鬼話連篇數據中臺（一）：透過中臺看數據中臺

關於數據中臺的一場對話

場景一：

發生在上週週末，與一個公司的老闆對話：

開門見山的提了一個問題：「想問一個問題， 我想搞一個數據中臺。」我驚了一下問到：「啥？搞數據中臺？沒燒壞吧？」

「那想搞這個這個數據中臺的目的是啥？是要支撐業務，仍是在融資上搞啥？」

「如今這個中臺很火啊，咱們也想搞一下。搞個數據中臺、再搞個運營中臺，將來面向 xxx 這個羣體，就是一個 SaaS。」

「你真有錢，其它中臺很差說，可是數據中臺我認爲就公司目前的這個業務狀況，還在初級階段，業務一直在快速奔跑，組織結構還沒成爲業務發展的瓶頸。

另外從中臺的難度上來說，在產品、架構規劃等方面強調的是服務、組件化、業務抽象等方面，其自然的起點已經比普通業務形態與產品有數量級的差別。

業務的快速頻繁變化，如何讓中臺來作沉澱？小心中臺的不完善拖累業務，搬不動這塊鐵，把本身砸暈了。

我的建議，拋開全部概念，就圍繞本身的要解決問題，解析出適合本身的商業模型到分析模型，在 圍繞分析模型來看如何作埋點與數據拼圖，用數倉的方式，數據平臺的實施來支撐好本身。」

老闆：「那你幫我出一個方案吧。」

「我 #￥%……&*（）——」

場景二：

發生在一個數據羣，一個同窗問到 ：「什麼是中臺，什麼是數據中臺呢，我看的一臉懵逼。」

「咱們公司要招中臺產品經理了，都是來幹嗎呢？」

「我看了不少材料，仍是沒懂啥叫中臺，最近有個公司出了一本數據中臺的書，買來再看看。」

而後呢，再過幾天，在不一樣的羣不一樣的場合，相似的不少關於數據中臺的對話將繼續神話般「狗對」着。

中臺的建設是一個複雜的系統工程，正如某大神說的「中臺的建設要想比較成熟且有體系的策略至少要三年以上時間，是要分階段去實施的」，中臺的實施在現階段只能是摸索、實踐，由於你們對中臺的理解是根據所處的當下環境與狀態而進行思考的。

如今中臺的實施將會在作事的方式、思惟的高度、系統框架方面有所改變，可是實際上不少打着中臺這個詞，在按照技術組件、技術產品或一個技術平臺的的方式在實施，只是被成爲了中臺。

總結本身 2019 年半年職業生涯，中旬離開一家「大航母」後，這半年也是在跟中臺打交道，而且到如今也是在嘗試去推進一個數據中臺化，其中遇到了各類有意思的問題，期間花了漫長時間來盤點問題並嘗試尋找一種適合的演進方案。那我能在這裏作點什麼呢？

交流了些中臺的實施，通常一上來就喊中臺化的基本入不敷出，不是人員投入問題、就是實施方向以及定位究竟是什麼， 可是有的企業用演進的辦法來作實施是個很是不錯的選擇。那成功與失敗的關鍵要素是什麼呢？是認知的因素？仍是人的因素？仍是組織因素？仍是指望與落差的因素？標準的中臺是什麼樣子？咱們如何衡量的是在作中臺而不是在作平臺？作中臺從具體事情層面來說，有哪些維度？該如何落地？如今中臺的書已經有好幾本、網上的各類文章有不少，或多或少的都有在回答」中臺」的相關問題吧。我在後面的篇章也會逐漸展開講我所理解的這些問題。

