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

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

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

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

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

如上圖所示，業務中臺和資料中臺又存在聯絡。業務中臺產生資料，資料中臺處理業務中臺產生的資料然後挖掘資料的價值，並反饋給業務中臺，形成一個資料閉環。

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

中臺的架構合理嗎

老實說中臺這架構是挺合理的。在前臺和後臺之間夾一箇中臺，遮蔽後臺的資料儲存，應對前臺沒完沒了的變化需求。

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

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

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

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

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

既然架構合理，那為什麼搞不下去？

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

根本的原因在於， 業界就沒有準備好能讓資料中臺落地的技術！

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

那麼，你打算讓我用什麼技術來寫這些計算程式碼呢？

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

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

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

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

不用Java，那我們還繼續用SQL行不？

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

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

資料中臺受制於計算能力。必須要具有上述特徵的計算引擎之後，才能讓資料中臺的合理架構真正發揮作用。