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

我發(fā)現(xiàn)網(wǎng)上也有很多文章進(jìn)行分析，但大多是長篇大論，表述也過于技術(shù)，今天我就用最通俗的話跟大家解釋一下。

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

首先，不論是數(shù)據(jù)中臺，還是業(yè)務(wù)中臺，都屬于中臺的一種。而中臺的職責(zé)在于抽象共性形成通用服務(wù)能力。

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

如上圖所示，業(yè)務(wù)中臺和數(shù)據(jù)中臺又存在聯(lián)系。業(yè)務(wù)中臺產(chǎn)生數(shù)據(jù)，數(shù)據(jù)中臺處理業(yè)務(wù)中臺產(chǎn)生的數(shù)據(jù)然后挖掘數(shù)據(jù)的價值，并反饋給業(yè)務(wù)中臺，形成一個數(shù)據(jù)閉環(huán)。

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

中臺的架構(gòu)合理嗎

老實說中臺這架構(gòu)是挺合理的。在前臺和后臺之間夾一個中臺，屏蔽后臺的數(shù)據(jù)存儲，應(yīng)對前臺沒完沒了的變化需求。

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

應(yīng)對靈活請求和規(guī)整數(shù)據(jù)存儲在一定程度上是兩個優(yōu)化目標(biāo)不同的需求，同一個團(tuán)隊在同一套硬件上同時對付這兩件事，容易發(fā)生精神分裂。

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

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

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

既然架構(gòu)合理，那為什么搞不下去?

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

根本的原因在于，業(yè)界就沒有準(zhǔn)備好能讓數(shù)據(jù)中臺落地的技術(shù)!

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

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

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

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

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

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

不用Java，那咱還繼續(xù)用SQL行不?

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

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

數(shù)據(jù)中臺受制于計算能力。必須要具有上述特征的計算引擎之后，才能讓數(shù)據(jù)中臺的合理架構(gòu)真正發(fā)揮作用。