「伴隨着業務的多元化發展，公司各部門紛紛建設各自的業務系統，在產生大量的系統、功能與應用重複建設的同時，也致使了系統之間的數據處於未能及時打通的割裂狀態。大量的數據被阻斷在了不一樣的系統中，就像一個又一個的「堰塞湖」，可能知足了單一的業務場景，卻阻塞了企業數據資產的全鏈路管理，使得企業數據難以被全局規劃與定義，這就是數據中臺應運而生的源動力。首先，數據中臺是根據企業的實際狀況所打造的數據產品與實施方案的結合物，它能夠融合企業內外數據，打破數據隔閡，解決企業面臨的數據孤島、數據標準不一致等問題。其次，又是一種戰略選擇與運營解決方案，是一套行之有效的數據運營機制」。

這段話是來自某一個科普文章，在行家的眼裏看會怎麼樣呢？我特麼想問問這個做者，企業級數據集成、數據倉庫、數據平臺的定位什麼。

透過數據中臺看數據平臺

寫這個小標題時盡是糾結，內心一直在想如何系統化的可以比較數據中臺、數據平臺的的類似性與區別呢？總結了一些維度，好比複用性、資源整合、能力沉澱、按照業務橫向相關聯性把數據作深度整合並最終沉澱爲公共的數據服務能力等等，但發現每一篇文章，每個定義都是很是隨性，沒有本質上顯著的區別，難道在平臺的實施中直接換個詞就能成爲數據中臺？開始老闆很是高指望的我花 1 年時間投入 30 個、50 個研發、十幾個數據產品經理就能完成中臺的建設？到頭來不斷下降的預期、難以忍受的產出與不成正比的投入，最終會怎麼樣呢？是顯而易見的？

複用性、組件化、資源整合、按照業務橫向相關聯把數據作深度整合並沉澱爲公共數據服務能力這些能力在構建數據平臺之處就是必須去解決的問題。資源整合也涉及技術資源整合與數據資源的整合沒什麼好說的。在兩年前曾經寫過一篇文章《我所經歷的大數據發展史》中曾經專門的研究與分享過數據部門的組織結構變化。有感興趣的讀者能夠翻出來看一下，關於組織結構這塊我在後續還會繼續展開講。

能力沉澱，這個相對來稍普遍一點、數據的接入能力、計算能力、存儲能力、業務支撐能力、展示能力都算在能力沉澱中，只有想不到沒有作不到。

通常的平臺化是由於業務需求繁多、響應及時要求高，須要平臺，由於企業的業務發展也是成生物生態的特色，平臺化也是須要下降成本、提高效率，並如何快速的支撐與相應業務、可是平臺的邊界很是清晰與管理很規範。

• 在實施平臺後，能夠實現柔性的支撐業務，能解放技術同窗併發經歷投入到穩定性、高性能、技術改造等一系列的其它重要事情上與提升人效，下降公司成本。
• 平臺化後，對業務分治與歸口的管理，業務邊界變的更加清晰，歸口管理使得各團隊對本身業務管理更規範與高效避免了一件事情找半天沒人理，須要更多的 pmo 與創建更多的流程與規章制度保障工做。ps 讀到這裏是否是有些讀者已經意識到什麼了，^_^ 後續在展開講。

總之平臺化是在業務層面、功能層面、接口層面、應用層面去作具體的落地。

迴歸數據體系建設，企業的一個營銷方案可能須要幾個禮拜到幾個月，是企業爲中心，生產爲嚮導的模式，可是如今變爲市場爲中心，又再變爲客戶 & 用戶爲嚮導的持續規模化。企業的業務響應能力和規模化的創新能力，是區別於傳統企業與互聯網企業的綜合能力的。企業擁抱這樣的變化就意味着業務必須逐步徹底信息化，對客戶的觸達方式也極具的縮短，中間全部的數據記錄模式也發生信息化的變化。業務數據結構變化，由傳統企業的單純文本，結構化數據轉爲非結構化的聲音、視頻、日誌、定位信息等。

因此須要數據處理的技術架構、產品架構、甚至相關的組織結構也是不一樣。在這種平臺結構下構建起來的數據平臺，是企業數據體系建設的基礎， 蒐集好的數據須要產生價值。數據的蒐集、存儲、顯示、產生價值是一個鏈路，相輔相成的。一個公司如何想實施好一個數據體系，是須要從數據、產品、工具、技術、應用等多個角度，來共同實施與落地才能徹底作好的。

