場景一：

發(fā)生在上周周末，與一個公司的老板對話：

開門見山的提了一個問題：“想問一個問題， 我想搞一個數(shù)據(jù)中臺。”我驚了一下問到：“啥？搞數(shù)據(jù)中臺？沒燒壞吧？”

“那想搞這個這個數(shù)據(jù)中臺的目的是啥？是要支撐業(yè)務，還是在融資上搞啥？”

“現(xiàn)在這個中臺很火啊，我們也想搞一下。搞個數(shù)據(jù)中臺、再搞個運營中臺，未來面向 xxx 這個群體，就是一個 SaaS?！?/p>

“你真有錢，其它中臺不好說，但是數(shù)據(jù)中臺我認為就公司目前的這個業(yè)務情況，還在初級階段，業(yè)務一直在快速奔跑，組織結構還沒成為業(yè)務發(fā)展的瓶頸。

另外從中臺的難度上來講，在產品、架構規(guī)劃等方面強調的是服務、組件化、業(yè)務抽象等方面，其天然的起點已經比普通業(yè)務形態(tài)與產品有數(shù)量級的差異。

業(yè)務的快速頻繁變化，如何讓中臺來做沉淀？當心中臺的不完善拖累業(yè)務，搬不動這塊鐵，把自己砸暈了。

個人建議，拋開所有概念，就圍繞自己的要解決問題，解析出適合自己的商業(yè)模型到分析模型，在 圍繞分析模型來看如何做埋點與數(shù)據(jù)拼圖，用數(shù)倉的方式，數(shù)據(jù)平臺的實施來支撐好自己。”

老板：“那你幫我出一個方案吧?！?/p>

“我 #￥%……&*（）——”

場景二：

發(fā)生在一個數(shù)據(jù)群，一個同學問到 ：“什么是中臺，什么是數(shù)據(jù)中臺呢，我看的一臉懵逼?！?/p>

“我們公司要招中臺產品經理了，都是來干嘛呢？”

“我看了很多材料，還是沒懂啥叫中臺，最近有個公司出了一本數(shù)據(jù)中臺的書，買來再看看?！?/p>

然后呢，再過幾天，在不同的群不同的場合，類似的很多關于數(shù)據(jù)中臺的對話將繼續(xù)神話般“狗對”著。

中臺的建設是一個復雜的系統(tǒng)工程，正如某大神說的“中臺的建設要想比較成熟且有體系的策略至少要三年以上時間，是要分階段去實施的”，中臺的實施在現(xiàn)階段只能是摸索、實踐，因為大家對中臺的理解是根據(jù)所處的當下環(huán)境與狀態(tài)而進行思考的。

現(xiàn)在中臺的實施將會在做事的方式、思維的高度、系統(tǒng)框架方面有所改變，但是實際上很多打著中臺這個詞，在按照技術組件、技術產品或一個技術平臺的的方式在實施，只是被成為了中臺。

總結自己 2019 年半年職業(yè)生涯，中旬離開一家“大航母”后，這半年也是在跟中臺打交道，并且到現(xiàn)在也是在嘗試去推動一個數(shù)據(jù)中臺化，其中遇到了各種有意思的問題，期間花了漫長時間來盤點問題并嘗試尋找一種適合的演進方案。那我能在這里做點什么呢？

交流了些中臺的實施，一般一上來就喊中臺化的基本入不敷出，不是人員投入問題、就是實施方向以及定位到底是什么， 但是有的企業(yè)用演進的辦法來做實施是個非常不錯的選擇。那成功與失敗的關鍵要素是什么呢？是認知的因素？還是人的因素？還是組織因素？還是期望與落差的因素？標準的中臺是什么樣子？我們如何衡量的是在做中臺而不是在做平臺？做中臺從具體事情層面來講，有哪些維度？該如何落地？現(xiàn)在中臺的書已經有好幾本、網(wǎng)上的各種文章有很多，或多或少的都有在回答”中臺”的相關問題吧。我在后面的篇章也會逐漸展開講我所理解的這些問題。

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

這段話是來自某一個科普文章，在行家的眼里看會怎么樣呢？我特麼想問問這個作者，企業(yè)級數(shù)據(jù)集成、數(shù)據(jù)倉庫、數(shù)據(jù)平臺的定位什么。

