最近阿里巴巴分享了《阿里巴巴資料中臺實踐》這個PPT（自行搜尋原始文章），對於資料中臺的始作俑者，還是要懷著巨大的敬意去學習的，因此仔細的研讀了，希望能發現一些不一樣的東西。

讀這些專業的PPT，實際是非常耗時的，你需要把這些PPT外表的光鮮扒光，死摳上面的每一個字去理解底下隱藏的含義，然後跟你的已有知識體系去對比，看看是否有助於完善自己的認知，對於自己不理解的，還需要經常去檢索相關的文件。

當然，很多寫PPT的用詞沒這麼嚴謹，臨時造概念的不少，或者是獨特的說法，因此有時候還要做一些揣測，結合自己的實踐去理解，這篇PPT的解讀有6000多字，因此請做好燒腦的準備，雖然筆者沒去現場聽演講，但希望我的“演講”也能讓你學到真功夫。

就讓我們開始吧。

1、題目和背景

看到這個片子的出處，阿里雲智慧事業部，其實是有點奇怪的，記得阿里的中臺事業群包括搜尋事業部、共享業務平臺、資料技術及產品部，阿里雲是一個側重雲業務的平臺事業部，它來說資料中臺合適嗎？

有人會問，平臺和中臺又有什麼區別呢？阿里雲來講中臺不是很合適嗎？

筆者的疑惑是這樣：一般意義上的平臺具備業務無關性，潛心技術就可以了，而中臺是業務的收斂，跟業務的相關性很大，對於資料中臺，其核心競爭力不是平臺級的技術，而是資料的理解、處理和挖掘。讓一個做平臺技術的人跑到前端去理解資料訴求沉澱共性是不現實的，而這是當前資料中臺創造價值的核心。

當然講PPT的可以不問出身，能理解阿里的資料中臺就可以了。

2、DT派向左，IT派向右

傳統的IT是成本中心，而有了資料後，就可能成為價值中心，這個價值體現在：在管理上可以提供決策支援，在生產上可以提供與管理匹配的智慧工具，也就是提升生產關係和生產力的適配能力。

這一點提得是不錯的，比如浙江移動大資料中心就是直接定位為利潤中心。

這裡的IT和DT的對比就不太合適了，兩者不是對立的關係，而是融合的關係，D通過IT形成DT，比如原來IT渠道系統僅受理業務，現在在受理的場景下可以載入基於資料的智慧推薦。

DT只是馬雲提得一個突出資料價值的抽象概念，不能生硬去的理解，現在中國移動提了一個三融概念：融合，融通，融智，我覺得IT和DT就要加強融合融通，融合就是搭在一起賣，融通就是能力共享，IT中有DT能力，DT中也要有IT能力。

片子中提到的DT是問題導向，IT是需求導向，這是一個問題的兩面，而不是DT和IT的區別；新丟擲的DT的授之以漁，IT的授之以網的區別在於方法的觀點倒是有點道理，比如DT的智慧推薦就是提供了方法，而以前IT的推薦靠的是人的判斷。

3、企業組織對於DT的希望

高管團隊：看指標發現風險這是BI時代的基本訴求，沒啥好說的；大資料更強大的處理、視覺化、實時等技術可以提供更好的看資料體驗，這是相對於以前BI提升的地方。

業務團隊：提到三個變化：

一是通過資料發現問題，而不是拍腦袋。

二是業務人員要既懂業務也懂資料，甚至能自己DIY資料和模型。

三是資料要嵌入生產流程中直接發揮作用，比如標籤庫要成為營銷目標使用者的發起地，風控模型要嵌入在使用者操作流程中等等。

第一點大家都在做，實際還是以經驗為主，資料只是參考和佐證，這種模式本質上沒有改變。第二點，第三點執行到位對於大多數企業都很難。

技術團隊：提到三個要點：

一是“資料多跑路”是智慧平臺的核心，浙江的“最多跑一次”就是要靠資料和平臺整合實現這個目標。

二是IT人員要有資料化的思維，這個提的很好，缺乏資料思維的人設計IT系統很少考慮智慧，現在很多企業的受理系統跟推薦系統是兩者皮多少有這個原因。

