最近阿裡巴巴分享了《阿裡巴巴資料中台實踐》這個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不了管理和文化，而這恰恰是資料中台成功的關鍵。
資料中台的更大挑戰是：你的企業對于資料的了解是否已經達到了一定的階段，你是否能夠驅動公司去建立一套适合自己企業的資料管理機制和流程，而這個是最難的，你得走出自己的路。
作者：傅一平 （微信号：fuyipingmnb）
歡迎加入“MaxCompute開發者社群2群”,點選連結申請加入或掃描二維碼
https://h5.dingtalk.com/invite-page/index.html?bizSource=____source____&corpId=dingb682fb31ec15e09f35c2f4657eb6378f&inviterUid=E3F28CD2308408A8&encodeDeptId=0054DC2B53AFE745