數(shù)據(jù)中臺是什么？

從 Hadoop 集群的開發(fā)運維，到構(gòu)建大數(shù)據(jù)平臺，再到數(shù)據(jù)中臺建設(shè)，這是很多大型互聯(lián)網(wǎng)公司大數(shù)據(jù)的建設(shè)歷程。到底什么是數(shù)據(jù)中臺，數(shù)據(jù)中臺跟我們之前一直說的大數(shù)據(jù)平臺有什么區(qū)別，我想可以通過一個例子來說明。

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

我們認為 數(shù)據(jù)中臺是企業(yè)級大數(shù)據(jù)通過系統(tǒng)化的方式實現(xiàn)統(tǒng)一、標(biāo)準(zhǔn)、安全、共享的數(shù)據(jù)組織，以服務(wù)化的方式賦能前臺數(shù)據(jù)應(yīng)用，提高數(shù)據(jù)的使用效率。

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

數(shù)據(jù)中臺解決的三大問題

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

效率問題可以分為數(shù)據(jù)研發(fā)的效率、數(shù)據(jù)發(fā)現(xiàn)的效率和數(shù)據(jù)分析的效率。

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

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

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

質(zhì)量是數(shù)據(jù)中臺需要解決的第二個問題，質(zhì)量包括數(shù)倉設(shè)計的質(zhì)量、指標(biāo)的一致性、數(shù)據(jù)研發(fā)的質(zhì)量。

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

指標(biāo)是數(shù)據(jù)加工的結(jié)果（也可能是中間結(jié)果），指標(biāo)管理的核心在于確保指標(biāo)的業(yè)務(wù)口徑、計算邏輯和數(shù)據(jù)來源的一致，消除指標(biāo)的二義性。數(shù)據(jù)開發(fā)經(jīng)常遇到的一個情況是，兩個數(shù)據(jù)產(chǎn)品，看到相同的一個指標(biāo)，結(jié)果不一致，這可能是口徑不一致導(dǎo)致的，當(dāng)然也有可能是數(shù)據(jù)來源不一致導(dǎo)致的。

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

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

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

效率、質(zhì)量、成本，這三個方面相互聯(lián)系，我認為這是數(shù)據(jù)中臺要解決的最重要的三個問題。

如何建設(shè)數(shù)據(jù)中臺

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

對于三個方法論，我們的經(jīng)驗是必須通過系統(tǒng)化的方式，將規(guī)范沉淀到系統(tǒng)中，確保建設(shè)的效果。為了支撐數(shù)據(jù)中臺的建設(shè)，我們研發(fā)了一套全鏈路大數(shù)據(jù)產(chǎn)品，網(wǎng)易猛犸 6.0，其架構(gòu)圖如下：

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

全鏈路大數(shù)據(jù)產(chǎn)品網(wǎng)易猛犸 6.0 在大數(shù)據(jù)開發(fā)、任務(wù)運維、數(shù)據(jù)集成等大數(shù)據(jù)平臺的基礎(chǔ)上，主要增加了兩個板塊，一個是 OneData 體系，它是以元數(shù)據(jù)中心作為基礎(chǔ)的，在元數(shù)據(jù)中心之上提供了 5 個中臺相關(guān)的產(chǎn)品：數(shù)倉設(shè)計中心、數(shù)據(jù)資產(chǎn)中心、數(shù)據(jù)質(zhì)量中心、指標(biāo)系統(tǒng)和數(shù)據(jù)地圖。

• 數(shù)倉設(shè)計中心：按照主題域、業(yè)務(wù)過程，分層的設(shè)計方式，以維度建模作為基本理論依據(jù)，按照維度、度量設(shè)計模型，確保模型、字段有統(tǒng)一的命名規(guī)范。

• 數(shù)據(jù)資產(chǎn)中心：主要作用是梳理數(shù)據(jù)資產(chǎn)，基于數(shù)據(jù)血緣，數(shù)據(jù)的訪問熱度，做成本的治理。

