本文深入探討了數據中臺建設的具體路徑和實施計劃，詳細闡述了從現狀梳理到項目成果的全過程，引導讀者了解如何高效構建企業級數據中臺，希望對你在數據管理和戰略規劃方面有所啟發。

本篇主要寫建設數據中臺的建設路徑，具體的項目實施計劃，以及實施過程中的注意點。

整個過程包含：

一、現狀梳理，明確當前主要問題

二、勾勒自下而上的解決方案

三、制定項目計劃

四、項目人員規劃

五、項目成果

一、首先進行現狀梳理，明確當前主要問題

每一塊業務都有對應的ETL開發團隊為其提供數據支持，每個團隊按自己的思路建設一套數據體系。

指標定義階段：字段命名不規范、口徑不統一、算法不一致。

指標規劃階段：數據部門疲于對業務支持、缺乏全局規劃，產品化能力不足。

指標開發階段：煙囪式數據開發，數據重復，不可信。

指標維護階段：復雜關系引用導致指標下線牽扯面大。

從此可看出，公司業務線較為單一的情況下，不需要盲目上中臺服務；數據中臺往往建立在解決一定交叉性數據問題的基礎上。

二、勾勒自下而上的解決方案

統一數據源：統一ODS數據基礎層，并有一個團隊負責和管控，其他團隊無權復制數據基礎層中的數據。

進行數據的統一規劃：面向業務提供服務前，由數據團隊負責從業務中抽象源于業務而又不同于業務的數據域，再主導統一建設數據中間層。

建設oneservice服務體系：將openAPI升級為緩解業務變化對數據模型沖擊的方法論、數據產品，提供統一公用服務的同事，兼容面向個性化應用的服務。

三、繼而制定項目計劃

梳理清楚現狀之后，明確問題所在，明確解決方案，接下來需要做具體的實施。

第一步：確定并堅定項目目標

在不影響業務發展的同時，在業務上推進數據價值化，降本提效為基礎目標，創造業務價值。

第二步：確定指導性的方法論

OneData：公共層建設核心方法論，知道構建與管理數據。

OneService：7x24h無間斷、無差異服務

OneEntity：連接孤島數據，實現數據連接后萃取各類標簽進行用戶畫像。

其中OneEntity體系包含如下：

1）OneEntity統一實體：全域關系打通設想ID-mapping

2）GProfile全域標簽：四維標簽體系探索，包含自然屬性、社會屬性、興趣偏好、行業消費偏好…

3）GRelation全域關系：設想以全域Entity關系打通為基礎的等關系圖譜

4）GBehavior全域行為：以全域Entity關系聚攏形成全域行為中心

第三步：確定三步走的項目執行計劃

第一階段：完成全局架構

1. 全面接管ODS數據基礎層

全面接管ODS數據基礎層，是一件十分吃力不討好的事情，事項十分繁瑣。但接管了ODS數據基礎層，則是從數據源頭上做了一層把關控制，防止重復建設數據體系的現象。

建設離線數ODS數據基礎層和實時ODS數據基礎層。

2. 升級OneData體系

將OneData體系升級到OneDataII，比較關鍵的是制定關于數據規范定義、數據模型設計、ETL開發規范3大環節的方法大綱。

3. 完成業務數據架構

從源頭控制住所有數據，并且也確定了未來如何建設和管理數據的方法論，那接下來如何設計具有前瞻性、可持續性、可擴展性的直接面向業務層的服務呢？

需要對業務數據進行盤點、分析和認知。但是，如果對所有業務都同時進行盤點，不僅耗時長且難以深入，不具備可行性。

于是，可以按照“二八原則”，先對關鍵業務及其關鍵數據進行第一批盤點，并從業務視角和技術視角同時進行盤點。

例如，對淘系數據的4100多張報表中的2萬多個指標盤點，經過多輪篩選，最終保留6600多個指標，即可保障當時的業務需求，其中1.4萬個指標，一部分直接下線，一部分在后續數據公共層建成并切換下線。

第二階段：抓關鍵業務的數據建設

在構建好ODS層之后，需要進一步豐富和完善DWD、DWS、ADS數據應用層?？偣舶?個方向。

1. 離線數據公共層建設（ODS、DWD、DWS）

最開始建設淘系數據基礎層治理項目，接盤ODS層之后，進行深度數據治理。，降低存儲和計算資源的消耗，提升數據監控管理力度。

2. 離線數據應用層建設（ADS、報表）

一是面向應用服務的數據寬表的建設：基于數據公共層，向各個業務部門提供方便、快捷的數據服務。

二是給領導們提供關鍵數據：建設面向COO領導層的重點關注的經營指標。

三是建設各業務線、行業的數據。

3. 數據存儲的專項治理

4. 實時數據公共層建設

第三階段：全面鋪開，逐步推進各個項目的數據建設

（下一篇文章中進行展開）

第四步：明確處理好關鍵矛盾

第五步：緊盯業務并超越業務滿意度

一個月內完成第一階段的全局架構工作，并快速啟動第二階段。第二階段第一期切入關鍵應用，并在2個月內完成數據公共層初始化；第二階段二期在遷移存量應用的同時支持新需求。

把服務雙十一和雙十二作為階段性業務目標，讓業務人員看到實際效果，技術人員感受到技術進步，數據公共層建設的推進就會由難到易，由慢到快。

第六步：業務和技術，兩手都要抓，兩手都要硬

數據技術是數據公共層建設的內核力量，包含數據模型、存儲治理、數據質量、安全權限、平臺運維、研發工具等。

第七步：以產品化思維推進項目

將數據公共層建設視為一個需要長期運營的產品。

第八步：關注預警和加強風險管理

提前進行風險規劃，制定保障措施，如：

風險描述：數據規范定義和數據模型設計體系化，需要專業人才和工具保障。

保障措施：

1）制定規則及工作流，完善onedata體系數據規范定義，同時以工具化保障onedata體系工作流

2）數據產品經理和數據模型師培養，輸出多名具有建模思想和建模能力、同時熟悉業務的人員

3）公共層可以穩定支持業務后，定期安排數據模型師和ETL研發人員深入業務以更新對源系統和業務的認知

四、同時需要項目人員規劃

若是需要最終完美的完成項目計劃，缺乏其他業務部門或技術部門的配合是萬萬不可的，因為在實際的項目進程中，需要一個實體團隊來負責數據公共層建設，以及協同若干個業務線的技術團隊作為虛線加入項目組。

在最初建設時，數據團隊只有50個人，而要實現如此龐大的計劃，需要更多人員的支持。在建設前期由兼職的18羅漢進行現狀梳理，并完成全局架構。

隨著項目的興起，領導團隊對項目愈加看重，因而得到了更多人員資源上的支持。

五、最后靜待項目成果

降本：數據計算成本和存儲成本降低，以及因重復建設而造成的人力成本的降低等。

2015年，批量數據計算總時長減少約50%，解約計算成本近億元；批量數據下線，解約存儲空間上百PB，節約存儲成本上億元。

提效：讓各業務部門得到了統一、標準的數據服務，并且響應速度很快，提升了使用數據的效率。

業務上，數據價值化。

如上是阿里數據中臺第一階段、第二階段的建設過程，接下來一篇會繼續解析第三階段：全面鋪開的數據中臺建設過程。