數據平臺這個詞自己含有平臺，平臺這個詞內部的含義已經包含組件化、服務化、系統化。建設數據的主要目的就是屏蔽數據異構性、構建統一的數據源，這個無論是在數倉、仍是在數據平臺都是必需要作的基本任務之一。

與你們一塊兒拆解 2 個內容：

一， 平臺中的關於組件、服務與系統化：數據域的建設分爲內容建設、工具建設與內容價值探索， 其中工具體系化建設是數據平臺的基石，內容透過工具把價值體現出來，工具如何構建與聯合將會將會發揮出不一樣的價值來。

例如，之前咱們的 ETL 過程、數據工具、調度工具、元數據工具、指標字典、庫表字典、數據質量等等一系列工具是一個個的工具產品，每個工具產品解決的是特定領域的問題，好比

指標字典是解決的公司離線級別指標管理與指標口徑管理問題或者是還能夠增長在線指標的配置管理。

庫表字典有的公司若是是數倉主導可能設計的就是給本身服務，裏面就是針對數倉的表作查詢，若是把業務系統庫表整合進來，那就是面向其它技術羣體等一款小的服務產品。

有的人說，這個屬於元數據的範疇，我把一個數據地圖作紮實作透了，把庫表字典、指標字典裏面的全部元數據經過有機的關係整合起來查詢多好，而且能夠提供對外的查詢服務，或者是在某個流程中，好比 ETL 的過程、調度的過程隨時隨地能夠查詢相關的信息與影響因素多好啊。

對沒錯的， 舉得這個例子單個工具與單個工具耦合性不好，缺乏相互聯合做用的功能， 如今有很多公司在作產品時每每都是一個個的工具獨立的存在， 說是成爲一個平臺，可是更多的僅是個工具，從架構與定位上來看僅僅是打的一些點，沒法聯合起來造成一個工具體系提供豐富的不一樣場景應用。這樣案例不少的。

這個小案例就思考到了組件化、服務化這幾方面，來作規劃與設計。

二，關於統一，無論是在工具建設、內容建設中不可避免的要去面對多個業務線、多個業務系統來作數據等整合，可能會涉及到不一樣的內容須要"歸一化" 「統一」。

咱們要統一的建模、統一的開發、創建統一的標準，所謂的統一這個是作數據必需要的去完成一個使命，數據倉庫自己具有的一個責任之一就是數據整合，屏蔽數據的異構性，完成對不一樣術語的統一，若是拿到中臺的這個 id 統一，哪一個 ID 統一，本質上只不過是數據倉庫、數據平臺自己所必須的職責之一。歷史有一個項目 的數據項目的目標。感受與如今有多大的差別性？但服務的範圍不一樣了。就像 APP 日誌採集同樣，埋點統一也是流量必需要作的事情。

（圖例是在 12 年前一個項目中項目模塊介紹）

強大數據中臺是每一個企業的夢想

每一個企業都夢想要一個很是強大數據平臺或中臺，對企業內部提高運營效率、決策效率、在線精準，對外支撐各類場景應用。從實施角度、管理、面對客戶上總結爲：

• 在實施上，想把數據前因後果梳理特別清楚，把數據加工、存儲、分析、建模等與數據有有關的全部事情均可以輕鬆的解決；

• 對於管理上，想有一個能夠管理一切的入口，把一切的數據、口徑、項目、工程等都管理起來；

• 面對的客戶上，想讓客戶能夠一站式在這個平臺上獲取到任何想要的東西，並能夠獲取到足夠的數據應用能力；

