? ? ? ?導讀：2015年以來，“數據中臺”已經成為了一個爆款詞匯，也經歷了2020年阿里“拆中臺”的問題，今天主要從科普和企業實踐兩個角度來介紹一下數據中臺。本次分享題目為《數據中臺底層邏輯》，主要介紹：

? ? ? ?什么是數據中臺

? ? ? ?為什么需要數據中臺

? ? ? ?數據中臺的原則

? ? ? ?數據中臺實踐

? ? ? ?01什么是數據中臺

? ? ? ?2015年，馬云老師去芬蘭一家游戲公司supercell考察，這家公司人數不到200人，但是卻成為2015年全球營收最高的游戲公司。它曾推出《部落沖突》（Clash of Clans）、《海島英雄》（Bomb Beach）、《卡通農場》（Hay Day）和《皇室戰爭》（Clash Royale）。為什么人數不到200的supercell，在2015年可以成為全球營收最高的游戲公司呢？通過組織能力的發現，它的組織架構和一般的組織架構不同，傳統的組織架構是從CEO到市場、經營、運營、產品、技術等部門的形式，但是supercell呈現的是一個從中臺發散再到各個部門的形式。國內也有類似的模式，如字節后來建立了自己的數據中臺、增長中臺、營銷中臺等等，以中臺式來支持一個APP工廠進行快速地迭代、試驗和審核。

? ? ? ?阿里數據生態的變化經歷了13年之久。最早可以追溯至2007年，阿里的“遵義會議”后，確定了阿里是一家數據公司。2014年，阿里確定數據上云，此時的阿里，無論是從思想儲備還是技術儲備上，都已經達到了數據中臺儲備的要求。2015年，馬老師去芬蘭supercell公司考察，年底便成立了阿里中臺事業群。到了2020年，出現了一種“中臺是毒藥還是救命稻草“的爭論觀點，逍遙子在阿里內網說中臺沒有達到預期，希望“中臺變薄”。大家可能會覺得中臺被妖魔化了，也不太被需要了，但我更想說的是，我們當初建立中臺的時候，其實是根據企業自身的目標和原則來建設的，自然不會因為中臺的污名化就將其舍棄。

? ? ? ?那什么是數據中臺呢？從阿里的視角來看，開始的數據開發是煙囪式的，比如淘寶、天貓、1688，但這種開發不能支撐整體的數據運維，后來就變成了由共享數據，從商品、品類、價格、用戶、交易、評價等以中臺為所有業務線進行數據支撐的方式。

? ? ? ?阿里的數據中臺的定義是：方法論?+ 組織 + 工具

? ? ? ???方法論：OneID+OneModel+OneService

? ? ? ???組織：從 IT 支撐到業務賦能的數據、技術、產品相匹配的人才結構，包含數據產品經理、數據研發、數據科學家等多角色

? ? ? ???工具：采集、構建、管理、服務等

? ? ? ?廣義上，數據中臺是指通過數據技術，對海量數據進行采集、計算、存儲、加工，同時統一標準和口徑。

? ? ? ?我從網上找了一些阿里的中臺圖，事實上中臺并沒有一個準確、統一的概念。但是從圖中可以發現，OneData和OneService是一直存在的。從我的經驗和對中臺的理解來說，OneData覆蓋的范圍包括數據源的統一整理、數據開發和生產、數據模型創建和指標口徑的統一。OnePlatForm是以產品形態中臺式的建立提供工具給業務方使用。OneSevice更多的是提供API接口，將血緣、引擎、API綜合式的從中臺提供能力給到業務方的各個平臺，包括數據平臺、交易類平臺等。

? ? ? ?02為什么需要數據中臺

? ? ? ?為什么需要數據中臺？數據中臺主要是解決以下5個問題：

? ? ? ?指標口徑不一致。阿里在建設中臺之前有三萬多個指標，這些指標存在命名相同定義不同的問題。例如DAU（Day Active User），Day的定義可以是0-24時的自然日，也可以是類似2點-2點這種ETL開始數據調度的日期，像一些海外新項目，不同的地區屬于不同的時區，也會有不同的時間。所以DAU對于不同的崗位視角或者業務視角，Day的定義也有所不同。又如Active的定義，可能以下載一個app為口徑，可能是注冊下載，可能是注冊手機號之后的行為，可能是打開app等等為口徑，這種就會造成口徑不一致的現象。

? ? ? ?數據重復建設。數據重復建設主要包括兩種情況，一種是數據中臺類型和業務型小中臺會出現很多數據重復性建設的問題，另外一種是業務線上不同崗位的人，比如數據PM和商分會進行重復性的數據建設，從商分的工作習慣來說，他們會進行很多多口徑實驗，對數據產出、更新迭代以及維度指標的要求比較豐富，而數據產品不能立刻滿足他們的需求，所以便導致了這種常見的重復性建設問題。

