《大數據大創新：阿里巴巴雲上數據中臺之道》：解密阿里數據中臺建設之道

寫在前面：我是「雲祁」，一枚熱愛技術、會寫詩的大數據開發猿。暱稱來源於王安石詩中一句 [ 雲之祁祁，或雨於淵 ] ，甚是喜歡。

寫博客一方面是對自己學習的一點點總結及記錄，另一方面則是希望能夠幫助更多對大數據感興趣的朋友。如果你也對 數據中臺、數據建模、數據分析以及Flink/Spark/Hadoop/數倉開發 感興趣，可以關注我的動態 https://blog.csdn.net/BeiisBei ，讓我們一起挖掘數據的價值~

哪怕是野火焚燒，哪怕是冰雪覆蓋，依然是志向不改，依然是信念不衰。 (ง •_•)ง

文章目錄

三、阿里的大數據主張

四、阿里雲上數據中臺的建設過程

五、數據中臺產品化服務

六、一位老數據人的情懷

一、前言

早在今年四月份，便看完了《大數據之路：阿里巴巴大數據實踐》一書，再迅速過了鄧中華老師這本《大數據大創新：阿里巴巴雲上數據中臺之道》，基本上可以窺見阿里數據中臺的建設過程以及一些技術細節。其中宗華作爲一位阿里老數據人的經驗分享和心路歷程，更是讓我這個後輩受益匪淺。

二、大數據的發展歷程和價值探索

從大數據的概念被正式提出，到馬老師預言人類從IT時代走向DT時代，大數據浪潮迭起。

身爲大數據開發者，我認同並且深信的一點就是，大數據一定會對社會創新、產業變革、業務創新及每個人的角色定位都會產生近乎決定性的影響。

阿里的雲上數據中臺，是歷經阿里生態內各種業態挑剔的實戰歷練，雲上數據中臺除了自身具備的內核能力外，還向上與“賦能業務前臺”連接，向下與“統一計算後臺”連接，並與之融爲一體，形成雲上數據中臺業務模式，因此也具備了對全社會賦能的可能。

2.1 大數據發展的關鍵事件

接下來簡單介紹下國內外大數據發展的關鍵事件：

這其中重要的一點需要了解，那就是2003年穀歌公開了著名的“三駕馬車”—內部對於海量文件的處理技術、GFS分佈式文件系統、並行計算處理框架MapReduce、高效數據存儲模型BigTable，這些促成了分佈式系統基礎架構—Hadoop，爲各個大數據組件的誕生打下基礎。

2.1 大數據的內涵和外延

醞釀20年才發展起來的大數據技術，究竟會給現實世界帶來怎樣的改變？可以探索的大數據市場又在哪裏？書中從以下四個方面進行了介紹。

語義層面：‘數據’即所有信息的記錄，例如用戶訪問網站的信息的轉化過程的行爲屬性；大是巨量的意思，可以隱身爲數量、形式、含義的豐富,保障實現被高保真的記錄與回放
實現層面：大數據是一套數據處理技術活方法體系，實現具體以上特徵的數據的存儲、計算、共享、備份和容災、保密等，保證數據處理的時效性和拓展性
服務層面：大數據的數據技術變革引發的新型信息服務模式，例如從數據探索出發，系統主動推送信息給用戶做決策、給及其優化參數、基於數據的量變完成數據的質變
應用層面：大數據是數據服務組合生成的新場景、新體驗、日益增長的數據量非但不會使信息獲取效率降低、質量下降，反而會讓每個人都能得到快速的迭代，個性化的互聯網服務。

三、阿里的大數據主張

在數據提供服務的基礎上，阿里對數據的要求是準、快、全、統、通，簡單的解釋是標準統一融會貫通、資產化、服務化、閉環自優，這是阿里數據中臺實現目標的核心。

3.1 雲上數據中臺賦能業務運行圖

在這張運行圖中，我們需要理解四個關鍵詞：數據全面、數據打通、數據統一以及數據的閉環優化。

要實現上面的目標，如何做呢？