寫這個小標題時滿是糾結，心里一直在想如何系統(tǒng)化的能夠比較數(shù)據(jù)中臺、數(shù)據(jù)平臺的的相似性與區(qū)別呢？總結了一些維度，比如復用性、資源整合、能力沉淀、按照業(yè)務橫向相關聯(lián)性把數(shù)據(jù)做深度整合并最終沉淀為公共的數(shù)據(jù)服務能力等等，但發(fā)現(xiàn)每一篇文章，每一個定義都是非常隨性，沒有本質上顯著的區(qū)別，難道在平臺的實施中直接換個詞就能成為數(shù)據(jù)中臺？開始老板非常高期望的我花 1 年時間投入 30 個、50 個研發(fā)、十幾個數(shù)據(jù)產品經理就能完成中臺的建設？到頭來不斷降低的預期、難以忍受的產出與不成正比的投入，最終會怎么樣呢？是顯而易見的？

復用性、組件化、資源整合、按照業(yè)務橫向相關聯(lián)把數(shù)據(jù)做深度整合并沉淀為公共數(shù)據(jù)服務能力這些能力在構建數(shù)據(jù)平臺之處就是必須去解決的問題。資源整合也涉及技術資源整合與數(shù)據(jù)資源的整合沒什么好說的。在兩年前曾經寫過一篇文章《我所經歷的大數(shù)據(jù)發(fā)展史》中曾經專門的研究與分享過數(shù)據(jù)部門的組織結構變化。有感興趣的讀者可以翻出來看一下，關于組織結構這塊我在后續(xù)還會繼續(xù)展開講。

能力沉淀，這個相對來稍廣泛一點、數(shù)據(jù)的接入能力、計算能力、存儲能力、業(yè)務支撐能力、展現(xiàn)能力都算在能力沉淀中，只有想不到沒有做不到。

一般的平臺化是因為業(yè)務需求繁多、響應及時要求高，需要平臺，因為企業(yè)的業(yè)務發(fā)展也是成生物生態(tài)的特點，平臺化也是需要降低成本、提升效率，并如何快速的支撐與相應業(yè)務、但是平臺的邊界非常清晰與管理很規(guī)范。

• 在實施平臺后，可以實現(xiàn)柔性的支撐業(yè)務，能解放技術同學并發(fā)經歷投入到穩(wěn)定性、高性能、技術改造等一系列的其它重要事情上與提高人效，降低公司成本。
• 平臺化后，對業(yè)務分治與歸口的管理，業(yè)務邊界變的更加清晰，歸口管理使得各團隊對自己業(yè)務管理更規(guī)范與高效避免了一件事情找半天沒人理，需要更多的 pmo 與建立更多的流程與規(guī)章制度保障工作。ps 讀到這里是不是有些讀者已經意識到什么了，^_^ 后續(xù)在展開講。

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

回歸數(shù)據(jù)體系建設，企業(yè)的一個營銷方案可能需要幾個禮拜到幾個月，是企業(yè)為中心，生產為向導的模式，但是現(xiàn)在變?yōu)槭袌鰹橹行?，又再變?yōu)榭蛻?& 用戶為向導的持續(xù)規(guī)?；?。企業(yè)的業(yè)務響應能力和規(guī)?；膭?chuàng)新能力，是區(qū)別于傳統(tǒng)企業(yè)與互聯(lián)網(wǎng)企業(yè)的綜合能力的。企業(yè)擁抱這樣的變化就意味著業(yè)務必須逐步完全信息化，對客戶的觸達方式也極具的縮短，中間所有的數(shù)據(jù)記錄模式也發(fā)生信息化的變化。業(yè)務數(shù)據(jù)結構變化，由傳統(tǒng)企業(yè)的單純文本，結構化數(shù)據(jù)轉為非結構化的聲音、視頻、日志、定位信息等。

所以需要數(shù)據(jù)處理的技術架構、產品架構、甚至相關的組織結構也是不同。在這種平臺結構下構建起來的數(shù)據(jù)平臺，是企業(yè)數(shù)據(jù)體系建設的基礎， 搜集好的數(shù)據(jù)需要產生價值。數(shù)據(jù)的搜集、存儲、顯示、產生價值是一個鏈路，相輔相成的。一個公司如何想實施好一個數(shù)據(jù)體系，是需要從數(shù)據(jù)、產品、工具、技術、應用等多個角度，來共同實施與落地才能完全做好的。

數(shù)據(jù)平臺這個詞本身含有平臺，平臺這個詞內部的含義已經包含組件化、服務化、系統(tǒng)化。建設數(shù)據(jù)的主要目的就是屏蔽數(shù)據(jù)異構性、構建統(tǒng)一的數(shù)據(jù)源，這個不管是在數(shù)倉、還是在數(shù)據(jù)平臺都是必須要做的基本任務之一。

