阿里提出了“大中臺，小前臺”，其中臺事業(yè)部包括搜索事業(yè)部、共享業(yè)務平臺、數(shù)據(jù)技術及產(chǎn)品部，數(shù)據(jù)技術及產(chǎn)品部應是數(shù)據(jù)中臺建設的核心部門。
那么，數(shù)據(jù)中臺到底是什么？具體包含哪些內(nèi)容？跟大數(shù)據(jù)平臺是什么關系？在架構層面是怎么體現(xiàn)的？數(shù)據(jù)中臺跟產(chǎn)品又有什么關系？
阿里數(shù)據(jù)技術及產(chǎn)品部的掌門提倒了數(shù)據(jù)中臺的具體含義，這里引用他說的話：
“很多人會把數(shù)據(jù)比作“石油”，馬老師（馬云）也說過，阿里巴巴要成為全球電子商務的“水電煤”。我們現(xiàn)在搭建的數(shù)據(jù)中臺，就是希望扮演“發(fā)電廠”的角色。”
“我們知道，電力的發(fā)展可以分為幾個階段，最開始是一些有能力的企業(yè)自己發(fā)電，后來出現(xiàn)新的工業(yè)產(chǎn)能，有的企業(yè)電用不掉，有的卻不夠用，這時候國家機構就出來了，會去搭建國家級的電網(wǎng)，不管是核能發(fā)電，還是風力發(fā)電、水力發(fā)電，最大程度地保障不同群體的用電需求。”
“我們數(shù)據(jù)中臺也是這樣一個運轉思路，我們落到實處是一個倒三角形，從下往上分為四個部分——”
“第一是數(shù)據(jù)技術。沒有數(shù)據(jù)中臺的時候，不管是阿里內(nèi)部還是各商家，大家都有自己的數(shù)據(jù)中心、機房、小數(shù)據(jù)庫。但當數(shù)據(jù)積累到一定體量后，這方面的成本會非常高，而且數(shù)據(jù)之間的質(zhì)量和標準不一樣，會導致效率不高等問題。因此，我們需要通過數(shù)據(jù)技術，對海量數(shù)據(jù)進行采集、計算、存儲、加工，同時統(tǒng)一標準和口徑。”
“第二是數(shù)據(jù)資產(chǎn)。數(shù)據(jù)中臺把阿里系的數(shù)據(jù)統(tǒng)一之后，會形成標準數(shù)據(jù)，再進行存儲，形成大數(shù)據(jù)資產(chǎn)層，進而保證為集團各業(yè)務和商家提供高效服務。”
“第三和第四都是數(shù)據(jù)服務，包括服務商家和服務小二。例如生意參謀和阿里指數(shù)，就是數(shù)據(jù)中臺中面向商家端提供的數(shù)據(jù)服務。”
“數(shù)據(jù)中臺服務阿里，說白了更多是在為各位商家服務。平臺會確保大家在使用數(shù)據(jù)的過程中，口徑、標準、時效性、效率都有保障，能有更高的可靠性和穩(wěn)定性。”
以上說得好像都對，但邏輯上有些是無法自洽的，比如這里的數(shù)據(jù)技術跟阿里云的數(shù)據(jù)技術是什么關系？數(shù)據(jù)中臺要不要承擔hadoop/ETL這類平臺和工具的研發(fā)？生意參謀是個端到端的產(chǎn)品，似乎不能劃為數(shù)據(jù)中臺？
當然，從職能看，作為中臺部門的確需要基于產(chǎn)品直接服務一線客戶，而不是往后退，這也是以前筆者對于數(shù)據(jù)中臺最大的困惑，一直在想這個數(shù)據(jù)中臺的部門績效該如何定呢？沒有業(yè)務的滋養(yǎng)中臺如何迭代優(yōu)化呢，阿里算是解惑了。
但如果把直接的產(chǎn)品當成中臺顯然是不合理的，阿里提了數(shù)據(jù)中臺，忙壞的倒可能是那些做數(shù)據(jù)架構和數(shù)據(jù)管理的，因為架構講究邏輯嚴密，本質(zhì)和邊界必須定義清楚，沒有歧義，否則做事就會很茫然，不知道該怎么入手。
比如哪天領導問你，我們企業(yè)的數(shù)據(jù)中臺有沒有，要向阿里學習啊，有了清晰的概念你就可以做映射了，否則就會顯得手足無措，這種事情其實很多。
筆者的企業(yè)最近在做IT規(guī)劃，很多人就對數(shù)據(jù)中臺要帶一些產(chǎn)品職能有異議，記得以前筆者還把營銷平臺當成中臺，號稱也是賦能所有營銷人員的，這就是概念不清造成的問題。
說來也奇怪，網(wǎng)上很難找到數(shù)據(jù)中臺的更科學解釋，能找到的大多也不夠清晰，與大數(shù)據(jù)平臺有千絲萬縷的關系，筆者最近正好在思考這個問題，特此分享于你，當然仁者見仁，智者見智了。
所謂數(shù)據(jù)中臺，即實現(xiàn)數(shù)據(jù)的分層與水平解耦，沉淀公共的數(shù)據(jù)能力，筆者認為可分為三層，數(shù)據(jù)模型、數(shù)據(jù)服務與數(shù)據(jù)開發(fā)，通過數(shù)據(jù)建模實現(xiàn)跨域數(shù)據(jù)整合和知識沉淀，通過數(shù)據(jù)服務實現(xiàn)對于數(shù)據(jù)的封裝和開放，快速、靈活滿足上層應用的要求，通過數(shù)據(jù)開發(fā)工具滿足個性化數(shù)據(jù)和應用的需要，見下圖（以某運營商為例）：
1、數(shù)據(jù)模型
數(shù)據(jù)模型是分層次的，以前叫作數(shù)據(jù)倉庫模型，筆者這里概括為三層，基礎模型一般是關系建模，主要實現(xiàn)數(shù)據(jù)的標準化，我們叫作“書同文、車同軌”，融合模型一般是維度建模，主要實現(xiàn)跨越數(shù)據(jù)的整合，整合的形式可以是匯總、關聯(lián)，也包括解析，挖掘模型其實是偏應用的，但如果用的人多了，你也可以把挖掘模型作為企業(yè)的知識沉淀到中臺，比如離網(wǎng)挽留的模型具有很大的共性，就應該有人把它規(guī)整到中臺模型，以便開放給其它人使用，中臺的中是相對的，沒有絕對的標準。
2、數(shù)據(jù)服務
將數(shù)據(jù)模型按照應用要求做了服務封裝，就構成了數(shù)據(jù)服務，這個跟業(yè)務中臺中的服務概念是完全相同的，只是數(shù)據(jù)封裝比一般的功能封裝要難一點，畢竟OLTP功能的變化有限，而數(shù)據(jù)分析受市場因素的影響很大，變化更快，導致服務封裝的難度變大。
隨著企業(yè)大數(shù)據(jù)運營的深入，各類大數(shù)據(jù)應用層出不窮，對于數(shù)據(jù)服務的需求非常迫切，大數(shù)據(jù)如果不服務化，就無法規(guī)模化，比如浙江移動封裝了客戶洞察、位置洞察、營銷管理、終端洞察、金融征信等各種服務共計幾百個，每月調(diào)用量超過億次，靈活的滿足了內(nèi)外大數(shù)據(jù)服務的要求。
3、數(shù)據(jù)開發(fā)
但有數(shù)據(jù)模型和數(shù)據(jù)服務還是遠遠不夠的，因為再好的現(xiàn)成數(shù)據(jù)和服務也往往無法滿足前端個性化的要求，這時候就得授人以魚不如授人以漁了，數(shù)據(jù)中臺的最后一層就是數(shù)據(jù)開發(fā)，其按照開發(fā)難度也分為三個層次，最簡單的是提供標簽庫（DMP），用戶可以基于標簽的組裝快速形成營銷客戶群，一般面向業(yè)務人員，其次是提供數(shù)據(jù)開發(fā)平臺，用戶可以基于該平臺訪問到所有的數(shù)據(jù)并進行可視化開發(fā)，一般面向SQL開發(fā)人員，最后就是提供應用環(huán)境和組件，讓技術人員可以自主打造個性化數(shù)據(jù)產(chǎn)品，以上層層遞進，滿足不同層次人員的要求。
對于標簽庫（DMP）到底是屬于SaaS還是PaaS是有爭議的，但標簽庫這類平臺顯然較生意參謀類產(chǎn)品更中臺一點，因為其通用性更強，專有業(yè)務的特性不是非常明顯，筆者還是認為可以歸為中臺。
應該來講，數(shù)據(jù)開發(fā)中的組件，比如頁面組件、可視化組件什么的，歸屬到業(yè)務中臺似乎更合理，但其實也要看企業(yè)的實際情況，哪里用的多就可以歸屬到哪里，沒有絕對的標準了。
以上劃分方式在邏輯上還是說得通的，但還有很多沒有考慮進來，比如算法服務、機器學習引擎、hadoop、MPP等等，筆者覺得算法服務應該屬于數(shù)據(jù)服務的一種類型，但h a d o o p、MPP、機器學習引擎更底層一點，應屬于私有云或公有云的范疇了，比如筆者看到阿里云就提供了MaxCompute這類機器學習服務。
關于數(shù)據(jù)中臺的分層看似簡單，但筆者卻糾結了好久，很多邊界是模糊的，最近看的一本書提到，新的概念如果跟既有知識體系不相符，一定要努力搞清楚，不能人云亦云，只要能表達出自己的觀點，即使還是錯了，也有了被人家糾正的機會，對于事物理解的不深入，大多是不求甚解導致的概念不清的結果。
最近新零售很熱，各路大仙都出來詮釋新零售的概念，大家可以想想新零售到底是什么？