? ? ? ?取數效率低。一般大廠都有幾萬張的表，不同的表從ODS層到APP層各分布在不同的層級，這樣便造成了信息的不透明不對等，從而導致取數效率低。比如想要取一張ODS層的表，然后再到一張APP層的表，二者的容納項可能有非常大的差異，所以就造成了取數效率低下的問題。

? ? ? ?數據質量差。由于多煙囪、多崗位、多部門式情況的存在，導致數據無法全鏈路勾連，不能成為全鏈路中的一個血緣，因此必然會產生數據質量差的問題。

? ? ? ?建設成本高。上述問題導致了數據在計算、存儲上建設成本高的問題，可能不同部門的人都需要從頭到尾了解研發流程的每一個細節，其中的坑每個人都會踩一遍，浪費研發人員的時間精力成本。而且在沒有規范管理標準的情況下，也會存在數據表層次力度不清晰的問題，為數據存儲帶來巨大的成本負擔。

? ? ? ?基于此，數據中臺是一個比較好解決這些問題的策略。

? ? ? ?下面是一個數據中臺解決問題的例子，對于大型公司來說，一般形成了數據中臺、業務數據支持、業務前臺三者之間的勾連關系。

? ? ? ?數據中臺可以解決一些問題，包括數據來源一致問題，例如日志型數據、DB型數據、文件上傳型數據和SDK數據；建設口徑一致問題，例如可以通過一些建模型的產品工具、指標元數據管理產品來保證建設口徑一致；同時可以通過技術引擎和存儲管理的迭代來降低存儲成本。

? ? ? ?中間層是業務數據支持，它可以保證業務口徑的一致，例如保證原生指標、派生指標、衍生指標達到業務口徑的一致性以及流程的順利運轉；計算邏輯一致，例如渠道指標和維度達到計算邏輯的一致；提升取數效率，通過SQL、看板還是分析效率型工具來實現取數效率的提升。

? ? ? ?業務前臺雖然不直接參與數據建設，但是可以從數據指標搭建、提升分析效率兩方面提高數據的使用情況，同時可以從B端或者C端視角對整體的數據鏈路形成反饋。

? ? ? ?03數據中臺的原則

? ? ? ?不是所有的企業都適合建設中臺，如果企業具有下述三點特征，可以嘗試建設數據中臺：

? ? ? ?企業有較多數據應用的場景（3+）。3+以上會出現重復性數據建設的問題。例如一家新零售或者電商公司，它有許多不同的部門，可能包括2C、2B甚至2G，通過建設數據中臺，可以實現用戶表、區域表、用戶畫像標簽的打通，比較適合數據狀態性的建設。

? ? ? ?企業有效率、質量和成本的壓力。數據中臺是解決數據計算、引擎、存儲壓力的有效方式，如果公司有效率、質量成本壓力，是適合建設數據中臺的。

? ? ? ?企業面臨經營困難/高速增長/數字化轉型，需要通過數據實現精益運營。傳統的OA或CSM系統不能實現數據打通，而且數據量比較有限，數據中臺可以通過Hadoop、MapReduce來運營更大量級的數據。

? ? ? ?數據中臺的組織原則：

? ? ? ?原則一：五指成拳，核心資源給到核心項目。數據中臺不太適合業務上的賽馬邏輯，因為它本質上是一個不產生效益的職能型部門。業務上一般是RD、算法、工具、數據十八般武藝都會一點，而中臺同學，尤其是RD，需要對資源、引擎、數據、算法專業分門類研究得細致入微，所以它不應該采用賽馬邏輯，而是核心資源給到核心項目，采取每個同學在自己的方向上精進的邏輯和原則。簡單來說就是自己不要卷起來。

? ? ? ?原則二：通用平臺而非BP制。BP制容易向某一個業務傾斜，導致中臺不能復用，而中臺強調通用性。

? ? ? ?原則三：不能急功近利，朝令夕改。作為中臺的領導者或是策略的制定者，不能急功近利、朝令夕改。由于中臺職能型的性質以及員工的分門別類，中臺其實是一個“慢工出細活”、“老火燉雞湯”的一個部門，可以以半年或一年為粒度，在技術和產品上做一些引領性的東西，達到賦能業務的目標。

? ? ? ?數據中臺的方法論原則：

? ? ? ?onedata，“一個生產”。從數據源，到數據建模，到指標維度口徑，對數據進行打通形成的全鏈路就是onedata。

? ? ? ?onemeta，“一個資產”。數據建設完成后，如何進行數據管理、數據地圖，方便各個業務線進行數據查找；數據作為一個不停計算的資源，如何進行管理；數據如何進行下線。這些維度都是onemeta的覆蓋范圍。