• 數(shù)據(jù)質(zhì)量中心：主要是通過豐富的稽核監(jiān)控規(guī)則，對數(shù)據(jù)進行事后校驗，確保問題數(shù)據(jù)第一時間被發(fā)現(xiàn)，避免下游的無效計算，分析數(shù)據(jù)的影響范圍。

• 指標(biāo)系統(tǒng)：管理指標(biāo)的業(yè)務(wù)口徑、計算邏輯和數(shù)據(jù)來源，通過流程化的方式，建立從指標(biāo)需求、指標(biāo)開發(fā)、指標(biāo)發(fā)布的全套協(xié)作流程。

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

另外一個板塊就是 OneService 體系，對應(yīng)的就是數(shù)據(jù)服務(wù)。數(shù)據(jù)服務(wù)對外提供 Restful API，屏蔽底層各種數(shù)據(jù)源，加工好的指標(biāo)，導(dǎo)出到 Greenplum、MySQL、Redis、HBase 里面進行查詢，數(shù)據(jù)服務(wù)將用戶訪問的 Restful API 轉(zhuǎn)化為底層對各種數(shù)據(jù)源的訪問。數(shù)據(jù)服務(wù)可以認為是數(shù)倉的網(wǎng)關(guān)。

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

數(shù)據(jù)中臺的價值

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

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

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

• 取數(shù)效率提升：在做數(shù)據(jù)中臺前，大量的數(shù)據(jù)發(fā)現(xiàn)都是通過人工協(xié)作交流的方式進行的，數(shù)據(jù)理解的準(zhǔn)確性、效率都非常低。基于數(shù)據(jù)地圖，我們實現(xiàn) 100% 自助取數(shù)，取數(shù)效率提升 300%，分析師滿意度得到大幅提升。

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

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

實施數(shù)據(jù)中臺的建議

在文章的最后，我想給即將做數(shù)據(jù)中臺，或者正在做數(shù)據(jù)中臺的同學(xué)一些建議。

首先要有目標(biāo)和度量，不管是做質(zhì)量，還是成本，還是效率，沒有目標(biāo)，沒有度量，就很難講的清楚效果。其次，要通過系統(tǒng)化的方式對規(guī)范和方法論進行沉淀。數(shù)據(jù)中臺不是一次性的事情，做質(zhì)量，稽核監(jiān)控規(guī)則要不斷的完善，治理成本，任務(wù)和表的優(yōu)化要持續(xù)進行。所以必須要有系統(tǒng)和產(chǎn)品做支撐。

最后，做數(shù)據(jù)中臺必須要實現(xiàn)全鏈路，各個子產(chǎn)品要相互打通，BI 產(chǎn)品可以引用指標(biāo)系統(tǒng)的口徑定義，任務(wù)運維中心任務(wù)異常可以追蹤到影響了哪個 BI 報表，數(shù)據(jù)資產(chǎn)必須要知道哪個 BI 報表訪問了那個表，才能知道哪個報表的哪個指標(biāo)消耗了多少資源，計算指標(biāo)的 ROI。

?

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

郭憶，網(wǎng)易杭州研究院大數(shù)據(jù)專家，網(wǎng)易大數(shù)據(jù)平臺網(wǎng)易猛犸、網(wǎng)易敏捷 BI 產(chǎn)品網(wǎng)易有數(shù)負責(zé)人。10 年互聯(lián)網(wǎng)數(shù)據(jù)研發(fā)經(jīng)驗，曾經(jīng)做過數(shù)據(jù)庫，主導(dǎo)了網(wǎng)易關(guān)系數(shù)據(jù)庫服務(wù) RDS 建設(shè)；做過推薦工程，負責(zé)網(wǎng)易信息流推薦服務(wù)；目前主要從事企業(yè)級數(shù)據(jù)中臺支撐產(chǎn)品以及通用型數(shù)據(jù)應(yīng)用的研發(fā)，支撐網(wǎng)易電商、音樂、傳媒等業(yè)務(wù)的大數(shù)據(jù)建設(shè)。

超強干貨來襲 云風(fēng)專訪：近40年碼齡，通宵達旦的技術(shù)人生

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。