「數據中台」是一個偽概念嗎？｜iCDO精選
- 2020 年 1 月 3 日
- 筆記
編者按
把2019年稱為「中台元年」似乎並不為過，各種中台概念被生造出來，魚龍混雜；許多舊的架構也搖身一變，被包裝成各色中台……這不禁讓我們深深懷疑——中台這東西，到底靠譜嗎？
這篇文章講的是數據中台。騰研識者火雪挺特別擅長用通俗的生活例子詮釋複雜的概念。愛好健身的他之前比較了游泳健身與人工智能的共性，在這篇文章中，他將用小漁村的故事來介紹數據中台的來龍去脈，並將探討一個直擊靈魂的問題：不做中台，會死嗎？
騰研識者 | 火雪挺 騰訊CSIG資深架構師
文章大綱：
1. 從「小漁村的故事」看數據中台
2. 數據中台的三個能力層級
3. 靈魂之問：不做中台會死嗎？
中文博大精深，我很佩服可以發明出新名詞、新概念的人，這些詞簡單準確，既可以被大眾接受，又可以被專家把玩，真正做到雅俗共賞、各有趣味。比如「中台」這個詞就是其中之一。
如今市場上「中台」概念滿天飛，有人甚至把2019年稱為「中台元年」，就像大數據之於2013年、人工智能之於2017年一樣。但同時，各種中台魚龍混雜，「乍看之下誰都明白，仔細一想兩眼一白」，其中「數據中台」尤為如此。有人為了兜售自己的產品，說數據中台對比數據平台的區別在於，數據平台只能提供數據集，而數據中台可以通過中間件、API的方式來提供所謂的數據服務，然後自己的AP搖身一變就成「數據中台」產品了，真香！
其實太陽之下並無新事，拿「數據中台」來說，早前在做諮詢工作的時候，甚至更早在做數據倉庫/商務智能工作的時候，我們提出和落地的數據平台方案一般都會囊括各個層面，用所謂基礎層、數據層、主題層、應用層等來區分。區別在於，其一，當時還沒有到大數據時代；其二，傳統企業業務側的需求變化不快；其三，較少考慮應用層以下平台的可擴展性、多樣性和實操性。
現在市面上大多數對「數據中台」的解讀，是來自阿里的：
「即大數據時代下，通過數據技術對海量數據進行採集、計算、存儲、加工，同時統一標準和口徑，具有數據治理和資產分析能力的，提供數據服務方式多樣的企業級數據倉庫與數據湖。」
儘管這一概念已較為完善，但我認為的「數據中台」應該意味着更多，在此也為它下一個定義：數據中台是企業級數據、算力、技術和平台能力的有機結合體，它匯聚和處理海量異構數據並使之成為可以反映不同業務之間相關性、連續性和可持續性的資產；它既具有中心化的數據治理和數據資產分析能力並提供多樣化、自動化、探索化的數據產品及服務應用，又可以通過平台的能力輸出和資產的快速復用來滿足靈活多變的業務需求。
從「小漁村的故事」看數據中台
將拗口的概念先放在一邊，為了幫助大家更好地理解「數據中台」以及與之相關的關鍵環節，我想講一個故事——《小漁村的改革自強之路》，故事是這樣的：
1. 海邊有個小漁村，村民以捕魚為生，突然有一天，村長決定改革開放，搞市場經濟，於是他把村子沿岸的海給圍了起來，不允許其他村子的人到這裡來捕魚，確定了本村這個「大魚塘」的範圍。
2. 其次，他把整個魚塘的捕撈權承包給了村子裏有意願搞市場經濟的人家，允許他們拿村裡的海鮮作為資源去進行貿易，所得收入歸自有，每年村子向他們收取一定的使用費用。現在大家可以把這個「魚」想像成「數據」。
3. 由於每位村民捕魚技巧和喜好不同，所以他們從大魚塘撈上來的海鮮品種也不一樣，於是最原始的業務數據積累就產生了。
4. 村民們把海鮮批發給遠近不同的海鮮市場，由於都是自己配送，運輸條件不足，常常造成了海鮮的腐爛，貨損貨差嚴重，這就是業務數據多源異構的問題，質量和時效參差不齊。
5. 後來村民和村長商量，每戶人家把大魚塘都划出一塊小魚塘來，按自己的喜好進行捕撈和養殖，就這樣垂直的業務系統數據源產生了。
6. 不同的海鮮市場對不同村民家的海鮮品類有不同的需求，在物流運輸上沒有統一規劃造成了浪費。因此，村長決定整合村子裏的閑雜人、車資源組成一支運輸隊，統一規劃和物流，於是數據服務總線誕生了。
7. 整個村子生意越做越不錯，引來了很多臨近的村子前來主動採購，於是「數據需求」開始呈現出賣方市場的跡象。因此村長又決定在村子邊建立起海邊海鮮市場做銷售批發，並指定了一位市場管理員，他需要洞悉市場需求，按需帶頭向大家採購不同海鮮品類。這樣不僅保證了供貨是市場所需的，質量經過統一審查的，再加上之前的物流運輸隊，可以做到時效有統一保障，大家的貨損貨差都少了，收入和效率都提高了，因此大家都很開心，是個多贏的局面。這可以理解為數據平台成立了。
8. 穩定中求發展，村長決定開展一些高增值的服務，例如海鮮半成品，就是海鮮經過去除內臟、清洗、甚至是腌制等工序，然後真空包裝，可以直接送到超市、飯店，甚至是臨近的村民家裡，客戶直接下鍋就可以做菜了。這個過程就是數據清洗、數據ETL的過程，體現了數據服務向多樣化、終端化（業務化）邁進。
9. 村長又發現，由於客戶對於海鮮的做法不同，有些人並不太在意新鮮程度，因此決定建立一個大型冷庫，把那些對新鮮程度要求不高的海鮮品冷凍或冷藏其中，每天定時向目標客戶進行配送，這樣就減少了由於打撈時間不同，或者天氣原因導致的配送時間的不可控，對整體物流規劃也是一個利好。這就是我們常說的數據倉庫的構建。
10. 村長覺得是時候開始做零售了，畢竟零售的毛利更高。於是村長又指定了一系列外派人員，根據所知臨近村莊的不同口味，帶着不同的海鮮品種去那裡開海鮮超市，直接面對最終消費者。於是數據集市也有了。
11. 村子的生意越做越大，食品管理局開始入駐，要對所有海鮮品進行質量的監測。不但要檢測，還要能回溯，一旦某一批的魚壞了，村長和小組長們要知道這個魚是從哪個魚塘捕撈的，是由誰捕撈的，這樣就能去分析原因，對相關人員進行教育指導。這就是數據質量管理、元數據管理，數據血緣分析等作用。
12. 不僅如此，稅務局的人也常來了，對村子和個人的所得稅進行審計工作，稱之為數據資產分析。而且為了方便管理，村長要求村民們至少能會寫、會讀關於海鮮品類的文字和知識，而且用統一的名稱和語言。這就是數據字典和數據標準化的作用。
13. 村子發達出名之後，越來越多的人來到這裡，於是這些人的衣食住行就既成了問題又成了商機。一開始他們去村民的家裡吃「農家樂」，村民提供固定的菜單和住宿標準，就像提供了固定的「數據產品」。同時呢，也有些店家很聰明，直接提供給客人一張漁網、一個爐子、一張桌子和各類香料配料，客人自己按喜好去捕撈和烹飪，讓喜歡自己動手的客人非常滿足。這就是我們講的，數據中台的平台能力服務和基礎算力服務等。
14. 村長也集合精幹之力，建設起了村裡的第一個豪華五星級酒店，酒店不僅有海底觀景房、售賣各類魚骨裝飾品，而且還有相當豐富的海鮮菜單，從前菜到甜點都由海鮮製成，整一個「海鮮全席」，這是我們說的靈活和多樣性的數據服務。由於費用不菲，這部分服務只能由高凈值的VIP客戶享用。這就是我們說數據中台團隊應整合數據、平台、算力等能力，瞄準最關鍵的20%核心業務需求，解決組織內80%的核心業務問題。
15. 再好吃的東西，吃多了就會厭。村長臨機一動又來一招，就是允許和鼓勵各村民家在自己的小魚塘裏面搞一些交叉養殖的實驗，希望可以培養出更多的海鮮新品種來，這就是我們通常說的機器訓練平台或算法訓練平台的作用，挖掘更多數據的價值。
16. 村長由於帶領整個村子奔小康，被評為時代改革先鋒，村子也聲名遠揚。不僅是汽車、火車和船隻都駛來交流經驗，而且貿易更加頻繁、市場成長很快，因此村子裏鋪設了符合國家標準的鐵軌、修建了車站，還興建了國際港口，符合萬噸輪級別的航運要求。這就是中台提供標準的數據接口，不僅執行數據接入，還提供數據訂閱、數據消費的作用。
數據中台的三個能力層級
聽完「小漁村的故事」，相信你會對數據中台的角色和作用有初步的了解。如果說數據中台的建設有一個目標的話，那就是整合數據、技術、算力和平台級別的能力來解決業務上的問題，其建設原則應該是先立後破、循序漸進、升級融合、風險可控，永遠要考慮的一個重點平衡中台的資源投入和對業務帶來的價值產出。
這個價值能力模型如下：
基於此，我認為數據中台應當提供三個層次的能力：
1. 在中台能力及資源充足的情況下（包括業務知識、技術能力、人才積累），提供數據產品、數據服務。
一般而言，數據應用是上層的概念，讓用戶去使用的東西，而數據產品和服務則是兩種不同的應用。產品提供預定義好的標準化功能，優點是使用簡單、易於維護，缺點就是缺乏個性化、定製化的能力；而服務則要靈活、多變的多，當然成本和實現周期也會因人而異。
這些數據產品及服務有其共性的一面，當然也由因行業及場景的不同，有多樣性的一面。將其共性抽象一下，無外乎包含以下幾類：
l 決策支持類：主題報表（月度/季度/年度/專題）、輿情監控、熱點發現、大屏數據可視化展示等
l 數據分析類：交互式商業智能、OLAP分析、數據挖掘、數據驅動的機器學習等
l 數據檢索類：全文檢索、日誌分析、數據血緣分析、數據地圖等
l 數據共享開放類：實時數據訂閱、離線數據接觸、數據API接出
而多樣性的一面每個行業都會不一樣，常見的有:
l 用戶相關：用戶畫像服務、用戶成長/流失分析及預測、點擊率預測、智能推薦等
l 市場相關：數據服務於搜索引擎、數據服務於推薦引擎、熱點發現、輿情監控等
l 製造生產相關：預測性維護、生產過程實時數據監控、數字孿生等
當提供第一種能力的時候，數據中台的應用和管理都會有中台團隊負責搭建和運維，此時管理和應用都是集中的。對於構建者、管理者要注意的是，我們要緊盯所有業務中那最重要的、具有戰略性的20%，集中資源和精力來為其提供數據產品或服務，因為它們往往代表着80%的核心業務價值。當然為了做到這一點，與各業務線同僚的有效溝通和大格局的審時度勢能力是必不可少的。
2. 在中台業務能力及人力資源不充分、但體系相對成熟的情況下（包括數據體系、技術體系），提供平台級別的能力，包括數據平台能力、技術平台能力、建模平台能力等，甚至是數據本身。
企業建設項目有兩個很重要但通常會被忽略的因素：人才和知識的累積。當前台對市場、用戶的感知越來越敏銳的時候，就會產生越來越多、越來越快的數據消費需求，因此這種情況下，中台無法參與並滿足前端的所有業務需求，一種新的能力需要被孕育出來，那就是前端業務在處理數據、使用數據的時候，對於後端來講是「無感知」但「可管理」的，這個時候就需要一個中間層，這個中間層幫助業務需求與技術支撐的「解耦」，也就是這個中台，中台的價值也就體現了出來。這裡有三點需要說明的：
l 無感知：業務側產生數據處理、計算、存儲和對自身數據消費的需求，不需要向中台進行預先申請，也不需要中台技術人員做相應的技術操作，業務人員自己就可以通過簡單的配置來完成這個數據方面的需求，包括數據的接入、存儲、簡單的計算，甚至是簡單的維度分析等，還有自助式的數據訂閱、數據接出等需求。
l 可管理：雖然中台人員不用參與每一個業務的數據需求，但這些動作對於中台都是可見的。從資源上來講，可以對較耗資源、異常的數據任務進行限流或中止，對較大、異常的庫表進行隔離或優化；從數據上來講，凡事接入的業務數據，中台人員可以通過平台操作進一步將對中台有價值的數據落地、入庫，有必要的話接入中台的數據清洗、加工流程、調控流程，使之成為可預見的資產，並使其進一步與其他業務數據融合，構建高價值密度的數據倉庫，在庫內消滅數據煙囪，產生更大的數據整合性價值，為提供面向業務用戶的數據集市、自助式決策分析、自助式數據分析打下基礎。
l 解耦：以前當我們可以提供較完備的數據倉庫/集市的時候，產生了自助式的BI分析，解決了業務人員需求報表，但技術人員來不及做的尷尬；現在我們也理應打造這樣的中台，通過這樣的能力，給業務人員提供自助式的、一站式的、從產生數據到產生價值的完整通路。
在第二種情況下，數據中台應當提供的是：
l 數據平台的能力：包括全域的數據採集能力（多業務、多終端、多形態）、自助式的數據接入、存儲和消費工具的開放；自動的建庫、建表、分區、消息Topic建立能力，簡單的自助式數據分析、數據檢索和數據審計能力，事件及日誌的查詢能力；數據清洗及任務調度工具的開放；數據資產分析能力的開放。
l 技術平台的能力：現在越來越多的業務系統由於時效性及數據處理的要求，也會用到消息隊列和NoSQL的能力，特別是有海量數據快速檢索類的需求時，那中台就應該為中台相關的系統提供這種技術組件來滿足需要，像kafka這種可以作為業務系統之間的消息分發通道或發佈隊列，HBase作為KV存儲提供業務系統的查詢能力等。
l 建模平台的能力：或者應該說是提供基於數據，進行統計機器學習建模的能力，包括了自助式模型訓練、算法引入、模型發佈與服務管理的能力
l 數據本身：通常來講，除了算法訓練平台或數據對賬審計可能需要原始數據之外，大多數情況下對數據的需求，其實是對清洗過後、價值密度較高的數據集的需求，也就要求中台人員構建合理且魯棒性高的數據倉庫、數據主題庫等，構建高聚集、高集計、高針對性的數據集市等，以此為基礎提供給業務用戶進行分析與應用。有時候對於特定的應用，例如搜索應用、推薦應用、熱點應用等，我們還需要構建特定的離線數據集或實時數據流，在特定的頻率下（分鐘/小時）以特定的方式（消息隊列/實時緩存/API）為其供數，這也是數據服務必不可少的一種。為了能夠提供這種能力，通常我們需要在數據清洗和轉換的過程中大費周章，結合業務知識發掘數據海洋里的「海底石油」並構建石油鑽井平台而取之有道。這對數據中台的從業人員也提出了一定的要求。
可以說，當提供第二種能力的時候，數據中台的應用是分散的，管理是集中的。
3. 在中台人力資源和對業務領域知識理解不充分，平台級別能力也無法滿足要求的情況下，作為算力基礎平台提供服務。
都說數據為王，但人們常忽略另一個事實，那就是在實操過程中，這些數據放哪？放多久？要花多少錢？這裡的致命要素就是：服務器。實際的企業環境、特別是傳統企業環境，不誇張的說，誰真實地掌控着服務器的管理權和使用權，誰就是「挾天子以令諸侯」。
服務器是真金白銀的硬性成本支出，涉及到各個部門每年預算的使用；其次服務器的變動涉及到基礎環境的問題、包括機房、水、電、網絡、安全等等，所以通常不輕易調整，這個調整包括擴容和釋放。而且，服務器代表着切切實實的算力，CPU的、GPU的，這個算力可以用在AI、大數據、也可以用在業務系統、安全系統等。所以通常建設數據中台，在不複雜或無特殊情況下，採購的服務器資源也會有數據中台來控制和管理，於是就有了分配算力的權柄，我們說這是數據中台作為一個算力基礎平台的能力。這裡又有兩層意思：
1. 純粹的算力平台。用戶藉助數據中台所擁有服務器的CPU/內存/硬盤等資源來進行自己的業務活動，可以是實驗性的數據分析，某些出庫訂閱任務，甚至和數據沒有關係，只是業務程序需要的算力支持。
2. 算力和大數據技術的平台。除開數據應用型的系統，例如用戶畫像、推薦系統、搜索系統等——它們原來就需要使用到大數據計算的技術組件和大量的計算資源——越來越多的業務相關型系統，例如日誌查詢、事務監控等系統也會藉助大數據的技術組件和相對應的計算資源來確保查詢、監控的全量性、時效性，此時這些系統就必須依附在數據中台的算力和技術支撐上，來完成系統里某一個或多個重要的計算或緩存功能。這有點類似於第二層能力中的技術平台能力，但不同點在於，首先這裡更看重算力、通常是和中台無關的業務系統，其次中台人員不參與技術組件的部署、配置和開發。
當提供第三種能力的時候，數據中台的人力投入應該是最低的，但需要進行資源的日常監控和任務管理。
前面闡述了個人認為的數據中台「理論上」應該提供的三種不同層面的能力，現在以一張圖作為總結，作為「理論上」的數據中台所必要的功能要素示例：
靈魂之問：不做中台會死嗎？
說了那麼多，現在我們需要冷靜地問一下自己，「不做中台會死嗎？」
簡短的回答是「不會」。要知道，數據中台一個很重要的部分是數據的融合，並用數據產生的價值去支撐業務。我們要問自己的是：一，能不能做融合；二，融合後對業務有沒有支撐作用。
第一，數據融合的前提是融合匯聚之後的數據是有價值的，而有價值的表現要麼是可以更完整地刻畫你的用戶，幫助你去賣東西；要麼是可以更完整地刻畫你的業務流程，幫助你去做運營；要麼是可以更完整地刻畫你的經營狀態，幫助你去拍板決策；因此其有價值的前提就要求你的業務具備一定的相關性、連續性。如果你同時開了一家汽修店和一家菜市場，你要將兩者的用戶數據做融合是沒有意義的，業務不具備相關和連續性，無論是頻率、客單價和受眾都差了許多；但如果你同時開了一家金店賣黃金和一家菜市場，那或許還有融合的意義，畢竟大媽們買完菜去金店逛一圈囤個貨還是有相關和連續性的。所以業務的相關性是指空間上的，業務的連續性是指時間上的，離開太遠的業務，或者時間差別太大的業務，並沒有必要做數據融合，純粹的業務系統各自支持就好了。
第二，就算數據融合了，但它對業務的支撐不具備可複製性和可持續性，那也不必大動干戈就建設中台了。還是金店和菜市場的例子，當我們花了很大力氣去採集數據並把兩者匯聚起來之後，發現在菜市場的大媽中確實有一批專門搶購黃金的人，但搶黃金這種事情只會發生在黃金大跌或股市大跌的時候，幾年不遇，難以預測，因此無法多次、持續地產生業務價值，所以就像我們一開始說的，資源投入和對業務帶來的價值產出是不對等的。
故事也講了，觀點也說了，最後總結一下核心所在，我覺得「數據中台」：
l 它不是一個產品；
l 它不是固化的；
l 它不只是數據平台加數據應用；
l 它不只是海量異構的數據倉庫；
l 它既是集中的「一體」，又是分散的「多個」；
l 它能提供中心化的管理，又能提供去中心化的服務；
l 它既能符合企業核心的數據化發展目標，又能滿足組織個體探索式的數據需求；
l 它應該是企業組織架構和技術體系相融合的有機結合體。
–END–
