前段時間訂閱學習了網易大佬的《數據中臺實戰課》專欄，一口氣學完后，做了一些總結筆記分享給大家，希望會對你有所幫助！

總結的文章我會分為上下兩篇來寫，先講原理，再談實踐，從原理到技術，最后到實踐。

這樣大家也能跟著我一起，既能看到數據中臺支撐技術的全貌，又不會錯過一些技術實現的細節 ? Here We Go !

一、開篇詞?

1.1 數據中臺為什么很難成功呢？ 客觀原因：數據中臺的建設是一項 系統性工程，從 組織架構、支撐技術到流程規范，既要有宏觀的頂層設計，又要有強有力的落地執行，團隊要求較高 主觀原因：企業本身數據建設經驗不足，不清楚數據建設中的痛點，更不知道用什么樣的技術手段和管理機制去解決問題?

1.2 方法論先行

通過原理方法論的學習，希望大家能弄明白下面三個問題：

什么是數據中臺？ 數據中臺解決了什么問題？ 如何來規劃數據中臺的建設？

不管是數據中臺還是業務中臺，歸根結底都是業務驅動第一性原理。

中臺是 技術+方法論+工具 的沉淀，在做任何的系統前我們都需要深刻反思業務的來源、現狀，未來我們業務的核心價值觀是什么？

這當中有管理也有技術，驅動業務數據化，數據資產化，資產服務化，服務業務化的循環。

而數據中臺無疑是要讓數據這種資產價值最大化，成為企業的重要基礎設施，重要的生產資料。

1.3 實踐出真知

這部分主要側重數據中臺支撐技術的整體架構，逐一講述每個模塊的具體實現。

了解企業在數據建設中到底存在哪些痛點，以及如何解決這些痛點。

數據中臺一定是基于大數據體系的，內在是數倉，底座是大數據計算平臺。

數據中臺建設的目的就是為了讓數據持續的用起來，賦能業務，提高響應能力和洞察能力，而上述的每一個點都是不可或缺的。

二、為什么數據中臺是大數據的下一站？?

2.1 啟蒙時代：數據倉庫的出現

商業智能（Business Intelligence）誕生在上個世紀90年代，數據分析需要聚合多個業務系統的數據，傳統數據庫已經不能滿足數據分析場景。

Bill Inmon 1991年 給出數倉定義：

數據倉庫是在企業管理和決策中面向主題的、集成的、與時間相關的，不可修改的數據集合。

Bill Inmon 提出的建模方法：

自頂向下（這里的頂指數據來源） 基于業務中各個實體以及實體之間的關系構建數據倉庫

Kimball 則提出了與 Bill Inmon 正好相反的建模方法，一種自底向上的模型設計方法。

兩種方法各有優劣：

Bill Inmon

從數據源開始構建，構建成本高，適用于比較固定的業務，如金融領域 冗余數據少是它的優勢

Kimball

從分析場景出發，適用于變化速度較快的業務，比如互聯網業務 現在業務變化較快，更適合用kimball維度建模?

2.2 技術變革：從Hadoop到數據湖

互聯網時代的變革

數據規模前所未有的龐大 數據類型的異構化

數據規模和數據類型的限制，導致傳統數據倉庫無法支撐互聯網時代的商業智能。

互聯網巨頭谷歌率先開始相關的探索，三駕馬車奠定了現代大數據的技術基礎。

《The Google File System》 《MapReduce：Simplified Data Processing on Large Clusters》 《Bigtable：A Distributed Storage System for Structed Data》

Hadoop相比于傳統數倉的優勢

完全分布式，易于擴展，價格低廉能滿足海量數據的處理需求 弱化數據格式

Data Lake

數據湖（Data Lake）是一個以原始格式存儲數據的存儲庫或系統。

隨著Hadoop技術日趨成熟，2010年 數據湖的概念在 Hadoop World 大會上被提出，同樣也拉開了Hadoop商業化的大幕。

2.3 數據工廠時代：大數據平臺興起

進入數據工廠的時代，我們首先要面對的就是數據開發復雜的流程：從數據集成、數據開發再到數據測試、數據發布、任務運維。

如此繁雜的工作流程，如果沒有搞高效的平臺支撐，自然效率低下。大數據平臺概念的提出，就是為了提高數據研發的效率，降低研發門檻。

大數據平臺是面向數據研發場景的，覆蓋數據研發的完整鏈路的數據工作臺

2.4 數據價值時代：數據中臺崛起

在大規模數據的應用場景下，也逐漸暴露除了一些問題：

煙囪式的開發導致企業的數據互相割裂，業務對數據的信任度下降 大量重復的計算、開發，導致研發效率的浪費，大數據應用成本越來越高

我們需要明白數據中臺的核心：避免數據的重復計算，通過數據服務化，提高數據的共享能力，賦能數據應用。

共享、連接和服務，這是中臺思想的根。

那為什么說數據中臺是大數據的下一站呢？

我想可以從下面四點來考慮：