三是通過資料分析發現新的知識，從而賦能業務，這是資料技術團隊的使命。

4、大中臺、小前臺

這張圖詮釋了阿里的商業作業系統的引擎：大中臺，小前臺，展示的很清晰了，特別提醒要理解兩個重要概念：業務資料化和資料業務化。

業務資料化：就是所有的商業活動都應該記錄下相關的資料，這是業務中臺應該承擔的使命。

業務資料化挑戰其實很大，以前業務平臺在設計的時候，是以功能和流程為核心的，只記錄對於要實現功能和流程必需的資料，其他的就可有可無了。

比如運營商的一些信令日誌記錄不全面導致可能影響後續的網路分析或資料價值變現，這就沒有做到業務資料化。

但業務資料化有時意味著巨大的成本投入，說來容易執行難，大多企業的資料不是業務資料化戰略執行的結果，而僅僅是順便摘取的低垂的果實。

資料團隊的一個使命就是業務資料化，很多好的資料是你進入前端爭取來的，這樣才能驅動業務記錄資料。

資料業務化：本質就是從資料中發現價值，反過來賦能業務，這是很好理解的。

數字孿生這個詞現在也比較熱了，未來萬物互聯的世界將你所有的行為實時記錄下來，形成另一個數字化的你，這就是數字孿生，如果業務中臺是你，那資料中臺就是你的兄弟。

5、資料中臺賦能的四大典型場景

（1）全域性資料監控：本質就是指標+報表+視覺化，這是給管理者看得，當然業務人員也要看，以下給了雙11大屏示例。

（2）資料化運營-智慧CRM：提到要“基於全鏈路全渠道資料的建立以“人”為核心的資料連線萃取管理體系，對使用者進行全生命週期的精細化管理”，這麼多形容詞懵不懵逼，到底在說啥？

全鏈路是指縱向記錄跟蹤整個商業過程的資料（包括商品企劃、售前及售中管理、客服管理、訂單處理、倉儲物流等等）。

全渠道就是各觸點的使用者行為資料，比如天貓、淘寶、優酷等等。

因此，通過匯聚全鏈路全渠道的資料才能形成完整的客戶畫像，然後用連線萃取的方式方便的獲得所需的資料進行分析，從字面意思看跟我們的標籤庫定位有點像。

（3）資料植入業務-智慧推薦：這裡講的比較清楚，就是營銷閉環管理，從使用者細分，千人千面，渠道推薦，再到營銷評估，以下是示例。

（4）資料業務化-生意參謀：這個是阿里力推的為數不多的血統純正的資料產品，是資料業務化和資料直接變現的典型代表，可以為店主提供端到端的分析支撐，網上介紹很多了，下面這張片子著重說明了生意參謀的歷史，現在和未來，有點意思。

歷史：百家爭鳴，雖然提了資料冗餘、體驗差等問題，但沒有百家爭鳴，不可能有生意參謀這個整合產品的出現。

現在：生意參謀獨霸天下，依託的是資料中臺體系，包括OneData、OneService、OnePlatForm等，這個後面會解讀。

未來：一個生意參謀還不夠，要打造一個產品開發平臺，複製出一個個面向不同行業的生意參謀，也就是參謀X，野心很大。

為什麼說血統純正呢？

因為諸如推薦啥的，資料是依附於業務流程上的，你評估資料價值的時候，很難說是業務本身好、流程設計好、還是你資料推薦的好，而純正的資料產品是資料人員彰顯自身價值的更好方式。

6、阿里巴巴做資料中臺的緣起

做資料中臺的緣起跟一般資料倉庫融合模型是一樣的，共享複用的需要，比如原來基於淘寶資料的各種業務都自建一套中間層，而這些中間層很多是重複或類似的，比如螞蟻業務有交易主題，天貓也有交易主題，那能不能抽象出公共的交易主題為兩個業務都服務呢？

因此你會看到阿里資料中臺抽象出了會員、商品、交易、瀏覽、廣告等公共核心主題層，從而為應用層服務，各個應用層以前要做很多公共層的東西，現在也可以完全複用了，理論上可以提升應用構建的速度。

