現在關于數據中臺價值的探討已經很多了，但凡事有利必有弊，今天就反其道而行之，談談數據中臺的原罪，知道了這些“罪”，有利于你權衡利弊，做出正確的選擇，這對于數據中臺的發展很重要。

?1. 數據中臺有“名不正言不順”之嫌

中國儒家講仁，但如果讓你對仁下個清晰的定義，估計沒人講得清楚，這體現了中國哲學跟西方哲學一個區別。

康德說：“我追求一切概念都有清晰的定義，一切推理都不允許有大膽的跳躍、而力求用合規律的原則、嚴格的證明，勾畫出研究領域的整個范圍、部門劃分和全部五遺漏的內容，并對未知部分立下清晰的界標。”

概念的模糊性很容易造成類似中國哲學的問題，比如《論語》里孔子提出的：“君君、臣臣、父父、子子”，本來孔子的意思是每個崗位的人做好自己該做的事情，校長要像校長，教授要像教授諸如此類。

但漢朝的董仲舒為了政治需要，提出了三綱五常，把孔子這段話曲解成了“君為臣綱，父為子綱，夫為妻綱。” 新文化運動的時候，孔老夫子就被批得很厲害，實在是很冤枉。

老外沒有中臺的說法，中臺這個詞就有那么點中國哲學的味道。

阿里2015年去歐洲的一家公司SuperSell參觀后提出了中臺戰略，數據中臺、業務中臺，技術中臺等這些詞也被順勢創造出來，我相信這些概念的提出，是各專業領域推進自身工作的需要，沒人會在概念的嚴謹性上去下功夫，差不多就得了。

但既然這些詞已經被炒起來了，就有了利益，有了利益就有了江湖，所有各方都會由于這個利益來詮釋自己對于中臺的理解，這就形成了概念亂象，一千個讀者眼中有了一千個哈姆雷特，你可以說中臺這個詞給了業界無限的想象空間，但模糊性也帶來了很多問題。

比如我們說中臺的本質是共享復用，但這僅僅是一種理念，不能當飯吃，一般還需要化作具體的行動吧，但沒人說得清楚落地共性復用理念的標準動作是什么，比如就數據中臺來講，數據領域哪些東西可以共享復用呢?

往大了講，平臺本來就有這個性質，工具也有這個性質，數據也可以有這個性質，數據倉庫本身似乎也是為共享復用構建的，那么對于已經建完成數據倉庫的企業，干嘛還要建數據中臺呢?數據中臺到底帶來什么具體的增量價值?

很多業務和技術發展到一定階段都會有白皮書，至少還是有中立的組織想標準化一下的，但中臺沒有，更別提數據中臺了，偶偶有幾本數據中臺的書想嘗試一下，但難說對全行業有什么指導意義。

我能想到的破解的方法只有一個，回歸業務本身，看看做哪些優化能提升數據賦能的效率，如果能力沉淀的價值未來可期，那就去做，比如API，這就是數據中臺;如果能力沉淀的價值還不大，就沒必要強求。

2. 數據中臺違背奧卡姆剃刀原理

數據倉庫是OLTP發展到一定階段自然演化出來的，但數據中臺不是，很多企業的數據倉庫被動要求升級成數據中臺，然后強制推進復用共享，或者用新概念來裝點門面，顯然這樣的數據中臺是無法創造出超越數據倉庫的新價值的。

數據中臺在原始數據和應用數據中間增加了一層數據實體，流程增加了，信息衰減了，連接變弱了，這就需要施加更多的外力來進行補償。

因此，如果這些新增的實體無法創造出增量價值來彌補由于引入了新的實體后帶來的成本增加，這就違背了奧卡姆剃刀原則，即“如無必要，勿增實體”，直白的解釋就是“切勿浪費較多東西去做，用較少的東西，同樣可以做好的事情”。

數據中臺如果沒有實際超越數據倉庫，那么就無法躲開奧卡姆剃刀的魔咒，為了進行對抗，我們得干點數據中臺該干的事情，比如API，這是每個數據中臺運營者要想清楚的事情，你得有些使命感，做出一些不一樣的有價值的東西。

3. 數據中臺需要巨大的成本投入

數據中臺希望用共享復用的理念來沉淀能力，然后基于能力來更快的支撐應用創新，但快速支撐應用創新的前提是要有足夠多的已經沉淀出來的能力。

可惜數據中臺伊始，根本就沒有什么拿得出手的能力，大家喜歡用數據中臺的結局來表達其價值，但少有人能真正理解數據中臺構筑能力過程的艱辛，不知道前期要付出多大的代價。

就好比以前說去IOE，說要自主掌控，老板以為可以降低IT投入了，但其實完全錯了。