圖片展示了數據中臺運行的過程，主要抽象成三個部分。但在阿里最新的OneData方法論中，則是劃分爲OneID、OneModel、OneService。

第一部分：OneModel 致力於實現數據的標準與統一。
第二部分：OneID 致力於實現實體的統一，讓數據融通而非以孤島存在，爲精準的用戶畫像提供基礎。
第三部分：OneService 致力於實現數據服務統一，讓數據複用而非複製。

3.2 阿里數據中臺賦能業務全景圖

在架構圖中，看到最下面的內容主要是數據採集和接入，按照業態接入數據（比如淘寶、天貓、盒馬等），把這些數據抽取到計算平臺；通過OneData體系，以“業務板塊+分析維度”爲架構去構建“公共數據中心”。

基於公共數據中心在上層根據業務需求進行建設：消費者數據體系、企業數據體系、內容數據體系等。

經過深度加工後，數據就可以發揮其價值被產品、業務所用；最後通過統一的數據服務中間件“OneService”提供統一數據服務。

四、阿里雲上數據中臺的建設過程

4.1 煙囪式開發造成業務困擾和技術浪費

阿里的數據中臺治理主要是在2014年開始的，在2014年以前，阿里的大數據建設處於煙囪式開發狀態，這樣的開發帶來了許多業務的困擾和資源的浪費。如圖，是2014年以前的阿里巴巴分業務自建數據體系的抽象圖。

不難看出，阿里的每一塊業務都有對應的ETL開發團隊爲其提供數據支持，而每個ETL開發團隊都會按照自己的思路建設自己的數據體系，可見：

數據流向會亂，無方向性的
數據管理式無序的，處於失控狀態
除了浪費研發人力和計算存儲資源、也必然滿足不了業務的需求

當然，這個問題被放大式在本身業務以極快的速度發展的前提下，這樣的開發導致的問題我們從兩個方面來看。

業務困擾

在混亂的開發中，會造成諸多的數據問題，如因爲指標的定義問題，導致同一指標有多個數據，最常見的指標爲UV,總結最業務的困擾主要一下三點：

數據統一：數據標準規範難（命名不規範、口徑不統一、算法不一致），數據任務響應慢，從而導致業務部門產生困擾而導致不滿。
數據未打通：各個數據團隊各自爲政，存在嚴重的數據孤島現狀；缺乏數據融通，數據價值發掘不夠，從而導致業務部門看不清數據。
成爲成本中心且服務化不足：數據無方向性，依賴混亂，，數據管理無序，失控，成本化嚴重，面向應用的服務化投入不足甚至缺失。

技術困擾

浪費主要分兩方面看，一方面是開發人力技術的浪費，開發人員日常在數據異常排查和數據調研上疲於奔命。另外一個是計算存儲資源的浪費，在沒有公共層的情況下，數據重複存儲和計算非常常見。簡單的總結爲一下的三點：

研發苦惱：煙囪式開發週期長、效率低。
維護困難：源系統乎或業務變成不能及時反應到數據上，加之數據不標準，不規範，上線難，下線更難。
時效性差：重複建設導致任務鏈路冗長、任務繁多，計算資源緊張；數據批量計算慢，時效性不強且覆蓋業務範圍窄，即時查詢返回結果慢。

4.2 數據公共層力求讓業務和技術都滿意

從上面的問題來看，數據的公共層建設是一件迫在眉睫的事情，那麼數據公共層建設到底該如何進行，建設之前又要如何準備。這裏就是OneData體系建設數據建設篇，OneData體系的主要四個組成部分爲：

規範化數據建模：規範化數據建模，特別關注數據規範定義、數據模型設計和ETL開發等全流程
規範化研發工具：用來落地和承載規範化建模的工具
數據模型數據小庫：規範化數據建模產生的所有分層數據模型的數據被統一存放在數據小庫中
面向應用的數據監控：所有的數據在面向應用是都會被監控和調用，且對上線、下線調優監控則會反饋到規範化數據建模中。

四個部分的運行圖如下：