與大家一起拆解 2 個內容：

一， 平臺中的關于組件、服務與系統(tǒng)化：數(shù)據(jù)域的建設分為內容建設、工具建設與內容價值探索， 其中工具體系化建設是數(shù)據(jù)平臺的基石，內容透過工具把價值體現(xiàn)出來，工具如何構建與聯(lián)合將會將會發(fā)揮出不同的價值來。

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

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

庫表字典有的公司如果是數(shù)倉主導可能設計的就是給自己服務，里面就是針對數(shù)倉的表做查詢，如果把業(yè)務系統(tǒng)庫表整合進來，那就是面向其它技術群體等一款小的服務產品。

有的人說，這個屬于元數(shù)據(jù)的范疇，我把一個數(shù)據(jù)地圖做扎實做透了，把庫表字典、指標字典里面的所有元數(shù)據(jù)通過有機的關系整合起來查詢多好，并且可以提供對外的查詢服務，或者是在某個流程中，比如 ETL 的過程、調度的過程隨時隨地可以查詢相關的信息與影響因素多好啊。

對沒錯的， 舉得這個例子單個工具與單個工具耦合性很差，缺少相互聯(lián)合作用的功能， 現(xiàn)在有不少公司在做產品時往往都是一個個的工具獨立的存在， 說是成為一個平臺，但是更多的僅是個工具，從架構與定位上來看僅僅是打的一些點，無法聯(lián)合起來形成一個工具體系提供豐富的不同場景應用。這樣案例很多的。

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

二，關于統(tǒng)一，不管是在工具建設、內容建設中不可避免的要去面對多個業(yè)務線、多個業(yè)務系統(tǒng)來做數(shù)據(jù)等整合，可能會涉及到不同的內容需要'歸一化' “統(tǒng)一”。

我們要統(tǒng)一的建模、統(tǒng)一的開發(fā)、建立統(tǒng)一的標準，所謂的統(tǒng)一這個是做數(shù)據(jù)必須要的去完成一個使命，數(shù)據(jù)倉庫本身具備的一個責任之一就是數(shù)據(jù)整合，屏蔽數(shù)據(jù)的異構性，完成對不同術語的統(tǒng)一，如果拿到中臺的這個 id 統(tǒng)一，哪個 ID 統(tǒng)一，本質上只不過是數(shù)據(jù)倉庫、數(shù)據(jù)平臺本身所必須的職責之一。歷史有一個項目 的數(shù)據(jù)項目的目標。感覺與現(xiàn)在有多大的差異性？但服務的范圍不同了。就像 APP 日志采集一樣，埋點統(tǒng)一也是流量必須要做的事情。

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

每個企業(yè)都夢想要一個非常強大數(shù)據(jù)平臺或中臺，對企業(yè)內部提升運營效率、決策效率、在線精準，對外支撐各種場景應用。從實施角度、管理、面對客戶上總結為：

• 在實施上，想把數(shù)據(jù)來龍去脈梳理特別清楚，把數(shù)據(jù)加工、存儲、分析、建模等與數(shù)據(jù)有有關的所有事情都可以輕松的解決；

• 對于管理上，想有一個可以管理一切的入口，把一切的數(shù)據(jù)、口徑、項目、工程等都管理起來；

• 面對的客戶上，想讓客戶可以一站式在這個平臺上獲取到任何想要的東西，并可以獲取到足夠的數(shù)據(jù)應用能力；

為了這個愿望，大部分的數(shù)據(jù)人朝著這個終極目標去努力，但是到頭卻發(fā)現(xiàn)，這是個泥潭越陷越深。大家都在泥潭中不停的掙扎，需要面對天天變化的業(yè)務與嚴重不規(guī)范的數(shù)據(jù)結構、確定什么樣的數(shù)據(jù)源，數(shù)據(jù)的含義是什么，數(shù)據(jù)的上下文是什么，數(shù)據(jù)質量問題，還面臨業(yè)務數(shù)據(jù)中元數(shù)據(jù)的丟失，業(yè)務文檔基本沒有， 問了一圈還沒人知道等各方面的問題。

個人相信以上提出的來的這些問題，不管是數(shù)據(jù)倉庫、數(shù)據(jù)平臺、數(shù)據(jù)中臺都是要幫助企業(yè)達到這些目的的手段，而不是目標本身，以用戶為中心的持續(xù)規(guī)模化創(chuàng)新，是數(shù)據(jù)體系建設的核心目標。

