讀透《阿里巴巴數據中臺實踐》，其到底有什麼高明之處？

最近阿里巴巴分享了《阿里巴巴數據中臺實踐》這個PPT（自行搜索原始文章），對於數據中臺的始做俑者，仍是要懷着巨大的敬意去學習的，所以仔細的研讀了，但願能發現一些不同的東西。

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

固然，不少寫PPT的用詞沒這麼嚴謹，臨時造概念的很多，或者是獨特的說法，所以有時候還要作一些揣測，結合本身的實踐去理解，這篇PPT的解讀有6000多字，所以請作好燒腦的準備，雖然筆者沒去現場聽演講，但但願個人「演講」也能讓你學到真功夫。

就讓咱們開始吧。

一、題目和背景

看到這個片子的出處，阿里雲智能事業部，實際上是有點奇怪的，記得阿里的中臺事業羣包括搜索事業部、共享業務平臺、數據技術及產品部，阿里雲是一個側重雲業務的平臺事業部，它來講數據中臺合適嗎？

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

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

固然講PPT的能夠不問出身，能理解阿里的數據中臺就能夠了。

二、DT派向左，IT派向右

傳統的IT是成本中心，而有了數據後，就可能成爲價值中心，這個價值體如今：在管理上能夠提供決策支持，在生產上能夠提供與管理匹配的智能工具，也就是提高生產關係和生產力的適配能力。

這一點提得是不錯的，好比浙江移動大數據中心就是直接定位爲利潤中心。

這裏的IT和DT的對比就不太合適了，二者不是對立的關係，而是融合的關係，D經過IT造成DT，好比原來IT渠道系統僅受理業務，如今在受理的場景下能夠加載基於數據的智能推薦。

DT只是馬雲提得一個突出數據價值的抽象概念，不能生硬去的理解，如今中國移動提了一個三融概念：融合，融通，融智，我以爲IT和DT就要增強融合融通，融合就是搭在一塊兒賣，融通就是能力共享，IT中有DT能力，DT中也要有IT能力。

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

三、企業組織對於DT的但願

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

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

一是經過數據發現問題，而不是拍腦殼。

二是業務人員要既懂業務也懂數據，甚至能本身DIY數據和模型。

三是數據要嵌入生產流程中直接發揮做用，好比標籤庫要成爲營銷目標用戶的發起地，風控模型要嵌入在用戶操做流程中等等。

第一點你們都在作，實際仍是以經驗爲主，數據只是參考和佐證，這種模式本質上沒有改變。第二點，第三點執行到位對於大多數企業都很難。

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

一是「數據多跑路」是智能平臺的核心，浙江的「最多跑一次」就是要靠數據和平臺整合實現這個目標。

二是IT人員要有數據化的思惟，這個提的很好，缺少數據思惟的人設計IT系統不多考慮智能，如今不少企業的受理系統跟推薦系統是二者皮多少有這個緣由。

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

四、大中臺、小前臺

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

業務數據化：就是全部的商業活動都應該記錄下相關的數據，這是業務中臺應該承擔的使命。

業務數據化挑戰其實很大，之前業務平臺在設計的時候，是以功能和流程爲核心的，只記錄對於要實現功能和流程必需的數據，其餘的就無關緊要了。

好比運營商的一些信令日誌記錄不全面致使可能影響後續的網絡分析或數據價值變現，這就沒有作到業務數據化。

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

數據團隊的一個使命就是業務數據化，不少好的數據是你進入前端爭取來的，這樣才能驅動業務記錄數據。

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

數字孿生這個詞如今也比較熱了，將來萬物互聯的世界將你全部的行爲實時記錄下來，造成另外一個數字化的你，這就是數字孿生，若是業務中臺是你，那數據中臺就是你的兄弟。

五、數據中臺賦能的四大典型場景

（1）全局數據監控：本質就是指標+報表+可視化，這是給管理者看得，固然業務人員也要看，如下給了雙11大屏示例。

（2）數據化運營-智能CRM：提到要「基於全鏈路全渠道數據的創建以「人」爲核心的數據鏈接萃取管理體系，對用戶進行全生命週期的精細化管理」，這麼多形容詞懵不懵逼，到底在說啥？

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

全渠道就是各觸點的用戶行爲數據，好比天貓、淘寶、優酷等等。

所以，經過匯聚全鏈路全渠道的數據才能造成完整的客戶畫像，而後用鏈接萃取的方式方便的得到所需的數據進行分析，從字面意思看跟咱們的標籤庫定位有點像。

（3）數據植入業務-智能推薦：這裏講的比較清楚，就是營銷閉環管理，從用戶細分，千人千面，渠道推薦，再到營銷評估，如下是示例。

（4）數據業務化-生意參謀：這個是阿里力推的爲數很少的血統純正的數據產品，是數據業務化和數據直接變現的典型表明，能夠爲店主提供端到端的分析支撐，網上介紹不少了，下面這張片子着重說明了生意參謀的歷史，如今和將來，有點意思。

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

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

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

爲何說血統純正呢？

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

六、阿里巴巴作數據中臺的緣起

作數據中臺的緣起跟通常數據倉庫融合模型是同樣的，共享複用的須要，好比原來基於淘寶數據的各類業務都自建一套中間層，而這些中間層不少是重複或相似的，好比螞蟻業務有交易主題，天貓也有交易主題，那能不能抽象出公共的交易主題爲兩個業務都服務呢？

所以你會看到阿里數據中臺抽象出了會員、商品、交易、瀏覽、廣告等公共核心主題層，從而爲應用層服務，各個應用層之前要作不少公共層的東西，如今也能夠徹底複用了，理論上能夠提高應用構建的速度。

下面這頁片子從數據的依賴關係圖比對了先後的變化，一個是網狀的，表明了相互之間千絲萬縷的關係，冗餘確定是不少的，一個是放射狀的，一個節點能夠爲更多的後端節點服務，表明了共享和簡潔。

七、阿里巴巴數據中臺全景圖

讀懂這張圖就理解了阿里的數據中臺具體到底幹了些什麼，有五大部分跟數據中臺直接相關：數據中臺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）:以數據倉庫整合計算好的數據做爲數據源，對外經過接口的方式提供數據服務。

八、阿里巴巴數據中臺的沉澱與積累

（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不了管理和文化，而這偏偏是數據中臺成功的關鍵。

數據中臺的更大挑戰是：你的企業對於數據的理解是否已經達到了必定的階段，你是否可以驅動公司去創建一套適合本身企業的數據管理機制和流程，而這個是最難的，你得走出本身的路。

本文做者：傅一平

原文連接

本文爲雲棲社區原創內容，未經容許不得轉載。