這些規範肯定是會與時俱進地被調優，但大部分的內容至今仍具有重要的指導意義，特別式其中的數據規範定義和數據模型設計，它們也因此被保留在從2016年開始再次升級的OneData體系中。

具體的OneData體系的方法論，包含三個關鍵點分別是數據倉庫規劃、數據規範定義、數據模型設計，這裏我們不介紹技術細節，我在《大數據之路：阿里巴巴大數據實踐》：看阿里人從IT時代走向DT時代的經驗之談！裏都有講述，大家可以自行學習。

4.3 阿里雲上數據中臺三大體系

經過多年實戰，沉澱出了阿里雲上數據中臺內核能力框架體系：產品+技術+方法論。

歷經阿里生態內各種實戰歷練後，雲上數據中臺從業務視角而非純技術視角出發，智能化構建數據、管理數據資產，並提供數椐調用、數據監控、數據分析與數據展現等多種服務。

承技術啓業務，是建設智能數據和催生數據智能的引擎。在OneData、OneEntity、OneService三大體系，特別是其方法論的指導下，雲上數據中臺本身的內核能力在不斷積累和沉澱。在阿里巴巴，幾乎所有人都知道雲上數據中臺的三大體系，如上圖所示。

(OneEntity，現在應該是OneID，講數據從多終端、全渠道被採集到，並，與“人”相關的數據ID就有：業務賬號信息、PC cookie、無線imei與idfa等設備標誌、身份屬性信息)，這些信息加劇數據孤島的形成，我們通過OneID進行打通。這裏涉及OneID的設計，二維關係的構建和倒排表等，我會在後面阿里數據中臺的文章中再詳細講述。

以下便是通過OneID構建的人物畫像：

OneData致力幹統一數據標準，讓數據成爲資產而非成本；OneEntity（OneID）致力於統一實體，讓數據融通而以非孤島存在；OneService致力於統一數據服務，讓數據複用而非複製。

這三大體系不僅有方法論，還有深刻的技術沉澱和不斷優化的產品沉澱，從而形成了阿里巴巴雲上數據中臺內核能力框架體系。

4.4 阿里數據中臺及賦能業務模式支撐

阿里數據中臺，經歷了所有阿里生態內業務的考驗，包括新零售、金融、物流、營銷、旅遊、健康、大文娛、社交等領域。

數據中臺除了建立起自已的內核能力之外，向上賦能業務前臺，向下與統一計算後臺連接，融爲一體。

4.5 數據中臺技術的數字表現

今天，阿里處理的數據量已達EB級，相當於10億部高清電影的存儲量。在 2016年雙十一當天，實時計算處理的數據量達到9400萬條/秒。而從用戶產生數據源頭採集、整合並構速數據、提供數據服務，到前臺展現完成僅需2.5秒。

"友盟+”是阿里把收購的幾家數據公司整合升級後，組成的一家數據公司。這裏僅以2017年“友盟+”對外公開的部分指標爲例，其中的數據覆蓋14億部活躍設備、685 萬家網站、135萬個應用程序，日均處理約280億條數據，這一切都建立在阿里強大的數據處理技術底座之上。

4.6 數據中臺六大數據技術領域

阿里建設數據公共層之初，規劃了六大數據技術領域，即數據模型領域、存儲治理領域、數據質量領域、安全權限領域、平臺運維領域、研發工程領域。

而在阿里數據公共層建設項目第二階段完成存儲治理領域，已經被擴大到資源治理領域，進而升級到數據資產管理領域，安全權限領域，升級到數據信任領域，因爲很多工作已經在產品中實現，平臺運維領域不再作爲一個數據技術領域被推進，數據模型領域與數據質量領域還在持續推進中，不過增加了許多新的內涵，智能黑盒領域則是新起之秀。

由此可見，數據技術領域不是一成不變的，而是隨着業務的發展和技術的突破不斷擴大、昇華的。

4.7 數據中臺建設方法論

4.7.1 數據中臺建設方法論體系的全局

(1) 全流程一體化：即從數據採集到數據服務實現全鏈路通。在產品層面，不會讓用戶在不同使用階段來回切換於不同產品。