企業(yè)有成千上萬，不同企業(yè)發(fā)展的不同階段，對于數(shù)據(jù)建設的意愿度與驅動力也不同，有的企業(yè)還在準備上馬數(shù)據(jù)倉庫，有的已經建立自己比較完善的數(shù)據(jù)平臺， 而大廠、準大廠已經數(shù)據(jù)中臺化，也或是走在中臺化的路上。

當還在實施數(shù)據(jù)倉庫、一套 BI 的時候，結果有數(shù)據(jù)平臺，當還在努力為了數(shù)據(jù)平臺而在投入資源實施時，有了數(shù)據(jù)中臺。不管三七二十一，搶先發(fā)布博人眼球甚至“高大上“全套解決新概念，隨著阿里的中臺戰(zhàn)略以及鄧中華的神一般的指導中臺問世后，到現(xiàn)在各種培訓都來了，如“中臺產品經理”、 “實施中臺戰(zhàn)略”、 “如何實施中臺” 。甚至在一些數(shù)據(jù)產品經理群里還會有招聘數(shù)據(jù)中臺產品經理。

相信每位老板、每位數(shù)據(jù)建設者在面對數(shù)據(jù)倉庫、數(shù)據(jù)平臺、數(shù)據(jù)中臺這個宏大的多概念混洗在一起時，會是一種怎么樣萬馬奔騰。在實施的過程中到底使用什么方法論？倉庫、平臺、中臺到底有什么區(qū)別？

在開始“這個文章系列”之前，我們先回到企業(yè)上數(shù)據(jù)的基本上來。企業(yè)到底要一個什么樣的數(shù)據(jù)管理體系，到底要什么樣的功能、為了解決什么問題？需要根據(jù)什么原則去設計與實施？

特別贊同一個句話“資源整合，降低成本，同時探索新的商業(yè)應收模式”，這個不管是在平臺階段、數(shù)據(jù)中臺階段都是要必須去滿足。

在這個干中臺的不如講中臺的時期，希望不要繼續(xù)誤導企業(yè)上什么平臺。其實中臺到底是什么并不重要，這只是一個概念。每個公司有每個公司的方法，如何想方設法持續(xù)提高企業(yè)對?戶的響應?才是建設背后最核心的邏輯，更好的服務前臺規(guī)?；瘎?chuàng)新，進而更好的響應服務。不管是中臺還是平臺能夠去的顯著成效就好。

自己也看了很多，但是也沒把中臺這個概念想的特別清晰。其實不用糾結概念，還是那句話：“中臺是什么并不重要，每家公司找到適合自己的方案并推進落地?！?/p>

在上面開篇時提到了企業(yè)上數(shù)據(jù)需要解決的問題與面臨的困難，那該用什么方案去實施？現(xiàn)在數(shù)據(jù)這幾種方案有什么異同點？

一個企業(yè)構建一個數(shù)據(jù)平臺是否已經標志著企業(yè)的數(shù)據(jù)應用能力就完全上一個新的臺階呢？或許不是絕對，與一些企業(yè)管理者溝通起來得到的信息就是成本太高，如何節(jié)省成本？

回顧為什么會提到這個問題，不管是傳統(tǒng)企業(yè)還是互聯(lián)網(wǎng)企業(yè)，因為企業(yè)的發(fā)展速度、形態(tài)與數(shù)據(jù)量等都不同，在開始進行中臺轉型時會從不同的接入開始切入。像接觸幾家家企業(yè)實施一樣，還是處在數(shù)據(jù)倉庫的時代，不停的無限滿足業(yè)務的統(tǒng)計、看數(shù)需求，就要嘗試開始數(shù)據(jù)中臺轉型。一個業(yè)務成熟、相似并行業(yè)務較多的企業(yè)、數(shù)據(jù)體系成熟的公司往中臺轉型將會是更簡單一點。在一些業(yè)務的單一模式，業(yè)務變化還非常迅速、不停的試錯的時候，是在想不到有什么能力可以往中臺上去做沉淀，不如先搞平臺來做支撐。

在寫這個系列時，我的觀點是非常明確的：我不反對中臺這個概念，反而認為中臺是很有必要的，“隨著時間的沉淀，中臺會逐漸的沉淀出來”。

在后面的章會繼續(xù)分享自己在實施中的一些方案、思考與碰壁。