數據中臺的概念已經出現了好幾年，而到目前，互聯網企業、IT軟件企業等企業都推出了自己的產品與戰略，進軍數據中臺領域。怎么理解數據中臺及其產品形態呢？這篇文章里，作者結合具體產品做了一定梳理和分析，一起來看。

一、歷史

1. 從世界大數據的角度去看

1991年，Bill Inmon出版了《建立數據倉庫》。也就是目前我們還是一直在使用的數據倉庫的概念。在落地方面，沒有準確的消息當時的技術是如何將大批量的數據入倉庫的，但是因為其非實時性質，應該不是問題，數據進倉之后再花一些時間去完成匯總層的計算。

2003年，Google公布了其內部處理海量數據的技術——分布式文件系統GFS、并行處理框架——MapReduce、高效數據存儲模型BigTable等等。這些促成了Hadoop的誕生，再后面是Hadoop的完善、更多的大數據相關開源項目的誕生，以致于每個場景都有了框架去使用，例如：Flink、Impala、Kudu、Kafka等等。

2008年~2011年，這期間是學術界對于大數據討論的繁榮時期，Nature、EMC世界大會、麥肯錫全球研究院、Gartner都在發表自己對于大數據的看法。大數據開始成為人們熱議的話題。

2011年以及之后，世界多國都將大數據作為戰略，更是推動了大數據的發展。

2. 從國家大數據角度去看

2014年開始探索大數據，并持續地去運用大數據，將大數據作為戰略，可見大數據的重要性。我想比較明顯的感受是一些政務可以在網上處理了，不一定要本人到現場辦理。

3. 從數據產品的角度去看

數據使用需要一種方式。

在久遠的年代或者是落后的企業環境里，我們還不會使用數據倉庫，只是使用數據庫去存我們的所有數據，但是這讓我們大量的數據難以完成計算，時效低。

到了數據倉庫的時代，開始使用數據倉庫去存和使用數據，使用效率開始有了較大的提升。

同樣是數據倉庫的形式，到了企業里面之后，隨著對于數據的管理實踐，漸漸總結出了數據平臺這個東西，可能是基于組織架構。

到現在，我們主要還是為了提升使用數據的效率，因而產生了數據中臺，這種高復用的使用和管理數據的方式。

4. 從數據中臺的角度去看

數據中臺的概念最早起源于2015年。

2015年，馬云在拜訪參觀芬蘭游戲公司Supercell時注意到該公司擁有一個強大的技術平臺來支持公司內部小團隊的游戲開發，從而各團隊可以專注創新，基礎且同質化的技術內容已實現共享支持。如果將這種思維轉化到企業治理中，則需要構建一個資源整合和能力沉淀的平臺，達到對不同部門進行總協調和支持的目的，數據中臺的概念由此誕生。

2016 年，阿里巴巴開始實施數據中臺戰略，通過構建創新靈活的“大中臺”、“小前臺”的組織機制和業務機制，實現管理模式的創新。

2017年，滴滴出行跟進了數據中臺戰略，并于同年12月分享了《如何構建滴滴出行業務中臺》的企業戰略。

2018 年，京東于12月宣布采用前臺、中臺與后臺的組織架構。

2019年，數據中臺建設規模開始迅速增長，傳統企業與創新企業均積極參與建設，同時，行業中涌現了一批以建設數據中臺為核心業務的創新業務服務商。

截至目前，互聯網企業、IT軟件企業、移動運營商及IT解決方案提供商均推出自己的產品與戰略，進軍數據中臺領域。

二、數據中臺的形態總結

1. 核心能力

我認為是強大的服務能力，能夠快速響應業務的需求。一般企業內的數據中臺并沒有數據業務化，也就是說數據中臺是不賺錢的，此時數據中臺扮演的角色是輔助業務決策。

而扮好這個角色就是業務有很多需求，數據中臺都能夠及時地消化，這是很難的，相信一定會有出現一個需求兩個月才完成的情況出來，從需求提出到產品梳理到技術開發到測試到驗收到上線，這是一個漫長的過程。

如果任何一個需求都是這樣去開發地話，完成業務的需求需要大量的人力，但這是難以做到的，企業需要考慮用人成本，而現在的技術成本是相當高的。那么數據中臺此時就是為提升服務業務的能力而生。

2. 架構

onedata和oneentity的理論的理論來自于阿里。經過我的其他一些認知結合，我對這2個方法論的認知如下。oneentity是數據的底層根基，作用在于打通數據。常見的數據打通是人的數據的打通，但實際上oneentity不僅僅指的是人，物也是需要打通的，也就是說需要對人或者物進行唯一標識。

通常一個人即是唯一的，此時常用的方法論是ID-Mapping。物的話，一個物可以是唯一的，但是如果是批量的商品，那么往往還會有唯一的型號，用以標識都是同一類型的商品。這樣后續需要統計商品的銷售情況時，可打通全域的數據進行全面的統計。

onedata指的是數據只存一份，口徑統一。所有的數據匯集到數據中臺，各個計算好的指標或者維度都是統一的，企業內的任何地方需要統計數據都是從這一份數據拿數據進行統計。