例如，用戶要做實體識別、用戶標籤畫像等，如果要依賴的數據在另外一個產品中, 甚至需要使用風格迥異的產品來完成，則用戶會不知所措。所以，以數據建設爲例，要實現數據從採集到標準化、實體識別、標籤畫像及最終面向應用的一站式服務。

(2) 向上多樣化賦能場景：不僅要有通用產品，還要有行業產品及尊享產品。應向不同的應用場雖和用戶，提供差異化服務。

例如，阿里數據中臺向阿里生態內小二提供數據產品時，就包括數據工具、專題分析、應用分析、數據決策這四個層次的產品和服務。

(3) 向下屏蔽多計算引擎：不管是哪裏的雲計算服務，都應該儘可能兼容甚至屏蔽的，讓用戶在應用時感覺簡單。

在阿里10年大數據建設歷程中，數據建設的底座依賴至少經歷了Oracle— GP-Hadoop—阿里雲計算平臺的變化過程。很多大數據應用與創新者也一定會面臨類似的變化。

所以，對於產品和服務，需要連同生態合作伙伴一起努力實現屏蔽多種計算引擎，不管底座是阿里雲公共雲，還是阿里雲專有云，還是自建的私有云，都可以在此之上構建數據並實現平滑切換。

(4) 雙向聯動：在構建大數據及服務業務應用與創新的過程中，業務和技術是需要協同互動的，而不是一方是另一方的資源這種單向關係。

一般來說，對於業務需要技術的協同這一點，人們很容易理解，但對於技術同樣也需要業務的協同這一點，人們可能就不太容易理解。例如，要對消費者進行識別、刻畫、觸達和服務，則需要業務部門在業務前臺按照數裾技術規範和標準進行布點，以便採集到數據，以及需要業務人員與技術人員一起討論刻畫消費者標籤的關鍵因素，並確定哪些標籤符合業務線的價值訴求。

4.7.2 OneData體系方法論

OneData體系方法論至少包括：數據標準化、技術內核工具化、元數據驅動智能化3個方面。

(1) 數據標準化。要從源頭實施數裾標準化，而非在數據研發之後，基於數據指標梳理的數據字典實施數據標準化。因爲，只有每一個數據都是唯一的，數據模型才能穩定、可靠，數據服務纔是靠譜、可信的。

(2) 技術內核產品化。所有的規範、標準等，如果沒有一個全流程的工具作爲保障, 則無法實現真正意義上的全鏈路通，因此，我們首先推進技術內核全面工具化。

(3) 元數據驅動智能化。前文提到，阿里正在持續努力實現數據建模後的自動化代碼生成，以及保障其實現和運行的智能計算與存儲框架。爲什麼阿里能做這件事情？其中一個重要原因就是，在源頭對每個元數據進行了規範定義，儘可能實現數據的原子化和結構化，並將其全部存在元數據中心裏。這些元數據對於計算、調度、存儲等意義非凡，因此有望實現從人工到半自動化，進而實現智能化。

4.7.3 OneEntity體系方法論

OneEntity體系方法論至少包括：技術驅動數據連接、技術內核工具化、業務驅動技術價值化3個方面。

(1) 技術驅動數據連接。OneEntity要實現實體識別，首先依賴很強的實體識別技術，所以要用技術來驅動數據連接。

(2) 技術內核產品化。產品化是目標，其發展過程不是一蹴而就的。一定要往這個方向努力，否則每一次進行標籤畫像（哪怕是類似的標籤），都要通過人力重複做一次，這實在是一件讓人非常痛苦的事情。所以，要高效地進行實體識別、用戶畫像，工具化是一條必由之路。當然，全部工具化總是很難實現的，一定還有工具無法替代人腦的部分，所以，努力追求的是將人腦智慧儘可能沉澱在工具型產品中。

(3) 業務驅動技術價值化。正如前文所述，將數據從孤島變得融通，進而實現高價值，是需要業務來驅動的。在此過程中，再一次體現了業務和技術要“背靠背”“你情我願”地進行雙向聯動的。