? ? ? ?onesevice，”一個服務“。即把不同的引擎技術能力通過API的形式為業務賦能。Onesevice是數據中臺正在探索、實驗的項目，不同的公司在onesevice的進展上有所差異，但是onedata和onemeta是比較成熟的。

? ? ? ?數據中臺的技術原則：

? ? ? ?數據中臺的建設一般包括四個模塊，通常是“三橫一縱”的架構。“三橫”自下而上分別為數據接入、數據開發和數據應用。數據接入包括日志接入和業務數據接入。數據開發分為離線/實時數倉開發、數據測試、數據監控與質量監測。數據應用是最上層，例如A/B測試產品。“一縱”是數據管理產品，包括元數據管理、資源管理、資產管理、數據治理和數據安全。

? ? ? ?04數據中臺實踐

? ? ? ?數據中臺建設中onedata比較復雜，存在一些通用性的痛點，可以從來源、口徑、規范三個方面來看。

? ? ? ?來源：導致來源和計算邏輯不清。

? ? ? ?口徑：包括口徑相同、口徑不同、口徑描述不清晰三種情況。口徑即誰創建的？誰以什么邏輯創建的？誰以什么邏輯在什么時候創建的？

? ? ? ?規范：

? ? ? ?口徑相同，命名不同，例如，電商和銷售領域有訂單核銷券和訂單關閉券兩個定義，不同的業務線二者的定義是相同的，都是下單之后訂單被接收且沒有退單的情況，但是容易誤認為兩個指標是不同的。

? ? ? ?口徑不同，生產者不同，例如，口徑是不同部門建設的，還是相同部門不同崗位的人建設的？口徑生產者不同，邏輯就會難以追溯。

? ? ? ?口徑不同，描述事件相同，例如，描述的都是消費券，但是消費券是否被核銷沒有被注明，也會造成口徑不同。

? ? ? ?口徑描述不清晰。例如DAU指標，如果沒有對Day、Active和User進行準確的描述，也會造成口徑問題。

? ? ? ?針對onedata的困境，對問題進行抽象，分別從來源、口徑和規范層面進行修復。

? ? ? ?來源：劃分業務線—主題——指標維度

? ? ? ?口徑：維度與指標的業務描述和使用場景

? ? ? ?規范：

? ? ? ?命名規范：eg原子指標和派生指標

? ? ? ?組織與生產規范：生產流程、審核流程、授權流程、治理流程

? ? ? ?下面舉例說明onedata的實踐。

? ? ? ?來源：業務板塊為電商業務；電商通常分為人、貨、場，或者是用戶域、交易域、商品域，該案例的數據域即交易域；業務過程是支付；修飾類型是專場/商品，時間周期分為實時、離線和維度指標（日、月、季、年等），此處為實時；修飾詞為單個專場和單個商品；此處的原子指標是銷售件數，派生指標為近7天所有專場的爆款率，度量為支付件數。需要注意的是，在指標管理里面可以區分原生指標和派生指標，因為它的輸出是業務線上的看板數據，但是對于平臺BI類分析型產品，不建議有原生指標、派生指標、衍生指標這種概念，容易造成指標膨脹，建議通過用戶宣導來進行維度的分組或過濾，直接提供原子指標和清晰的維度，方便用戶理解。維度即專場商品，屬性為商品ID和專場ID。

? ? ? ?命名規范：派生指標=原生指標+時間周期+其它修飾詞，例如會員有黃金、白金、黑金等修飾詞，就會產生派生指標。

? ? ? ?組織與生產規范：業務方提出需求，然后進行業務調研、需求分析和數據探查，需求一般來自于業務線上的運營、產品和分析師；確認需求指標和指標口徑之后，對指標的規范進行定義，構建一致性維度、一致性度量和指標，這個過程通常由業務線上的數據PM或數據接口人實現；需求受理之后，進行模型明細設計，構建一致性維度和事實表，同時構建統一指標匯總表；進而完成代碼開發、部署、運維和數據應用，最后可以應用于報表、OLAP分析應用或者自主查詢分析，這個過程由數據中臺的數據PM來完成。

? ? ? ?05總結

? ? ? ?數據中臺是通過數據技術對海量數據進行采集/計算/存儲/加工，同時統一標準和口徑的部門。

? ? ? ?如果你有指標口徑不一致，數據重復建設、取數效率低、數據質量差、建設成本高等問題，數據中臺是解決這些問題的良藥。

? ? ? ?數據中臺仍舊適合至少3條業務線/有降本增效需求/長期有耐心的公司。

? ? ? ?數據中臺的組織三原則/方法論原則和技術原則。（集中資源/非bp/不急功近利）

? ? ? ?最后，建議數據中臺還是要為業務部門提供價值，核心問題就是效率、質量和成本的問題。