搞數據的都知道，阿里發明了數據中臺，然后“中臺”這個概念就馬上成為了國內大多數企業趨之若鶩的風口，真正實施后卻發現中臺與數據平臺、數據湖等項目大差不差，又有好多機構開始忙著拆中臺了，中臺雖然還沒到人見人煩的地步，但總體來講已經不那么受待見了。

我發現網上也有很多文章進行分析，但大多是長篇大論，表述也過于技術，今天我就用最通俗的話跟大家解釋一下。

首先，先解釋一下中臺的概念

首先，不論是數據中臺，還是業務中臺，都屬于中臺的一種。而中臺的職責在于抽象共性形成通用服務能力。

而數據中臺就是抽象處理數據能力的共性形成通用數據的服務能力。數據中臺側重于數據，包括數據存儲，數據計算，數據分析等，這些能力也是具備共性的。比如數據中臺提供的用戶畫像能力，我們可以在各個領域使用同一套方案。

如上圖所示，業務中臺和數據中臺又存在聯系。業務中臺產生數據，數據中臺處理業務中臺產生的數據然后挖掘數據的價值，并反饋給業務中臺，形成一個數據閉環。

基礎設施層，提供更加底層的服務能力，比如可觀察性，CICD，容器，服務治理等，支撐各種中臺。而中臺除了數據中臺和業務中臺，還應該包括AI中臺。共同服務前臺應用。

中臺的架構合理嗎

老實說中臺這架構是挺合理的。在前臺和后臺之間夾一個中臺，屏蔽后臺的數據存儲，應對前臺沒完沒了的變化需求。

前臺跟著界面走，天生就穩定不了，總是有五花八門的數據請求，這是必然的事情。后臺應該主要負責數據存儲，把不同形式和規模的數據以合適的方式整理好，大數據倒騰起來動靜太大，要求有一定的穩定性。如果前臺的請求都要求后臺直接做，那后臺管的事就太多了。

應對靈活請求和規整數據存儲在一定程度上是兩個優化目標不同的需求，同一個團隊在同一套硬件上同時對付這兩件事，容易發生精神分裂。

而且，后臺是被許多前臺共享的，如果直接向前臺提供靈活數據服務，還可能導致各個前臺之間的耦合程度變高，維護成本立即陡增。

同樣的，把這些數據處理放在前臺也不合適，一方面不太安全，另一方面，前臺團隊也是忙著讓界面如何更好看使用更流暢，沒太多工夫琢磨數據的事情。

有了中臺就好很多了，后臺專心管存儲，前面專心管界面，前后臺之間的差距由中臺負責抹平。分工明確，各司其職，效率自然提高。

既然架構合理，那為什么搞不下去?

原因呢，說啥的都有，不過大都沒說到點子上。因為說這些話的大都不寫代碼，寫代碼的又大都輪不到來說話。

根本的原因在于，業界就沒有準備好能讓數據中臺落地的技術!

中臺向前臺提供數據服務。啥是數據服務呢?就是收到請求后返回一些合適的數據回去，那咋弄出返回的數據呢?計算唄，就是把以前在后臺讓數據庫做的事搬到中臺來唄。

那么，你打算讓我用什么技術來寫這些計算代碼呢?

Java?開玩笑呢?寫個分組匯總就好幾百行，你讓我怎么提高效率?還想迅速應對前臺變化?這代碼我連寫帶調得好幾天，下禮拜再見吧。

中臺要干的這些任務，也是之前數據庫干的事，絕大多數都是結構化數據相關的計算。而Java這些高級語言基本上沒什么好用的結構化數據計算類庫，原先用SQL幾句話能搞定的事，現在用Java就得幾百上千行代碼了。代碼長了，不僅難寫，還容易出錯。而且，Java程序員的成本也挺高啊，效率沒提高，錢倒是花多了，那又何苦?

但是，貌似有些大廠的中臺架構實施得不錯，這又咋解釋?

可能是大廠人才多，Java代碼積累豐富吧，搞起這些計算就容易一點了。而且，悄悄地說一句，這些互聯網大廠雖然大，業務復雜度卻遠遠趕不上傳統行業。大廠能搞得通的事，你可未必能搞得通。

不用Java，那咱還繼續用SQL行不?

那得在中臺也放個數據庫，把一堆數據從后臺搬出來再移到中臺來。搬多少數據呢?貌似所有的數據都有可能用于計算，那得把整個后臺的數據都搬過來。然則這玩意兒還能叫中臺?不就是把后臺挪了個位置而已，純粹吃飽了撐的嘛。

在沒有不依賴于數據庫的、可被集成嵌入的、支持多樣數據源、簡單方便且豐富強大的結構化數據計算能力之時，數據中臺就是空想，架構好看，但無法落地。強行上中臺，除非你的業務足夠簡單，否則就是只會讓開發成本上升而效率下降，靈活性一點沒增加，麻煩事卻一大堆。

數據中臺受制于計算能力。必須要具有上述特征的計算引擎之后，才能讓數據中臺的合理架構真正發揮作用。