下面這頁片子從資料的依賴關係圖比對了前後的變化，一個是網狀的，代表了相互之間千絲萬縷的關係，冗餘肯定是很多的，一個是放射狀的，一個節點可以為更多的後端節點服務，代表了共享和簡潔。

7、阿里巴巴資料中臺全景圖

讀懂這張圖就理解了阿里的資料中臺具體到底幹了些什麼，有五大部分跟資料中臺直接相關：資料中臺DaaS、資料資產管理IPaaS、資料研發平臺IPaaS及計算與儲存平臺IaaS。

筆者理解廣義的資料中臺其實包括資料中臺DaaS、資料資產管理IPaaS、資料研發平臺IPaaS三部分，如果狹義的理解則僅包括資料中臺DaaS，資料資產管理IPaaS、資料研發平臺IPaaS在筆者的企業叫做能效中臺。

（1）計算與儲存平臺IaaS

流計算SteamCompute：應該指阿里內部的Flink版本。

離線計算MaxCompute：阿里自研的EB級的資料倉庫（原來的ODPS）。

實時計算ADS：AnalyticDB的簡稱，主要是提供實時線上分析，可以認為是阿里自研的OLAP版本。

（2）資料資產管理IPaaS

資料資產管理其實跟元資料管理一回事。

資產地圖：本質上是資料字典的圖形化版本，阿里有多少資料、如何儲存、資料之間關係如何、如何找、如何用都可以從資產地圖找到答案，蠻形象的，從網上資料看，其設計還是值得借鑑，以下是一些介面截圖。

資產分析：你可以理解為針對元資料的BI分析，什麼結構分析，趨勢分析什麼的，萬變不離其宗，你希望通過元資料分析理解現狀，發現異常，從而指導資料資產的治理，比如支付類別的資料增長情況如何。

資產應用：你可以理解為利用元資料資訊來提升資料資產的利用效率，比如通過影響分析挖掘出無效的資料資產，從而降低資料冗餘，這個工作做好，價值是很大的。

資產運營：運營這個詞被用爛了，運營其實不是一個功能，而是一個動作，希望通過各種舉措來讓資料被更多的人使用，從而產生更多的價值，比如新增資料資產的推薦等等。

資料資產使用的二八定律是非常明顯的，大多資料其實是沒人訪問或使用的，而儲存的成本可是很高的，只有通過運營才能讓沉默的資料被更多的人使用，無效的資料得到清除，從而實現降本增效。

（3）資料研發平臺IPaaS

這個平臺跟筆者以前文章中提到的DACP是一個東西，就是負責資料的加工，需要一系列配套功能，包括資料規劃、交換、處理、開發、排程及監控等等。

（4）資料中臺DaaS

垂直資料中心（OneClick）：就是傳統資料架構中的ETL，通過離線、實時等方式將各渠道的資料採集過來。

公共資料中心（OneData）：就是資料倉庫建模需要達到的目的，保證資料口徑的規範和統一，沉澱共性的資料，阿里採用的是維度建模，通過分析業務過程抽象出維度和指標，最後彙總成所需要的倉庫模型。

萃取資料中心（OneID）：筆者的理解是阿里為了方便對外提供資料，形成了一套以各種ID（業務核心物件）為唯一標識的寬表，就好比運營商需要形成一套以使用者ID（手機號碼）、客戶ID、賬戶ID、家庭ID為核心的寬表體系一樣。

統一資料服務中介軟體（OneService）:以資料倉庫整合計算好的資料作為資料來源，對外通過介面的方式提供資料服務。

8、阿里巴巴資料中臺的沉澱與積累

（1）OneData

資料標準化：實現資料資產各域、主題、模型、欄位、指標命名等的統一規範，筆者一直強調資料標準化一定要在源頭解決，如果阿里的業務系統資料資產都遵循這個原則，那是厲害的很。

技術核心工具化：我的理解是規範的落地必須依託工具來強制控制，比如你只能按照規範模板的要求來建表，否則就執行不了，阿里在這方面的管控據說是比較給力的。

