談一談資料中臺的原罪

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

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無法恢復，幸虧另一個應用有重複資料的存在，才避免了核心資料的丟失。

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

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