不知幾年前，數據中臺這個概念開始變得很熱鬧，各個機構都要上中臺，中臺架構意味著先進，人見人愛，也冒出許多以中臺為業的軟件公司。然而，大概從去年中開始，聽說又有好多機構開始忙著拆中臺了，中臺雖然還沒到人見人煩的地步，但總體來講已經不那么受待見了。
這是怎么回事？
老實說，中臺這架構是挺合理的。在前臺和后臺之間夾一個中臺，屏蔽后臺的數據存儲，應對前臺沒完沒了的變化需求。
前臺跟著界面走，天生就穩定不了，總是有五花八門的數據請求，這是必然的事情。后臺應該主要負責數據存儲，把不同形式和規模的數據以合適的方式整理好，大數據倒騰起來動靜太大，要求有一定的穩定性。
如果前臺的請求都要求后臺直接做，那后臺管的事就太多了。應對靈活請求和規整數據存儲在一定程度上是兩個優化目標不同的需求，同一個團隊在同一套硬件上同時對付這兩件事，容易發生精神分裂。
而且，后臺是被許多前臺共享的，如果直接向前臺提供靈活數據服務，還可能導致各個前臺之間的耦合程度變高，維護成本立即陡增。
同樣的，把這些數據處理放在前臺也不合適，一方面不太安全，另一方面，前臺團隊也是忙著讓界面如何更好看使用更流暢，沒太多工夫琢磨數據的事情。
有了中臺就好很多了，后臺專心管存儲，前面專心管界面，前后臺之間的差距由中臺負責抹平。分工明確，各司其職，效率自然提高。
既然架構合理，那為什么搞不下去？
原因呢，說啥的都有，不過大都沒說到點子上。因為說這些話的大都不寫代碼，寫代碼的又大都輪不到來說話。
根本的原因在于，業界就沒有準備好能讓數據中臺落地的技術！
中臺向前臺提供數據服務。啥是數據服務呢？就是收到請求后返回一些合適的數據回去，那咋弄出返回的數據呢？計算唄，就是把以前在后臺讓數據庫做的事搬到中臺來唄。
那么，你打算讓我用什么技術來寫這些計算代碼呢？
JAVA？開玩笑呢？寫個分組匯總就好幾百行，你讓我怎么提高效率？還想迅速應對前臺變化？這代碼我連寫帶調得好幾天，下禮拜再見吧。
中臺要干的這些任務，也是之前數據庫干的事，絕大多數都是結構化數據相關的計算。而Java這些高級語言基本上沒什么好用的結構化數據計算類庫，原先用SQL幾句話能搞定的事，現在用Java就得幾百上千行代碼了。代碼長了，不僅難寫，還容易錯。而且，Java程序員的成本也挺高啊，效率沒提高，錢倒花多了，那又何苦？
但是，貌似有些大廠的中臺架構實施得不錯，這又咋解釋？
可能是大廠人才多，Java代碼積累豐富吧，搞起這些計算就容易一點了。而且，悄悄地說一句，這些互聯網大廠雖然大，業務復雜度卻遠遠趕不上傳統行業。大廠能搞得通的事，你可未必能搞得通。
不用Java，那咱還繼續用SQL行不？
嗯，那得在中臺也放個數據庫，把一堆數據從后臺搬出來再移到中臺來。搬多少數據呢？貌似所有的數據都有可能用于計算，那得把整個后臺的數據都搬過來。然則這玩意兒還能叫中臺？不就是把后臺挪了個位置而已，純粹吃飽了撐的嘛。
在沒有不依賴于數據庫的、可被集成嵌入的、支持多樣數據源、簡單方便且豐富強大的結構化數據計算能力之時，數據中臺就是空想，架構好看，但無法落地。強行上中臺，除非你的業務足夠簡單，否則就是只會讓開發成本上升而效率下降，靈活性一點沒增加，麻煩事卻一大堆。
有一點小例外，國產報表工具通常在一定程度上擁有一些上述的計算能力（更詳細解釋報表工具的計算能力：不依賴于數據庫、可被集成嵌入、支持多樣數據源、豐富強大尚有不足但應對常規分組過濾等運算都沒問題），如果前臺應用主要用來看統計查詢結果（統計邏輯和數據源還不能太復雜，否則報表工具的計算能力就擺不平了，還得去寫Java或者搬數據），那么搞一個報表工具作為中臺是部分可行的，對于這些限定的應用場景確實可以起到提高效率和增強靈活性的作用，所以有些為數不多還能用起來的中臺其實就是個報表平臺。
數據中臺受制于計算能力。必須要具有上述特征的計算引擎之后，才能讓數據中臺的合理架構真正發揮作用。