元資料驅動智慧化：有了元資料分析就能科學的計算出對於資源的訴求，而且可以做得非常快速和靈活，擯棄每次規劃擴容到處找依據的窘境，這跟前面的元資料應用是類似的。

OneData是阿里資料中臺非常核心的內容，其有一個Dataphin引擎，可以實現資料標準規範定義、資料模型的自動化開發、主題式資料服務即時生成等功能。

具體如下面這個片子所示，其包括資料引入-規範定義-資料建模-資料外部關聯-資料資產沉澱-資料服務生成整個閉環鏈條，通過這一鏈條把資料管理的大多要素都實現了。

這種強規範性的開發模式在一定程度上也降低了靈活性，但其規模效益是非常好的，否則阿里這麼龐大的資料資產是根本無法很好管理的，這個筆者深有體會，正如我們運營的DACP一樣，我們遭遇到的，他們也一定遭遇到了。

指標標準化是筆者嘗試過的事情，因為當初深感重複開發的報表太多了，而通過指標標準化可以解決這類問題，這是報表做到一定程度後自然而然產生的想法，以下阿里的做法跟自己當初做的如出一轍，所謂殊途同歸。

（2）OneID

假設有一位使用者張三，在第一個手機上使用百度地圖， 在ipad上觀看百度愛奇藝視訊，在第二個手機上使用手機百度app, 在pc電腦上使用百度搜索，如何將同一個使用者在這些不同端的使用者資訊聚合起來呢？

跟運營商的天然的以手機號碼為唯一標識不同，網際網路公司的各類賬號ID要打通的挑戰是非常高的，ID-MAPPING是網際網路公司的一個核心技術，其需要確保各個領域蒐集的資料是可以整合和關聯分析的，沒有統一ID的支援，多樣化的資料集中起來分析是沒有意義的，這是另一種形式的資料孤島。

比如下面的四條使用者記錄實際上表明的是同一個人。

（3）OneMeta

這裡的“資料資產分析”和“資料血緣跟蹤”在前面的“資料資產管理IPaaS”都已經提及，是資料管理裡非常基本的東西，特別提下資料綜合治理。

安全：指的是諸如敏感資料分級和訪問控制定義。

質量：指的是資料的質量規則定義。

成本：指基於資料資產的呼叫情況和處理成本給出一個綜合評估。

人員：大概是資料資產指歸屬組織和個人的定義吧，比如我們的資料字典裡就有一個屬性，必須標識出這個資產的建立人、修改人以便跟蹤追責。

（4）OneService

主題式資料服務：應該是基於元資料構建的簡單資料服務查詢引擎，面向業務統一資料出口與資料查詢邏輯，遮蔽多資料來源與多物理表，就是搞一套業務化的偽SQL方便取數。

統一而多樣化的服務：一般查詢指普通SQL查詢，OLAP就是多維分析，線上服務比較抽象，筆者猜測是諸如資料推送、定時任務等定製化服務形式。

跨源資料服務：大資料由於技術元件非常多，不同的資料往往儲存在不同的資料庫內，比如hadoop，gbase，oracle等等，如果要進行跨異構資料庫的即席查詢一般就要做先做資料匯聚，但一些輕量級的取數希望能直接進行關聯分析得到結果，因此出現了這種服務訴求。

PPT就解讀到這裡，筆者最大的感受就是阿里的資料中臺技術體系很龐大，但又非常關注細節，幾個字看著簡單，但落地則需要付出巨大的代價，而且是個漸進的過程，比如Dataphin。如要要了解阿里資料中臺的更多技術細節，推薦一本書《阿里巴巴大資料實踐》。

其實資料中臺要搞好不是簡單的引進幾個工具就可以了，技術僅僅是技術，你能COPY技術但COPY不了管理和文化，而這恰恰是資料中臺成功的關鍵。

資料中臺的更大挑戰是：你的企業對於資料的理解是否已經達到了一定的階段，你是否能夠驅動公司去建立一套適合自己企業的資料管理機制和流程，而這個是最難的，你得走出自己的路。

 

本文作者：隱林

原文連結

本文為雲棲社群原創內容，未經