乍一聽感覺是比較簡單的一個方法論，但是在實踐的過程中不好將所有的口徑進行統一，因為各個業務線對于口徑都有自己的看法。然而，我認為盡管如此，我們還是可以制定出公認的標準的口徑，這樣的話高層在看數據的時候就不至于因為多口徑而誤解了數據，至于那些個性化的口徑可以使用某個規則將盡可能多的個性化口徑覆蓋，還有部分個性口徑實在沒有辦法覆蓋則為之創建特定的表去計算。

3. 核心邏輯

1）關于oneentity

關于人，我曾寫過一個相對詳盡的ID-Mapping的方案，在此不再贅述，邏輯比較復雜。

關于物，這個的邏輯比較簡單，主要就是物都經過中臺，帶有唯一標識，所帶的標識將會去到訂單、行為日志等等數據里，這樣的話，便可基于唯一標識去打通全域的物體。而這個事情通常是由業務中臺去做，數據中臺再基于業務中臺的數據去統計。

2）關于onedata

在過去我們建設數據倉庫總是先有數據分析需求，然后才是ETL工程師去設計數據倉庫并進行開發。我認為了解業務，從業務的角度去建設數據倉庫會是更好的做法。

兩種做法得到的結果的區別在于業務的附加程度是不一樣的，前者可以說基本就是基于技術的角度去設計數據倉庫的，可能會造成之后的修改或者不斷的新增更多相似的表，單點的開發并不會考慮更多的事情，基于需求能夠完成需求即可。后者則是在充分了解業務的情況下，以俯視的視角去進行設計，考慮到業務的情況，之后有更多的其他的數據時，不需要頻繁新增表或者改表，而是在良好的表基礎上進行擴展——簡單理解就是加字段。

這樣的設計背后的邏輯常常是基于主流程主數據考慮的。我們會梳理出主流程，并在主流程中找到我們認為重要的主數據，然后基于主數據進行標簽或者指標的設計。

而這些標簽/指標將依附在我們的表中。每一張表其實代表的是主數據的一個分類，而主數據是這個分類的根節點。如下例子所示，用戶是主數據，是根節點，注冊信息是分類或者可以叫它子節點（對應的是我們的表），而首次注冊的APP、首次注冊的渠道則是樹節點（對應的是我們表中的字段）。當然這個樹結構可能沒有這么簡單，根據企業的實際情況建立樹結構。

4. 落地

• 標簽體系設計：主要是產品或者是資產設計師建立標簽體系，相當于給技術提需求。這里的標簽可能是指標也可能是標簽。
• 標簽同步與加工：需求到了技術時，當技術完成開發后，需要將相關的元數據同步回到系統。
• 標簽管理：產品/資產設計師對于標簽的管理，從標簽的上架到下架。
• 標簽門戶：標簽的展示，相當于標簽超市。
• 標簽應用：各種服務組件，也就是各種各樣的功能。

因為我曾寫過一篇比較詳盡的文章描述這個落地方法，在這里就不再贅述了。

5. 行業情況

2019年被稱為數據中臺元年。單從數據來看，目前，我國數據中臺行業已經從萌芽發展階段轉換到高速發展階段。根據艾瑞咨詢數據，數據中臺市場已從2018年的17億元增長至2020年的68億元，三年CAGR為100%， 到2023年，數據中心市場規模有望達到183億元，五年CAGR可達到48.1%。

雖然數據看起來不錯，但是置身于這個行業會發現很少真的將中臺的所有能力都標準化出來的軟件服務商，大多應該都還是提供咨詢服務，走的是項目制。

這里的數據中臺其實應該更多指的是數據產品，并不是企業自建的那種厚重的中臺，很少聽說企業會將自己的所有數據都放在一個外部的平臺上，大多數時候都是某個產品使用某個數據平臺。而且由于中臺的復雜性，標準的組件一般難以滿足需求。

那到底復雜在哪里？或者說并不是復雜，而是企業的所有數據不會都交由第三方處理，所以現在的數據平臺一般都是提供比較簡單的標準化的功能，像用戶行為分析、用戶畫像、智能推薦等等。

從大數據企業的排行榜來說，深耕這個行業的SaaS公司似乎比大廠更有競爭力，在前30的榜單上沒有看到大廠的身影。

另外，在數據行業，不管什么公司，大多產品都以服務業務為導向，以業務價值為導向，不再片面地追求厚重的中臺，更加聚合的理想的中臺，反而順應企業的發展情況，一般而言中小公司都是不太注重建設厚重的中臺，反而希望能夠更輕量地實現需求，可能實現地沒有那么完美，但是應該是低成本的不需要影響到公司級別的員工去配合。

我也在這段時間里從希望能夠比較理想地建設中臺到更加希望服務業務為主，至于是否非常規則高級地實現是次要的。至于如何輕量地實現，按我的理解是不去大改目前的情況，以間接地小改去實現需求。

三、行業產品分析

1. 分析的目的

