數據中臺是什么？

從 Hadoop 集群的開發運維，到構建大數據平臺，再到數據中臺建設，這是很多大型互聯網公司大數據的建設歷程。到底什么是數據中臺，數據中臺跟我們之前一直說的大數據平臺有什么區別，我想可以通過一個例子來說明。

如果我們把數據中臺看作是一個汽車工廠，那大數據平臺就是工廠中的設備，Hadoop 集群則是工廠運作所必須的水、電、煤。Hadoop 提供的是大數據生產所必須的計算和存儲資源，大數據平臺使得數據開發人員具備了對數據的加工和處理能力，類比設備使得工人具備了對原材料的加工能力，但是大數據平臺還不能提供產品，這么多的原始數據，要按照一定的方法論，進行良好的組織，加工，才能生成最終的指標，就如只有切割機、油漆機還不能生產汽車，各個零部件要按照一定的規則，通過設備組裝在一起，才是一輛完整的汽車。

我們認為 數據中臺是企業級大數據通過系統化的方式實現統一、標準、安全、共享的數據組織，以服務化的方式賦能前臺數據應用，提高數據的使用效率。

數據中臺與數據平臺最本質的區別在于數據中臺是具備業務屬性的，輸入的是原始數據，輸出的是指標。數據中臺包含了業務對數據的組織方法論，體現在主題域，業務過程的劃分，數據模型的設計，指標、維度、度量的管理，如果我們想確定一個數據是指標還是維度，就必須理解業務。大數據平臺提供的是與業務屬性無關的工具集合，是數據的加工能力，至于加工的什么數據，平臺并不關心。

數據中臺解決的三大問題

在明確了數據中臺與大數據平臺的區別之后，我們需要探討的是，數據中臺到底解決了什么問題。歸結起來，主要是三個：效率、質量和成本。

效率問題可以分為數據研發的效率、數據發現的效率和數據分析的效率。

首先是數據研發的效率，在我所接觸的很多項目中，在項目初期，由于業務模式還不固定，變化比較快，往往缺少良好的主題域和分層的設計，煙囪式的開發模式占據了主導，隨著業務復雜度和規模的上升，大量重復性的數據開發，制約了數據需求交付效率。一個需求往往需要一個星期甚至更長的時間才能上線，需求響應速度經常被業務部門詬病。

其次是數據發現的效率，由于開發數據的和使用數據的往往是不同的人，面對動輒數萬張表，每張表有數十個甚至上百個字段，準確理解每張表的含義是一件非常困難的事。如果沒有一個好用的系統，往往需要大量的溝通成本，對于數據開發，經常抱怨工作被打斷，每天都在回答重復性的問題；對于分析師而言，想要知道有哪些數據可以用，找到自己想要的數據，需要花費大量的時間。在網易，建設數據中臺之前，很多業務都在用很原始的方法，每個分析師都自己維護了一個 Excel，相當于自己的知識庫，記錄著一些常用的表。一個新的分析師想要了解數據，需要花費大量的時間。

最后是數據分析的效率，我們希望越來越多的人能夠基于數據進行分析決策，但是數據分析本身確實存在門檻，取數對于大多數非技術專業的運營和分析師就是一個大問題，經常看到一個分析師的 SQL 把整個集群資源跑滿還跑不出來，經?？吹椒治鰩熡龅揭粋€ SQL 異常不知所措。另外，傳統的數據分析依賴的是分析師的經驗，一個指標異常波動，需要從哪些維度去分析，完全靠分析師的個人技能，如何將經驗變成一種知識，甚至是一種規范，沉淀到產品中，通過系統自動地進行全維度的鉆取分析，降低數據分析的門檻，這其實也是業務面臨的難題。

質量是數據中臺需要解決的第二個問題，質量包括數倉設計的質量、指標的一致性、數據研發的質量。

數倉設計得好不好，主要體現在三個方面，完善度、復用性和規范性。數倉設計一般采用的是面向主題域的分層設計，對于 ODS 層保存的是業務原始數據，DWD 保存的是經過清洗的明細數據，DWS 是經過輕度聚合的匯總數據，ADS 或者 DM 是應用層、集市層數據，這是一個常見的 4 層模型劃分。完善度的意思就是對于使用者而言，“要啥有啥”，對于不同分層，完善度的衡量方式也是有區別的，對于明細層，如果數倉中存在匯總層（DWS）數據直接引用 ODS 原始數據的情況，我們稱之為跨層引用，這就說明細層數據建設是有缺失的，如果其他匯總層也要使用相同的數據，都從 ODS 層去引用，就存在重復清洗的問題。對于匯總層數據而言，如果 Query 覆蓋率比較低，說明大量的查詢都是直接查詢明細數據，甚至是原始數據，這就說明匯總層數據建設完善度不夠，對于使用數據的人而言，查詢明細數據，不僅慢，而且查詢成本高，經常出現一個查詢 hang 住整個集群的情況。復用性主要強調的是一個表被多個表使用的情況，復用性越高，說明數倉的設計越合理，更多的數據在數倉被復用。規范性主要是指數倉中的表、字段的命名規范統一，相同指標、維度、度量的標識是一致的。