數據中臺構建于數據湖之上，具備數據湖異構數據統一計算、存儲的能力，同時讓數據湖中雜亂的數據通過規范化的方式管理起來； 數據中臺需要依賴大數據平臺，大數據平臺完成了數據研發的全流程覆蓋，數據中臺增加了數據治理和數據服務化的內容； 數據中臺借鑒了傳統數據倉庫面向主題域的數據組織模式，基于維度建模的理論，構建統一的數據公共層； 數據中臺吸收了傳統數據倉庫、數據湖、大數據平臺的優勢，同時又解決了數據共享的難題，通過數據應用，實現數據價值的落地； 學習思考：數據中臺的下一站是什么？ 實時數據中臺，實現流批一體 云上數據中臺，全面擁抱K8S，實現在線、離線混合部署，進一步提高資源利用率 智能元數據管理+增強分析，降低數據分析的門檻，進一步釋放數據智能 自動化代碼構建，進一步釋放數據研發的效能 數據產品的時代，面向各行業的數據產品全面涌現，并和數據中臺實現聯動?

三、什么樣的企業應該建數據中臺？

企業數據日常在使用時，往往會面臨以下的問題：

指標口徑不一致 需求響應慢 取數效率低 數據質量差 數據成本增長過快

而這些問題的背后，主要由以下幾點原因構成：

缺少全局統一的指標管理； 煙囪式的開發導致數據重復建設； 找不到數據，非技術的同學取數困難； 數據加工的鏈路過長，出現問題很難及時發現； 數據重復建設，無用的數據加工消耗了大量的資源。

數據中臺該如何解決這些問題呢？

確保全局指標業務口徑、數據來源、計算邏輯一致 相同聚合粒度的度量、指標只加工一次，避免重復建設 構建企業數據資產目錄，提供非技術人員取數工具 全鏈路稽查監控，早發現、早處理、早恢復 計算每個應用、報表、指標的ROL，避免低價值的數據加工

那什么樣的企業適合建數據中臺呢？

擁有多個數據應用場景 存在業務數據孤島 面臨效率、質量和成本的問題 需要借助數據提高企業經營效率 業務相對穩定的有一定規模的公司?

四、數據中臺建設的板斧

如果我們把建數據中臺比作是蓋房子，那么設計圖紙就是數據中臺建設的方法論；工具是數據中臺的支撐技術；施工隊伍就是數據中臺的組織架構。這三者缺一不可。

4.1 方法論

早在 2016 年，阿里巴巴就提出了數據中臺建設的核心方法論：OneData 和 OneService。

OneData

OneData的核心就是復用，所有的數據只加工一次。數據中臺就是要在整個業務中形成一個公共數據層，消滅那些跨部門的小數倉，實現數據的復用，所以強調數據只加工一次，不會因為不同的應用場景，不同的部門數據重復加工。

具體來說主要由以下五點：

分主題域管理 命名規范定義 指標一致 數據模型復用 數據完善

這里離不開OneData的具體的實施流程，前面在 ：什么是OneData？阿里數據中臺實施方法論解讀 有詳細的解讀，這里就不再贅述。

OneData 體系的目標是構建統一的數據規范標準，讓數據成為一種資產，而不是成本。資產和成本的差別在于資產是可以沉淀的，是可以被復用的。成本是消耗性質的、是臨時的、無法被復用的。

OneService

OneService 數據即服務，強調數據中臺中的數據應該通過API接口的方式被訪問。

屏蔽異構數據源：數據服務必須要能夠支撐類型豐富的查詢引擎，滿足不同場景下數據的查詢需求。 數據網關：實現包括權限、監控、流控、日志在內的一系列管控能力，哪個應用的哪個頁面訪問了哪個模型，要做到實時跟蹤，如果有一些模型長時間沒有被訪問，應該予以下線。 邏輯模型：從用戶的視角出發，屏蔽底層的模型設計的實現，面向用戶提供邏輯模型。 性能和穩定性：由于數據服務侵入到用戶的訪問鏈路，所以對服務的可用性和性能都有很高的要求，數據服務必須是無狀態的，可以做到橫向擴展。

OneService 體系的目標是提高數據的共享能力，讓數據可以被用得好，用得爽。

4.2 支撐技術

這個圖完整地描述了數據中臺支撐技術體系，它的底層是以 Hadoop 為代表的大數據計算、存儲基礎設施，提供了大數據運行所必須的計算、存儲資源。

以 HDFS 為代表的分布式文件系統，以 Yarn/Kubernates 為代表的資源調度系統，以 Hive、Spark、Fink 為代表的分布式計算引擎，都屬于基礎設施范疇。如果把數據中臺比作是一個數據工廠，那可以把它們比作是這個工廠的水、電。

灰色的部分，是數據中臺的核心組成部分：數據治理模塊。它對應的方法論就是 OneData 體系。

深綠色的部分是數據服務，它是數據中臺的門戶，對外提供了統一的數據服務，對應的方法論就是 OneService。

4.3 組織架構

什么樣的組織架構是適合數據中臺建設的呢？簡單總結幾點如下：

獨立于業務線的中臺組織部門 中臺團隊必須深入業務，懂業務 中臺團隊的組織架構 數據產品 數據開發 數據平臺 數據應用 中臺團隊的組織績效必須與業務綁定。