4.7.4 OneService體系方法論

OneService體系方法論至少包括：主題式數據服務、統一但多樣化的數據服務、跨源數據服務3個方面。

(1)主題式數據服務。舉一個例子，假設用戶想要看的是“會員”這個主題下的數裾.，至於“會員”主題背後有1000張物理表還是2000張物理表，他都不關心。而主題式數據服務要做的是，從方便用戶的視角出發，從邏輯層面屛蔽這1000張甚至是2000張物理表，以邏輯模型的方式構建而非物理表方式。

(2)統一但多樣化的數據服務。例如，雙十一當天上百億次的調用服務是統一的，但獲取形式可以是多樣化的，可以通過API提供自主的SQL查洵數據服務，也可以通過API提供在線直接調用數椐服務。

(3)跨源數據服務。不管數裾服務的源頭在哪裏，從數據服務的角度出發，都不應該將這些複雜的情況暴露給用戶，而是儘可能地屏蔽多種異構數據源。

業務在發展，技術在迭代，方法論也必然不斷升級，在實戰中沉澱、豐富雲上數據中臺建設方法論。

五、數據中臺產品化服務

在推進阿里數據公共層建設之初，就意識到業務與技術“背靠背"、雙向聯動的重要性。

在推進阿里巴巴數據公共層建設時，雖然當時在業務上雖然有了幾個月的緩衝時間，但維穩業務支持並不是停止業務支持，基本等同於“開着飛機換高能引擎”，雖然有時間和機會，但要快、很、準。

5.1 數據中臺核心產品Dataphin

Dataphin是一款PaaS產品，致力於一站式解決智能數據構建與管理的全鏈路訴求。具體來說，Dataphin而向各行各業的大數據建設、管理及應用訴求，一站式提供從數據接入到數據消費的全鏈路的大數據能力，包括產品、技術和方法論等，助力客戶打造智能大數據體系，以驅動創新。

智能大數據體系的建設，極大地豐富和完善了阿里巴巴大數據中心，OneData、 OneEntity、OneService三大體系也漸趨成熟，併成爲阿里巴巴中上至CEO、下至一線員工共識的三大體系。

Dataphin將指導解決所有與大數據體系建設有關的OneData、OneEntity、OneService體系方法論，及其在解決阿里巴巴數據公共層建設，及後續數據體系建設中的實際問題的具體做法全部沉澱下來。

5.2 Dataphin的PaaS服務

Dataphin在賦能阿里生態內外的驅動力下，到底要關注哪些痛點與核心訴求？在Dataphin沉澱過程中，還要考慮哪些因素？Dataphin在解決這些問題的過程中，提供了哪些獨樹一幟的核心能力？上圖所示的正是Dataphin在沉澱過程中考慮的各種因素，以及相應的核心能力輸出。

阿里生態內遇到的很多痛點和訴求，阿里生態外的各行業客戶也會面臨，具體介紹如下。

CEO關心數據對公司的戰略意義及現實意義：這份數據是準確的嗎？早上一起牀就能看到數據嗎？在數據上的投入產出比是怎樣的？……
CCO/CFO關心數據對業務的意義和價值，以及如何考量：大數據能助力全局監控,進而輔助投資決策嗎？每一條業務線運營都能用同一份數據嗎？大數據如何助力數據化運營並無處不在地深入業務？大數據是否會提升業務運營的效率和效果，以及如何考量？……
CTO/CFO關心如何讓數據又準又快又成本可控：成本消耗是否在可控範圍內？在技術資源上還有多少優化、提升的空間？技術人才的研發、維護投入是否有改進和提升空間？……
—線業務人員關心數據對自己達成業務自標的作用：我能又準又快地看數據和用數據嗎？我的數據需求能否得到快速、無差異的響應？這些數據能否幫助我提升業績，及時反映業務的完成進度？……
—線技術人員關心如何既優又超前地提供服務：計算是否夠快，存儲是否夠優？代碼開發是否可以提速，線上任務是否可維護？技術是否有可能在滿足業務的同時主動賦能業務？……