指標是數據加工的結果（也可能是中間結果），指標管理的核心在于確保指標的業務口徑、計算邏輯和數據來源的一致，消除指標的二義性。數據開發經常遇到的一個情況是，兩個數據產品，看到相同的一個指標，結果不一致，這可能是口徑不一致導致的，當然也有可能是數據來源不一致導致的。

質量還包括數據的質量，這里面包括數據的一致性、準確性、及時性以及完整性。數據的一致性，具體表現在集市層相同的指標數據是否一致，維度是否一致，相關指標的趨勢是否一致，不同數據源對同一個實體的值是否一致。準確性體現在數值計算的邏輯是否符合預期，數據格式是否正確。曾經我們有過一個深刻的教訓，在電商業務中，由于業務側更新上線后部分 IP 格式有問題，導致流量域、交易域部分指標出現異常波動。由于沒有對數據進行質量稽查，問題的排查和定位花費了大量的時間。及時性主要體現在數據產出時延，我們一般通過數倉數據在指定時間（比如 5 點之前）產出完成率來衡量。另外對于實時數據，對時效性要求比較高，我們會拿數據計算延遲來衡量。完整性主要是表記錄是否完整，包括記錄數是否完整，字段是否完成。

成本是數據中臺需要解決的第三個問題，成本包括計算資源成本、存儲資源的成本以及人力研發成本。

數據就像手機里面的文件，如果不定時清理，手機存儲空間永遠不夠用。我們經常發現，大數據成本比業務增長還要快，這一方面是由于煙囪式的開發導致的數據重復加工，浪費計算和存儲資源，另一方面也是由于沒有定時清理，及時將無用的數據和任務下線，導致已經沒人看的報表，每天還從幾十億行的原始數據進行計算加工，浪費大量的資源。人力的成本其實跟效率有關系，如果效率得到提升，研發成本也會得到控制。

效率、質量、成本，這三個方面相互聯系，我認為這是數據中臺要解決的最重要的三個問題。

如何建設數據中臺

接下來我們要講講如何建設數據中臺。建設數據中臺，本質上是要減少數據的重復建設，提高數據的共享能力，做好數據的連接，對應的就是 OneData、OneService 和 OneEntity 三個方法論。OneData 要求數倉所有數據只加工一次，對應到數倉的設計層面，要求有統一的維度，對于明細層數據，相同粒度的度量只加工一次，對于匯總層的數據，相同粒度的指標只存在一份。OneService 是統一查詢服務，原先數據開發和應用開發的邊界是比較模糊的，哪些邏輯應該是由數據開發完成，哪些應該是由應用開發完成，我們甚至發現有些計算是在一個超大的 Redis 集群里面完成海量數據的加工計算，成本非常大，且不能共享。數據服務劃清了數據和應用的邊界，數據服務提供的是加工好的指標數據，應用通過數據服務，直接獲取計算的結果，強制把公共計算邏輯下沉到數據層面，提高了數據的共享能力。OneEntity 主要是解決數據連接的問題，同一個用戶，由于用戶是否登錄，在同一個模型中，可能存在重復的記錄，如何識別兩個 ID 是同一個用戶，做到所有用戶只有唯一的 ID 標識，這個是 OneEntity 要解決的問題。

對于三個方法論，我們的經驗是必須通過系統化的方式，將規范沉淀到系統中，確保建設的效果。為了支撐數據中臺的建設，我們研發了一套全鏈路大數據產品，網易猛犸 6.0，其架構圖如下：

全鏈路大數據產品網易猛犸 6.0 建立在 Hadoop 基礎之上，包括 16 個子產品（上圖中綠色模塊標識部分），覆蓋了數據生產、治理的完整鏈路，本著“簡單易用，舉重若輕”的產品設計思想，我們采取了“組件式”的產品設計模式，每個產品都聚焦一個典型的場景，業務可以根據自身的需要，選擇性的搭配一些產品應用，解決業務當前面臨的問題。同時猛犸 6.0 具備可擴展的產品架構，業務方可以基于該產品提供的基礎能力，擴展新的產品。

全鏈路大數據產品網易猛犸 6.0 在大數據開發、任務運維、數據集成等大數據平臺的基礎上，主要增加了兩個板塊，一個是 OneData 體系，它是以元數據中心作為基礎的，在元數據中心之上提供了 5 個中臺相關的產品：數倉設計中心、數據資產中心、數據質量中心、指標系統和數據地圖。

• 數倉設計中心：按照主題域、業務過程，分層的設計方式，以維度建模作為基本理論依據，按照維度、度量設計模型，確保模型、字段有統一的命名規范。

• 數據資產中心：主要作用是梳理數據資產，基于數據血緣，數據的訪問熱度，做成本的治理。

• 數據質量中心：主要是通過豐富的稽核監控規則，對數據進行事后校驗，確保問題數據第一時間被發現，避免下游的無效計算，分析數據的影響范圍。

• 指標系統：管理指標的業務口徑、計算邏輯和數據來源，通過流程化的方式，建立從指標需求、指標開發、指標發布的全套協作流程。