最近業務方需要我們開放一批原始表，我說：“你能不能告訴原始業務需求，數據中臺用融合模型來支撐?” 業務方說：“這個你不用管，我等不了你修改融合模型，到時改來改去溝通成本也高，模型我們可以自己建。”

為了兼顧能力沉淀和響應速度，我就說：“那能不能這樣，我安排多一倍的資源來支撐你們的需求?” 業務方后來妥協了，但這個多出的資源需要公司買單。

無論從哪個方面看，運營數據中臺都要付出巨大的代價，包括建章立制、組織構建、能力打造、迭代優化等等。

4. 數據中臺的投資風險還是很高

數據中臺概念屹立不倒，是因為我們堅信數據中臺沉淀的能力在未來一定有機會創造更多的價值，這足以彌補前期的投入，但從潛力市場、回報周期、價值產出等要素看，企業投資數據中臺的確是門高風險的生意。

第一、狹義的數據中臺僅限于數據模型和服務，這些數據模型和服務打上了企業和業務的烙印，因此很難復制到其他領域，這實際限制了數據中臺的投資回報率。

現在兜售數據中臺的企業賣得并不是數據模型和服務，而是工具平臺，這并不屬于數據中臺的核心內容范疇。

第二、參考大廠，數據中臺三年才能小成，這還是在人才充足的前提下，因此，一般企業并不一定有足夠的耐心。

正如凱恩斯經濟學派在批駁市場學派所謂的自由市場最終會實現資源的最優配置這種觀點所說的那樣：“長遠是對當前事務錯誤的指導。從長遠看，我們都已經死了。”

第三、數據中臺概念不清，對于企業的文化、組織、機制、流程、數據、平臺又有很高的要求，輸入和產出的關系也不是很明顯，這也是投資比較忌諱的。

當然企業對于自己的投資不一定要那么斤斤計較，畢竟不是簡單的買賣，但心里還是要有所權衡。

5. 數據中臺的能力標準化有點難

15年前的數據倉庫時代，業界曾經提出過一個非常超前的概念：數據封裝，就是把數據封裝成API供業務調用，類似于編程語言中的函數。

比如把某種即席查詢封裝成一個API，而不是跟應用強捆綁，我想這是最早的數據中臺的原型吧，但我后來對數據封裝的可復用性提出了質疑。

數據跟功能不同，數據的指標和維度可以成千上萬，組合之后更是不勝枚舉，也許日常的函數1000個就可以滿足基本的編程需要的，但數據封裝呢，我不知道要多少數據封裝才能滿足一個數據分析應用的需要，大多還是靠定制化取數滿足吧。

函數的貢獻來自于所有編程者，這個超越了行業，因此它能夠快速更新迭代，但數據封裝很難超越行業，能貢獻經驗的也僅限于企業的某些人，我一直覺得數據封裝出來的功能可能等不到規模化用的時候，就已經被新的業務淘汰了，或者企業根本沒有那么多標準化能力復用的場景。

正是這個原因，也許只有巨型的企業才可能在數據中臺的能力標準化方面獲益。

6. 數據中臺導致了系統的脆弱性

現在云原生如火如荼，微服務，容器化，DevOps在保證業務中臺敏捷的同時，也確保其連續性。

數據中臺并沒有吃到什么連續性的紅利，對于大多數公司，數據中臺一般是沒有容災的，也許連應急也沒有，因為對數據的容災就意味著成倍的投資增加，這在一般的公司無法實現。hadoop雖然有數據三備份的策略，但其對于人為操作失誤、數據邏輯錯誤也是無能為力。

數據中臺的目標是把分散的數據能力集中化、共享化，實現其能力“一點發布，全部共享”的理想，但在數據中臺連續性問題無法徹底解決之前，集中化的數據中臺也帶來了集中化的風險，比如一旦集中化的數據被刪除，那么對于企業應用的影響是全方位的。

數據中臺做的越好，共享能力越高，風險就越高，這就是懸在數據中臺連續性上的“達摩克里斯之劍”，也就是“一點故障，全面影響”。

自己就曾經歷過這么一個hadoop事故，換做現在，估計就是災難了。

我們有兩個GIS應用，一個GIS應用由于歷史原因自己采集了很多數據，另一個GIS應用則是基于數據中臺提供的數據構建的，某天運維人員誤刪了數據中臺的所有GIS相關數據，hadoop無法恢復，幸虧另一個應用有重復數據的存在，才避免了核心數據的丟失。

所謂禍兮福之所倚，福兮禍之所伏。

數據中臺的確有很大的價值，但也隱含著不少風險，我們以前談其優點多了，缺點談少了，這不是實事求是的作風，更可怕的是，也許我們自己并不知道這些風險的存在。