我們僅是從產品的角度去分析各個廠商做出來的產品是什么樣的，有什么可借鑒可學習的地方。

2. 競品的選擇

神策、巨量引擎、友盟。神策是我比較關注和常用的數據產品，在業界比較出色。巨量引擎是今年接觸到的字節產品，是一個比較新的產品，我比較喜歡它的架構。友盟則是老牌大廠的一個產品，用以對比。

3. 架構

神策：

火山引擎：

友盟：

總結：

總的來說，這樣的架構是符合典型的業務流程的。

• 先通過廣告進行引流。
• 當流量來了之后，對其進行行為分析、畫像分析。不知不覺中進行智能推薦，千人千面地進行觸達。
• 每次觸達都需要使用內容，因而也就有了內容管理，追蹤轉化的內容歸因。
• 當客戶有了潛力之后可能就進入客戶管理系統中。
• 涉及到比較復雜的情況時，就需要進行A/B測試。

實際上這樣的架構還不是一定的，只能說比較相似，神策與巨量引擎的比較相似，友盟咋一眼看上去不相同，但實際是相似的，只是功能的結構不一樣。友盟相比其他的，多了很多分析的模型，在很多的分析模型上加上一些常規功能，例如畫像、用戶行為分析，最后組成了一整套的解決方案。

四、我的認識

1. 中小企業表面臨的一些困境

企業數據氛圍不夠：大多數企業已經在倡導數據說話，但是對于數據的認識不夠，就像一個初級的數據使用者，對于數據的理解停留在比較表層，拋出幾個簡單的數據，然后就草草完成結論。這是司空見慣的。這樣的情況，導致這些數據本就是比較基礎的，業務自己就可以完成數據統計，根本就用不上大數據，大數據被晾在了一邊。

業務疲于完成kpi：如果大數據試圖去引導業務去使用更細致的數據，此時在糾纏下可能輸出了一個方案，但最后很可能效果并不好，業務可能看了幾次就放棄了這個功能。有人可能會懟說，這應該是你們產品的責任，需求都沒確認好?？墒钱a品確實是與業務確認過了才開發的。責任問題有點難以判定得很清楚，但是我分析一個比較重要的點是因為業務不太在意這個事情，可能是被推著去做的這么一件事情，口里雖認同，心里則不然。另外，業務更在意完成kpi，因此可能對你的方案并不太上心，不想花太多的時間去處理。

功能影響范圍大：如果每一個功能的影響范圍都覆蓋全公司，那么大數據系統可能很難以迭代起來，推動的成本會很高。此時更優的方案是，先做出一個功能盡管只有一個部門使用，但其實這個功能是通用的，未來其他部門要是合適用也可以用。

人才缺失：大數據的人才也是數據平臺建設的關鍵一環。其是否有寬闊的眼界，能否搭建一套良好的產品架構，滿足未來的需求，是影響一個系統能否走向更好的關鍵因素。此時更建議大數據人才能夠了解行業的各種做法，取長補短，吸收行業的先進思想應用起來。

一般而言，高層對于數據的理解是比較透徹的，只是一線員工不是都能到達這個層面。如果有一些不好推動的事情，可以找高層推，這個基本是最優的方法。

2. 關于產品架構

其實產品架構不是固定的。我們可以參考現在的經典的架構就是如上所述。但就企業內部而言，我覺得可以是這樣的。

標簽平臺：對于標簽的管理，也是數據資產的管理，可以讓數據像商品一樣上架到超市供業務取用。

指標平臺：統一的一套指標體系，在此標簽體系上進行擴展。

用戶行為分析：常規。

用戶畫像：常規，但我們要思考得更加深入，不能只做靜態的標簽，也要做動態的，而且要充分利用模型，盡量不要買了什么商品就一直打上這個商品的標簽，其實這樣的做法是比較粗暴的。

舉個例子說，今天我買了一個籃球就表示我喜歡籃球嗎，不是的，可能我只是給弟弟買，或者班級買等等，我們要充分考慮各種情況再給用戶打標簽，再深入思考一層，用戶的興趣也是有可能減退的，可能今年我喜歡打籃球但是明年就不一定了。

廣告分析：常規。

內容管理：在這個內容為王的年代，只要你的內容能夠吸引流量，那就有很大的機會轉化。因此對于內容的管理能夠識別出最優的內容，幫助企業做出更好的選擇。

智能推薦：千人千面的，無時無刻不在創造客戶轉化的機會。

觸達：這個非常重要，可以是運營人工設置一次觸發，也可以是一個流程畫布，根據用戶的行為路徑進行一系列的觸達。

看板：常規。

總而言之，還是要多思考深入一點，這樣才能挖掘到更多的轉化機會。不局限于一般的營銷手段，可以大膽地采用算法模型給業務賦能，不局限自己的想法，多參考業內先進的思想。

3. 參考資料

• 《阿里巴巴云上數據中臺之道》
• 中國信息通信研究院
• 國泰君安證券研究
• 華泰研究
• 《標簽類目體系》
• 艾瑞咨詢
• 德本咨詢
• 火山引擎
• 神策
• 友盟