爲了這個願望，大部分的數據人朝着這個終極目標去努力，可是到頭卻發現，這是個泥潭越陷越深。你們都在泥潭中不停的掙扎，須要面對每天變化的業務與嚴重不規範的數據結構、肯定什麼樣的數據源，數據的含義是什麼，數據的上下文是什麼，數據質量問題，還面臨業務數據中元數據的丟失，業務文檔基本沒有， 問了一圈還沒人知道等各方面的問題。

我的相信以上提出的來的這些問題，無論是數據倉庫、數據平臺、數據中臺都是要幫助企業達到這些目的的手段，而不是目標自己，以用戶爲中心的持續規模化創新，是數據體系建設的核心目標。

企業有成千上萬，不一樣企業發展的不一樣階段，對於數據建設的意願度與驅動力也不一樣，有的企業還在準備上馬數據倉庫，有的已經創建本身比較完善的數據平臺， 而大廠、準大廠已經數據中臺化，也或是走在中臺化的路上。

當還在實施數據倉庫、一套 BI 的時候，結果有數據平臺，當還在努力爲了數據平臺而在投入資源實施時，有了數據中臺。無論三七二十一，搶先發布博人眼球甚至「高大上「全套解決新概念，隨着阿里的中臺戰略以及鄧中華的神通常的指導中臺問世後，到如今各類培訓都來了，如「中臺產品經理」、 「實施中臺戰略」、 「如何實施中臺」 。甚至在一些數據產品經理羣裏還會有招聘數據中臺產品經理。

相信每位老闆、每位數據建設者在面對數據倉庫、數據平臺、數據中臺這個宏大的多概念混洗在一塊兒時，會是一種怎麼樣萬馬奔騰。在實施的過程當中到底使用什麼方法論？倉庫、平臺、中臺到底有什麼區別？

在開始「這個文章系列」以前，咱們先回到企業上數據的基本上來。企業到底要一個什麼樣的數據管理體系，到底要什麼樣的功能、爲了解決什麼問題？須要根據什麼原則去設計與實施？

特別贊同一個句話「資源整合，下降成本，同時探索新的商業應收模式」，這個無論是在平臺階段、數據中臺階段都是要必須去知足。

在這個幹中臺的不如講中臺的時期，但願不要繼續誤導企業上什麼平臺。其實中臺究竟是什麼並不重要，這只是一個概念。每一個公司有每一個公司的方法，如何千方百計持續提升企業對⽤戶的響應⼒纔是建設背後最核心的邏輯，更好的服務前臺規模化創新，進而更好的響應服務。無論是中臺仍是平臺可以去的顯著成效就好。

本身也看了不少，可是也沒把中臺這個概念想的特別清晰。其實不用糾結概念，仍是那句話：「中臺是什麼並不重要，每家公司找到適合本身的方案並推動落地。」

在上面開篇時提到了企業上數據須要解決的問題與面臨的困難，那該用什麼方案去實施？如今數據這幾種方案有什麼異同點？

一個企業構建一個數據平臺是否已經標誌着企業的數據應用能力就徹底上一個新的臺階呢？或許不是絕對，與一些企業管理者溝通起來獲得的信息就是成本過高，如何節省成本？

回顧爲何會提到這個問題，無論是傳統企業仍是互聯網企業，由於企業的發展速度、形態與數據量等都不一樣，在開始進行中臺轉型時會從不一樣的接入開始切入。像接觸幾家家企業實施同樣，仍是處在數據倉庫的時代，不停的無限知足業務的統計、看數需求，就要嘗試開始數據中臺轉型。一個業務成熟、類似並行業務較多的企業、數據體系成熟的公司往中臺轉型將會是更簡單一點。在一些業務的單一模式，業務變化還很是迅速、不停的試錯的時候，是在想不到有什麼能力能夠往中臺上去作沉澱，不如先搞平臺來作支撐。

在寫這個系列時，個人觀點是很是明確的：我不反對中臺這個概念，反而認爲中颱是頗有必要的，「隨着時間的沉澱，中臺會逐漸的沉澱出來」。

在後面的章會繼續分享本身在實施中的一些方案、思考與碰壁。