• 數據地圖：提供的是元數據的快速檢索，數據字典、數據血緣、數據特征信息的查詢，相當于元數據中心的一個門戶。

另外一個板塊就是 OneService 體系，對應的就是數據服務。數據服務對外提供 Restful API，屏蔽底層各種數據源，加工好的指標，導出到 Greenplum、MySQL、Redis、HBase 里面進行查詢，數據服務將用戶訪問的 Restful API 轉化為底層對各種數據源的訪問。數據服務可以認為是數倉的網關。

在數據服務之上，就是應用層，這里可以分為兩類，一類是通用性數據應用，包括報表系統、大屏系統、自助分析系統，本身不具備行業屬性，任何業務都可以使用；另一類是行業性的數據應用，比如電商的供應鏈系統、傳媒的輿情系統。在我們的數據中臺劃分中，通用性的數據應用也被劃入了中臺的范圍內，因為中臺本質是提供共性能力，對于數據中臺，就是提供共享的數據。

數據中臺的價值

數據中臺是一個自上而下的工程，需要投入大量的人力和資源，很多企業想做數據中臺，卻又不知道如何去衡量數據中臺的價值，下面結合網易的實踐，給大家一些參考。

• 消除指標的不一致：在做數據中臺之前，指標業務口徑不一致，數據來源不一致，計算邏輯不一致，經常是造成同個指標結果不一樣的原因。通過指標系統，我們對所有數據產品的指標進行了全面梳理，按照主題域、業務過程進行劃分，對指標按照原子指標和派生指標進行拆分，消除冗余指標、無效的指標，明確所有指標的業務口徑、計算邏輯和數據來源。通過指標系統，我們可以快速的查詢，數據產品上直接引用指標系統的業務口徑，在數據產品上，我們完全消除了指標的二義性。

• 數倉設計水平提升：在做數據中臺之前，我們有大量的表沒有明確的主題域和業務過程劃分，大量匯總層數據直接引用原始數據，ODS 層有大量的任務直接引用，大量 Query 直接查詢原始數據。在數據中臺建設后，整個數倉水平上了一個臺階，不僅所有數倉維護的非中間表均有明確的主題域和分層，并且完全消除了匯總數據直接引用 ODS 層原始數據的情況，數倉表的復用性顯著提高，匯總層 Query 的覆蓋率明顯提升。

• 取數效率提升：在做數據中臺前，大量的數據發現都是通過人工協作交流的方式進行的，數據理解的準確性、效率都非常低?；跀祿貓D，我們實現 100% 自助取數，取數效率提升 300%，分析師滿意度得到大幅提升。

• 數據質量的提升：在做數據中臺前，數據經常無法按時產出。我們規定每天 6 點前數倉的數據要產出完成，但是往往達不到這樣一個要求，出現一個異常，經常被業務方投訴，而排查和定位一個故障，也需要大量的時間，有了數據質量中心后，通過大量的稽核監控規則，我們做到了先于使用數據的人發現數據的問題，并且基于全鏈路的監控，我們可以知道某個任務異常，影響了哪些指標，并且基于任務的歷史運行數據，對故障恢復時間進行預測。

• 數據成本減少：衡量這個其實是最簡單的，直接就看數倉消耗的資源，原先是多少，數據中臺建設之后又是多少，當然這里面存在業務增長的情況，我們核算的方法是把單個任務的成本占優化任務時，數倉消耗的當日成本占比，作為衡量指標，我們最終通過下架無用的、低價值的表和任務，為業務節省了 20% 的成本。

實施數據中臺的建議

在文章的最后，我想給即將做數據中臺，或者正在做數據中臺的同學一些建議。

首先要有目標和度量，不管是做質量，還是成本，還是效率，沒有目標，沒有度量，就很難講的清楚效果。其次，要通過系統化的方式對規范和方法論進行沉淀。數據中臺不是一次性的事情，做質量，稽核監控規則要不斷的完善，治理成本，任務和表的優化要持續進行。所以必須要有系統和產品做支撐。

最后，做數據中臺必須要實現全鏈路，各個子產品要相互打通，BI 產品可以引用指標系統的口徑定義，任務運維中心任務異?？梢宰粉櫟接绊懥四膫€ BI 報表，數據資產必須要知道哪個 BI 報表訪問了那個表，才能知道哪個報表的哪個指標消耗了多少資源，計算指標的 ROI。

?

感謝作者！以下為作者簡介

郭憶，網易杭州研究院大數據專家，網易大數據平臺網易猛犸、網易敏捷 BI 產品網易有數負責人。10 年互聯網數據研發經驗，曾經做過數據庫，主導了網易關系數據庫服務 RDS 建設；做過推薦工程，負責網易信息流推薦服務；目前主要從事企業級數據中臺支撐產品以及通用型數據應用的研發，支撐網易電商、音樂、傳媒等業務的大數據建設。

超強干貨來襲 云風專訪：近40年碼齡，通宵達旦的技術人生

總結

以上是生活随笔為你收集整理的网易数据中台建设实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。