數據是企業真正能發揮價值的武器，能使用數據的場景有很多，希望大家一直對數據懷有敬畏之心，結合場景化需求去落地，將數據逐漸沉淀成企業的資產；其次更多的從數據的角度去發現問題、解決問題、改進問題。

數據是企業真正能發揮價值的武器，能使用數據的場景有很多，希望大家一直對數據懷有敬畏之心，結合場景化需求去落地，將數據逐漸沉淀成企業的資產；其次更多的從數據的角度去發現問題、解決問題、改進問題。

隨著企業的快速發展，在規模不斷擴大的同時業務逐漸變的多元化，有更多的業務數據產生，為企業進一步實現業務數據化和數據業務化提供了更多的可能性。

但是，由于各種歷史原因，導致企業數據煙囪林立，數據理解、認知以及分析斷層，缺數據、缺標準、缺治理，知數據難、懂數據難、要數據難，需要如何規避系統的重復建設，讓系統復用的同時快速支持多元化前臺業務的迭代更新、靈活創新是企業數字化轉型過程當中必然會面臨的問題與困境。

為了，進一步和大家一起認識到中臺的本質，統一認知偏差，本篇按照順序介紹如下：

1. 中臺建設之前需要知道的事情
2. 中臺建設的方法論
3. 中臺建設的內容

最近外面已經各種關于中臺的文章，真可謂是百家爭鳴，有的人說了建設中臺的各種概念，有的人說了建設中臺的坑與雷，有的人說了建設中臺的方法——對于建設中臺問題的本質總是避而不談。

遇到從沒有真正落地實踐過的人，已經要跳出來做行業的布道者、先行者，真的是打字不用負責任的年代，這種行為是擼羊毛還是收智商稅，亦或是其他一些什么東西，想必稍微有點辨別事物真偽的人，都知道在干什么。

中臺的本質其實很簡單，總結成一句話就是：通過資源集中化的方式匯聚整個企業的運營數據能力，產品技術能力，快速的支撐各前臺業務迭代更新。

那么，如果企業想建設中臺，需要通過什么樣的方式來判斷和評估，適不適合建設中臺呢？

個人經驗，可以從以下幾個方面來進行判斷與評估

1.1 明確建設中臺的目標與意義是什么

中臺是以場景化業務驅動為中心，具有可服用能力的有機組合。目標是為了能夠快速的賦能業務，進行落地實施、改造、試錯、轉型；意義是為了快速提升組織之間的效率，最終，達到降本增效。

為什么說要明確建設中臺的目標與意義呢？

畢竟，認知這個東西真的很可怕，很多人認為企業建設中臺就是蛋糕的重新分配，其實不然。任何事物的存在必然有它存在的道理和原因，己所不欲，勿施于人道理，想必大家都懂。

企業在建設中臺之前如果不統一人員認知的話，必然在中臺的建設過程中就會四面碰壁，各種扯皮、推諉，面臨多方面的阻礙，陷入一個被動的局面。

個人經驗，需要做好兩個方面：一方面，是職責邊界的劃分問題，需要明確知道那些東西該中臺來做，那些不該中臺來做，需要業務部門自己去做；另一方面，更多的是涉及溝通的藝術和做事情的方式方法。

1.2 是否具備建設中臺的條件與時機

1）戰略分析

企業需要從公司整體的戰略布局、核心競爭力、戰術方法、業務方向等維度來，明確知道自己的優劣勢綜合判斷，現階段做與不做中臺對于企業未來發展的利弊都有哪些，對于未來業務影響到底有多大。從而進一步明確企業建立中臺的目標是真的想賦能業務，做到真正的降本增效，還只是單純的想對外秀肌肉。

2）業務調研

只有深入業務，明確業務單元后，梳理出業務價值鏈條后，拆解各個業務系統的情況，才能評估出業務是否有值得中臺化的場景。

同時，也能明白就算通過組件化、模塊化、標準化、解耦等方式來拆分系統和業務，再基于數據服務化的方式，就真的能快速支撐前臺業務的迭代更新，從而不斷的沉淀能力，做到服務和體驗都統一升級嗎？

3）數據調研

基于業務統計出數據來源，確定數據資源分類，做好數據評估，確定當前數據容量，結合業務運行頻度，數據產生效率，預測數據成長規模。

因為，建設中臺是在全域級數據匯集之后，做數據清洗、數據治理、數據資產管理等工作之前。所以，需要對數據使用情況進行盤點，為后續中臺建設過程中數據流動和使用機制提供有力依據。

4）技術調研

通過技術現狀調研，可以提前了解技術落地情況、人員技術情況，做好建設中臺的技術人員準備，提前規避風險。

5）組織分析

通過高層訪談、組織架構分析，明確企業中臺的目標與意義，同時調研分析各個事業部對建設中臺的看法，為后續中臺的溝通落地、推廣做好前期準備。

1.3 中臺的用戶和客戶是誰

中臺的用戶和客戶其實主要就是企業所有事業部、業務線的人，只有先把對內的賦能做好了，或許才有機會對外賦能。與此同時，企業需要把握好短期利益與長期利益的博弈和廝殺，中臺需要與各個事業部、業務線定義好職責邊界。

為什么說要定義好職責邊界？

就目前而言，任何企業確定要啟動中臺戰略，一定會涉及組織、業務、技術等多方面的架構調整，也一定會出現短期的矛盾與沖突。

企業的組織架構調整，是一個相對敏感的話題。畢竟，只要組織架構調整后，一定會牽扯到利益關系。

這種矛盾和對立關系，需要如何平衡好，稍有不慎，就帶來很多不必要的麻煩。

所以說，企業建設中臺需要有自己的主賽道，做到兼聽則明，偏信則暗，才能真正意義上建設好中臺。

1.4 中臺每個階段的效果如何來驗證

中臺每個階段的效果如何來驗證呢？

需要如何評價企業中臺建設的效果，驗證每個階段是否達到企業建設中臺的預期目標呢？

任何一個產品都存在生命周期，中臺的建設也是一樣，在不同的階段產品側、研發側、運營側所運用的策略，評估的方法也不盡相同。

對于數據中臺來講，更多的是如何助力提升運營、研發效率，快速的將數據的價值挖掘出來，并縮短周期。

對業務中臺來講，更多的是基于數據的表現力來判斷，如基于現在建設的中臺是否真的能快速的減輕前臺的負擔，提高前臺響應速度。

小結

不取決于公司大小、數據量多少，關鍵取決于是否需要快速擴張。

個人建議，千萬不要盲目跟風去啟動中臺戰略，看到別人家做了中臺就也要做，一定要三思而后行。從多個角度去衡量去思考，畢竟各家企業在很多方面都存在較大的差異化。盲目去做，到最后會變成事與愿違、弄巧成拙，那就尷尬了。

企業是否建設中臺跟公司大小、數據量大小、業務線多少其實沒有多大關系，關鍵取決于公司業務是否需要快速擴張以及數據使用的方式。其次，希望大家明白，中臺不是一個產品，是一個戰略和體系，是以數據驅動業務發展為主，讓一切業務數據化，一切數據業務化。

二、中臺建設的方法論

在搞清楚企業到底要不要建設中臺之后，大家一定會問，對于中臺的建設到底應該如何落地呢？有沒有一些行業落地的經驗和方法，可以參考呢？

答應一定是有的。任何事物的發展變化都是有規律可循的，中臺的建設也是一樣。雖然，各家企業存在一些差異化，但是建設中臺的思想和方法都是相通的。

下面就和大家一起來探討下，建設中臺的一些方法和步驟。

2.1 業務中臺方法論

在前面的文章中，提到過業務中臺是為了沉淀業務通用服務能力，以服務化形式提供公共業務組件，為企業快速變化的場景化業務應用提供專業、穩定、高效、安全的共享服務，提升前端應用開發效率，快速響應實現創新需求，實現業務創新、數據共享和業務能力協同。

說的簡單通俗一點，業務中臺更多是建設通用的公共基礎業務和通用服務。例如，用戶中心、賬戶中心、會員中心、服務中心、交易中心等。

那么，我們需要通過什么樣的方法和步驟去評估出業務中哪些功能點適合做中臺化呢？

1）業務抽象

明確中臺建設目標及與意義之后，可以從以下幾個方面對業務進行抽象處理

• 需求分析：由于企業建設中臺的需求多數來源于公司高層領導的一句話，需求很難明確具體，只能從企業建設中臺的目標與愿景出發，進行拆解和分析。這樣做的目的，一方面，是為了知道參與企業建設中臺工作當中的個體和組織有哪些人，他們的關注點和擔心點是什么；另外一方面，是為了明確在企業建設中臺過程中，量化好建設中臺的價值，知道企業高層領導的期望是什么，知道每個階段中臺能給業務解決什么問題，帶來什么價值，實現什么目標。
• 競品分析：通過競品分析，取其精華去其糟粕，加深行業對于中臺的理解和認知。目前各家企業主要都是看阿里巴巴建設中臺的落地經驗，然后，進行合理借鑒和參考。只有通過競品不斷的學習，加深自己對于中臺的理解和認知，才能真正找到可借鑒的地方，從而節約試錯成本。
• 功能分析：體驗各個業務線的產品，從產品的交互流程、業務規模、服務方式、性能要求等維度來了解各個業務線的產品現狀，才能找到各個業務存在的問題，從而，提取出各個產品的共性需求。
• 業務分析：從業務流程、業務對象、業務規則、業務價值四個維度出發逐個拆解各個業務模塊。
• 用戶分析：貼近產品的用戶，做用戶分析和調研，明確各個產品業務線的用戶是誰、用戶的使用場景是什么以及用戶需要是什么。

只有基于需求分析、競品分析、功能分析、業務分析、用戶分析五大維度進行分析，才能找到真正的找到適合做中臺化的場景需求。

2）方案設計

通過基于企業建設中臺的目標與意義，通過需求調研和業務分析，找到適合做中臺化的場景需求之后，需求才能正式開始進行業務設計和架構設計。

業務設計目的，一方面是明確產品的模式，與多個業務方達成一致，從業務流程、產品原型、業務規則三個方面做好功能規劃，知道做這個需求的目的是什么，能為前臺業務提供什么能力，解決什么問題；另外一方面，需要做好風險評估，預估上線后的切換成本有多高，制定出應對措施與機制。

架構設計目的，一方面是梳理業務落地，解決業務功能系統的復雜度帶來的問題；另外一方面是確定與上下游系統的依賴關系，為建立統一的標準化做準備。

個人經驗，只有做好詳盡的需求調研與分析，定義好職責邊界，了解各個業務合作團隊的工作環境和系統業務邏輯之后，進行多輪的需要評審，才有可能做好業務設計和架構設計。

在必要的時候，需要進行制定人員輪崗的方案和機制，只有這樣才能知道各個業務線目前的痛點是什么、訴求是什么。

3）方案落地

對于大多數企業建設中臺都是一個樣，瞎子過河，不知深淺。在摸索的過程當中都會遇到各種坑與雷，真可謂如人飲水，冷暖自知。

在中臺項目推進的過程當中，由于業務的錯綜復雜，人員的認知不統一，需要如何進行有效的溝通與推進，真的是極度考驗智商和情商的一個過程。

如果，稍有不慎，沒有處理好各個業務方人員之間的利益和關系，真的會一著不慎，滿盤皆輸。

那么，在方案落地過程中，需要如何做好項目管理和項目推進呢？

• 在方案落地開始之前，需要做好項目啟動會和產品啟動會，必要時候需要和各個業務方建立合伙機制共同推進，這樣做的目的一方面是為了統一認知，達成目標一致，確保項目能夠順利的進行；另外一方面，是確定上下游部門的排期、制定協同機制；
• 在方案落地過程當中，需要隨時溝通項目的進度，可以通過日報、周報、月報等方式，讓各個業務方及時的知道和明確目前項目的進展情況和風險，及時發現問題，處理問題；
• 在方案落地執行之后，及時進行項目復盤，分析原因，及時調整優化迭代方案，提前規避風險。

4）上線運營

企業建設中臺是一個長期的過程，在不同階段所使用的運營策略不盡相同，中臺部門需要自己把握好中臺產品的發展節奏，才能真正做好中臺相關的運營工作。

2.2 數據中臺方法論

數據中臺概念最早于2015年年底被阿里巴巴首次提出，是一個承接技術，引領業務，構建規范定義的、全域級可連接萃取的、智慧的數據處理平臺，建設目標是為了高效滿足前臺數據分析和應用的需求。

數據中臺，主要涵蓋了數據資產、數據治理、數據模型、垂直數據中心、全域數據中心、萃取數據中心、數據服務等多個層次的體系化建設方法。

數據中臺具有數據獲取與存儲、數據計算與處理、數據共享與協作、數據應用與價值探索以及數據服務與服務運用等全鏈路一站式數據服務的能力，緊密貼合業務，探索業務場景中的價值，助力企業數字化、智能化轉型。

額，看到這么一大堆專業術語的名詞解釋，想必大家和我一樣，真想反問一句“sorry，I don’t understand what you’re saying”。

那么，數據中臺到底是什么？

通俗一點，數據中臺是全域級、可復用的數據資產中心與數據能力中心，可以提供干凈、透明、智慧的數據資產與高效、易用的數據能力，使得業務能夠數字化運營。

數據中臺主要負責大數據統計分析相關的DaaS和PaaS相關基礎能力的服務建設。

就目前而言，市面上數據中臺的方法論也是集百家之長，最典型的代表莫過于阿里巴巴數據中臺建設的方法論。

無論是阿里數據中臺的建設方法論還是其他企業建設數據中臺的方法論，其最核心的思想都來自于數據倉庫領域關于數據倉庫規劃實施和指標體系建設的方法。

稍微知道數據倉庫發展史的人都應該清楚，在數據倉庫領域中一直存在兩套截然不同的方法和體系在相互暗自較勁。一個是數據倉庫之父Bill Inmon所倡導的至上而下的方法，另一個是Ralph Kimball大師所倡導的至下而上的方法。

對于數據倉庫體系結構的最佳問題，其實始終存在很多不同的看法，甚至有人把Ralph Kimball和Bill Inmon之爭稱之為數據倉庫界的“宗教戰爭”，至于誰好誰壞，只能說一千個人眼中就有一千個哈姆雷特，在這里就不做過多的深究，只能說適合的是相對較好的。

阿里數據中臺的建設主要遵循三個One的概念：One Data，One ID，One Service。從中可以看出，數據中臺不僅僅是匯聚企業各種數據，而且讓這些數據遵循相同的標準和口徑，對事物的標識能統一或者相互關聯，并且提供統一的數據服務接口。

其中，One Data，核心CDM層采用的是多維模型，主要選擇了以Kimball維度建模為核心理念的模型方法論，同時在指標設計的方法論基于Kimball方法中的粒度建模的方法，進行了一定的升級和擴展，構建了阿里集團的數據架構體系。

那么，我們需要通過什么樣的方法和步驟去建設好數據中臺，才能融合匯集整個企業的數據，打通數據之間的隔閡，消除數據之間的不一致性呢？

在規劃做數據中臺架構設計之前，要明確需求是什么，知道要接入什么數據到數據中臺中來，再根據數據接入的實際情況，進行技術選型，合理評估計算和存儲資源的配置。

數據中臺的愿景是接入全域級的數據。

但是，筆者經常會反問自己，數據中臺真的需要全域級的數據嗎？

想必大家脫口而出的答案一定會是“需要”。

剛開始，和大家的想法也是一樣的，但是在真正落地開始建設數據中臺之后，才翻然醒悟。其實，在沒有找到場景化的需求之前，給中臺再多數據其實都是徒勞。靜態的數據價值永遠沒有流動數據的價值大，沒有基于業務真正的使用起來的數據，價值為零。

所以，建設數據中臺需要以場景化需求為中心，做好業務調研和需求調研，然后以數據多樣性的全域思想為指導，采集與引入全業務、多終端、多形態的數據才是相對合理的。

個人經驗，數據中臺的建設主要包括數據資產、數據治理、數據模型、數據服務四個部分。

1）數據資產

數據即資源的概念，伴隨著大數據時代的發展逐漸深入人心。企業都希望通過數據交換共享和數據服務應用的方式，不斷積淀的數據后發揮它的價值。

但是事實上，若沒有通過恰當有效的管理方法和手段，數據可能會變成企業的負資產。因為，企業只有對數據懷有敬畏之心的認知，才可能發揮出數據背后所隱藏的價值，要不然反而會被數據所害。

基于數據資產管理白皮書看來，主要從數據標準管理、數據模型管理、元數據管理、主數據管理、數據質量管理、數據安全管理、數據價值管理以及數據共享管理等方面來做好數據資產管理。

但是，在實際企業做數據資產管理落地的情況之下，不會完全按照這個所謂的行業標準的，這個行業標準太理想化?，F實情況是各家公司的情況和歷史原因都不一樣，所以不會完全按照這個標準來，更多的會是各種差異化的做法。

因為，任何的數據資產管理做到最后都會變成數據治理。

2）數據治理

說到數據治理，想必身邊很多數據倉庫的研發小伙伴天天自嘲說自己就是個提數工程師，每天的工作就是幫業務提取數據、核對各種指標。時間長了，小伙伴們對自己的工作設定，開始懷疑人生，就更不用說業務人員對于系統數據的準確性、一致性極度不信任了，導致這些問題的根本是數據質量問題與指標口徑的原因。

數據治理是王婆娘的裹腳布，也是政治斗爭的絞肉機。治理與管理永遠是兩個矛盾的對立面，數據質量歸根結底主要是受到人的影響，僅僅試圖依賴技術手段解決管理問題的效果往往甚微。

因為，任何的數據治理方案最后還是需要人去落地、去實施。它是一個漫長而持續的過程，沒有立竿見影的捷徑可以走，要想保障數據資產的完整性、準確性、一致性、及時性，只能共同保證正確的信息，用正確的形式，在正確的時候，交付給正確的人，才能根據指定的規范開發模型、校驗模型、管理模型，為業務提供統一、準確的數據。

3）數據模型

數據模型，其實就是數據倉庫領域中的模型范疇，通過標準規范數據架構與研發方式，統一基礎層、公共中間層、應用層的數據分層架構模式，通過數據指標結構化規范化的方式實現指標口徑統一，實現數據的標準化。

4）數據服務

數據中臺需要對外提供統一主題式服務，主要是通過構建服務元數據中心和數據服務查詢引擎，面向業務統一數據出口與數據查詢邏輯，屏蔽多數據源與多物理表，降低使用成本和復雜度。

從原則上來說，數據中臺只提供通過數據服務能力，更多個性化需求需要各系統在業務層面自己去實現，用協同的方式簡化系統上層業務的使用，提升對前臺業務需求的響應效率，以此達到降本增效的目的。

通常提供采用以下三種服務方式：依賴接口的服務、依賴工具的服務和依賴數據的服務。

• 依賴接口的服務：通過數據接口標準化的方式，提供統一的數據服務在線查詢視圖，讓開發者能夠快速、簡單的訪問數據服務；
• 依賴工具的服務：通過數據開發可視化的方式，提供服務接口的可視化配置，開發者通過配置SQL的方式產生Api，降低接口開發的要求和成本，也便于后續的管理和維護；
• 依賴數據的服務：通過數據封裝的服務方式，主要有Data Api 、SDK 、引擎等多種方式數據服務方式。

中臺的建設主要圍繞著規劃、治理、整合、共享四個方向來進行演進。

首先，做好企業的全域級數據接入，做好數據資產盤點、整合、分析、確保全域級數據一致性、準確性、可復用性，為前臺提供數據資產、數據創新、數據監測與數據分析等服務，最終實現數據資產的價值最大化。

在具體建設中臺的策略方面，需要結合公司的發展戰略和業務特點，選擇明確數據資產對象，以大數據小場景的方式去驗證場景化需求。

三、中臺建設的內容

基于前面中臺建設需要知道的事情和中臺建設的方法論，希望大家能有所收獲。

筆者在這也盡量多說些細節方面的東西，統一大家的認知，避免大家知其然，不知其所以然，如果是這樣的話，與其一知半解不如全然不知，權當罪過，良心難安。

中臺建設的內容主要分為三大塊：One ID（一個用戶賬號）、One Data（一個數據平臺）、One Service（一個業務平臺）服務體系。

3.1 OneID體系

One ID的前身其實是ID – Mapping。

通俗一點，ID-Mapping是用來關聯識別同一個用戶ID的。ID-Mapping通過把多份來源于不同業務系統的數據源，通過一系列技術手段、方法識別為同一個主體或對象。通過直接或者間接的方式，識別同一臺設備，同一個用戶，同一家企業等等，業內形象地理解為用戶畫像的“拼圖”過程。

因為，一個用戶的行為數據、屬性數據通過業務過程數據化的方式，記錄存儲到不同的業務系統。從各個業務系統的數據來看信息都不一定是完整的，看到的只是用戶在某個系統或者某個業務一個片面的畫像。

而ID-Mapping技術能夠將碎片化的數據全部串聯起來，消除數據孤島，形成一個完整的用戶信息視圖，讓數據在不同的領域發揮出相應的價值。

那么，企業需要如何做好ID-Mapping呢？

1）基于物理設備做Mapping

通過唯一標識符作為一個用戶ID號。常用的標識用戶的唯一標識符的有：MAC位址、IMEI（手機序列號）、IMSI、Android ID、UDID 、UUID、OpenUDID、IDFA、Telephone、身份證等。

這種方式是最直接的，可以通過精準地記錄和標識識別出一個用戶。通過利用硬件設備碼生成一個統一的設備碼，利用一些強賬號來關聯標識用戶。

這個層面上主要的技術難度在于ID的穩定性、唯一性、準確性和持久性。

2）基于用戶行為做Mapping

在前面的文章中，筆者就說到過，大數據中的大就是少，越是真實的業務數據，數據量就越大，可用的信息比例就越少，更多的是噪音數據。如果你擬合了噪音數據，那就被數據綁架了，所以不要只看數據，更多地從業務層面上多思考問題。

在做ID-Mapping識別也是一樣，同一個用戶的數據存在在不同的業務系統，在多份數據、多種ID之間存在著一對多、多對多的關系，需要如何統一這些ID。

哪些ID是可以相信的？置信度如何去評估？

業內通常采用的方式是人工規則和機器學習兩種方式相互結合，從多個緯度來幫助確定身份的ID的準確度，做到收斂、分配、分裂、聚合。

基于業務分析梳理出人工標注（正樣本和負樣本），然后基于人工規則做正向、反向的反饋，這里的業務規則更多來源從業者的經驗與智慧。梳理規則目的是確定在不同的業務場景下，是不是為同一個用戶，同時也為后續機器學習的結果做AB測試的校驗和輸入。

常用的機器學習方式和策略，有單模型和多模型兩種方式。模型是機器學習的結果，而這個學習的過程稱為訓練（Train）。

一個訓練好的模型可以被理解成一個函數：y = f(x)，這個 y 可能是一個數值（回歸），也可能是一個標簽（分類）。模型是基于大量的數據，然后基于對數據訓練得到結果，當然數據越多，訓練的結果相對就越準確。

單模型的意思就是通過一種方式的訓練過程得出結果；多模型就是兩種以上的訓練方式得出結果。

相對來說，多模型訓練的準確度會比單模型訓練準確度要好。多模型在訓練時更多需要考慮融合問題以及融合后的判斷機制。

3）基于相似用戶做Mapping

通過把行為相似的用戶給合并起來，物以類聚，人以群分的道理想必大家都懂。先根據用戶歷史消費行為幫你找到一群和你口味很相似的用戶；然后根據這些和你很相似的用戶再消費了什么新的、你沒有見過的物品，然后做內容物品推薦。

說的簡單一點，就是一個給用戶聚類的過程，把用戶按照興趣口味聚類成不同的群體，給用戶產生的推薦就來自這個群體的平均值。

本質就是用戶與物品之間的關系矩陣。

大致的思路是，先準備用戶向量，理論上來說可以給每一個用戶得到一個向量；其次用每一個用戶的向量，兩兩計算用戶之間的相似度，設定一個相似度閾值或者設定一個最大數量，為每個用戶保留與其最相似的用戶，為每一個用戶產生推薦結果，從而做到基于用戶興趣做相似用戶Mapping。

小結

ID-Mapping絕對不是一個簡單的按照key和value匹配的過程，在實際的落地過程中會遇到各種困難。

• 數據中往往帶噪音數據，如果你擬合了噪音數據，那就被數據綁架了，識別結果就不準確，需要考慮如何提升數據質量問題。
• 對于僵尸用戶或者長期不用的用戶，保存數據是沒有意義，浪費資源而且數據長期不更新后也會導致數據不準確，需要考慮到ID-Mapping后數據的更新頻率機制。
• 打通后的數據是HDFS的離線數據，需要如何保證ID之間的Mapping關系，選擇何種分布式數據庫、表如何設計、如何做到數據更新時才不會影響線上服務呢？

在中臺建設的過程當中，最核心的是OneData體系建議。

數據體系建設目的是建立企業統一的數據公共層，從設計、開發、部署和使用上保障數據口徑的規范和統一，實現數據資產全鏈路管理，提供一套完整、規范、準確、標準的數據體系，可以方便快速的?撐前臺的數據應用。

該體系主要包含：全局數據倉庫規劃、數據規范定義體系、數據模型規范設計、數據連接萃取、數據運維監控、ETL規范研發等以及支撐整個體系從方法到實施的工具體系。

那么，企業需要如何做好數據中臺設計呢？

1）數據模型層次設計

基于Kimball維度建模的方式，將數據分為操作數據層（ODS）、公共維度模型層（CDM）、應用數據層（ADS）。

• ODS層：把來源于其他系統的業務流程數據，同步到數據倉庫當中來，中間僅做簡單整合、非結構化數據結構化處理或者增加標識數據日期描述信息，不做深度清洗加工。
• CDM層：存放明細事實數據、維表數據及公共指標匯總數據。CDM層又細分為DWD層和DWS層，分別是明細寬表層和公共匯總數據層，采取維度模型方法基礎，更多采用一些維度退化手法，減少事實表和維度表的關聯，容易維度到事實表強化明細事實表的易用性；同時在匯總數據層，加強指標的維度退化，采取更多寬表化的手段構建公共指標數據層，提升公共指標的復用性，減少重復的加工。
• DIM層：建立一致的數據分析維表，降低數據計算口徑不統一的風險。
• DWD層：標準化、維度補齊、異常處理。
• DWS層：基于業務場景做行為數據組織、提升公共指標的復用性。
• DWM層：寬表集市、跨過業務場景、行為數據組裝。
• ADS層：存放數據產品個性化的統計指標數據，根據CDM層和ODS層加工生成。面向應用，個性化指標加工、基于應用的數據組裝。

需要遵循圖中的調用方式，但是，并非絕對，有時候在特殊的業務訴求下會違法建模規范的。

2）數據規范定義設計

中間層（CDM）構建過程以維度建模為理論基礎，構建總線矩陣，劃分業務板塊、定義數據域、業務過程、維度、度量、修飾類型、修飾詞、時間周期、派生指標，進而確定維表、明細事實表、匯總事實表模型設計。

數據域是指面向業務或數據本質分析，歸納總結出來的數據集合。為保障整個體系的生命力，數據域需要抽象提煉，并且長期維護和更新，但不輕易變動。

在劃分數據域時，既能涵蓋當前所有的業務需求，又能在新業務進入時無影響地被包含進已有的數據域中或者擴展新的數據域。

一致性指標定義即描述原子指標、修飾詞、時間周期和派生指標的含義、類型、命名、算法，被用于模型設計，是數據建模的基礎。

• 原子指標：在某業務過程下具有明確的業務含義最小度量單元，原子指標不可再拆分，在設計時以動作+度量構成。比如：支付金額(pay_amt)、停留時長(stay_time)；
• 時間修飾詞：數據統計的時間范圍或者時間點，如最近1天、最近7天、最近1小時；
• 其他修飾詞：是對指標業務場景的限定，如用戶等級高、終端（App、PC、小程序）；修飾詞歸屬到某個抽象的修飾類型，比如：用等級、終端類型等；
• 派生指標：由原子指標、時間周期修飾詞以及其他修飾詞組合而成。其中原子指標為單一選擇，時間修飾詞為單一選擇，而其他修飾詞可以多選。派生指標繼承了原子指標所在的數據域、數據類型、算法，保障指標的一致性。原子指標、時間修飾詞、其他修飾詞的命名確定后，派生指標的命名也被確認下來。

在數據建模的過程中需要遵守開發規范。比如，表、字段、分區、任務的命名、類型都需要做一致性定義，公共代碼的一致性規范定義，確保整個模型的規范、易理解、易查找。

同時，每個表責任到人，可以找到對應的技術責任人，技術責任人對表的處理邏輯、數據質量、產出時間、以及規范性等負責。

在必要的情況下表的責任人與HR系統打通，當責任人離職必須把負責的所有表轉移給接手人，否則不予辦理離職手續，避免表無責任人情況。

ODS層、CDM層的表一般有技術責任人即可；ADS層表除了要有技術責任人和業務責任人，業務責任人主要是為了避免業務已經停止使用，技術也不敢下線數據加工任務的情況。

3）數據模型設計

維度建模是專門用于分析型數據庫、數據倉庫、數據集市建模的方法，維度建模以分析決策的需求出發構建模型，構建的數據模型為分析需求服務。因此它重點解決用戶如何更快速完成分析需求，同時還有較好的大規模復雜查詢的響應性能。主要包括維度表設計、事實表設計、匯總表設計。

維度表是表示對分析主題所屬類型的描述。通常來說維度表信息比較固定，且數據量小。

事實表是表示對分析主題的度量。事實表的度量通常是數值類型，且記錄數會不斷增加，表規模迅速增長。通過合理設計事實表使其有效地組織和保存業務數據，沉淀為企業核心數據資產。

事實表是數據倉庫維度建模的核心，一切數據應用和分析都是圍繞來它展開的，穩定的數據模型能大幅提高數據復用性；根據平臺和業務特性，適當冗余的事實表能提高數據易用性并降低平臺計算成本。

維度建模常見的由星型模型、雪花模型和星座模型三種，數據中臺設計一般采用星型模型。

小結

數據體系建設的大致流程如上圖所示，在實際落地過程中還涉及到一些其他的外部系統依賴，比如調度系統、元/主數據質量管理系統、離線/實時的計算平臺、數據質量監控系統等等，總的來說數據體系建設成敗的關鍵在于是否具備全方位的掌控能力。

在建設的過程中，需要能做好以下幾個方面：

• 企業人員需要統一對數據的認知，特別是高層領導更加需要具備數據驅動的戰略思維。高層領導的自上而下是企業數據戰略后續人、財、物持續投入的保障，只有自上而下和自下而上都具備統一的數據認知，才能推動數據應用場景落地，發揮出數據的價值；
• 基于數據和業務調研，制定一套符合企業業務現狀、數據現狀、技術現狀以及符合企業未來發展的數據建模規范。數據建模方法本身是大同小異的，關鍵點是需要一套標準的規范，才能保障其正常的流轉運行，包括需求對接規范、數據分層規范、命名規范、開發規范、數據權限隔離規范、數據安全隱私規范等；
• 在數據中臺數據體系建設的過程當中涉及到多個業務團隊的共同協作，人員的變化以及業務的發展變化很難靠人保證規范的持續執行，只有依靠數據相關的工具來保障規范的正常執行，如果能把數據建模規范、數據質量監控、數據地圖等工具規范融入到工具使用當中就更好；
• 無論是戰略的執行、方法規范的制定、數據工具的落地都需要有組織人員保障?；跀祿卫淼姆结槪祿瘑T會運用自上而下頂層設計方法，制定符合企業現狀短期和長期的建設目標、規范、制度并且推動執行，同時將數據團隊的考核與業務發展進行雙向綁定，共同推動業務數據化和數據業務化的發展。

在做數據服務平臺建設之前，先和大家來聊一聊“一切業務數據化，一切數據業務化”這句話背后隱藏的本質，統一認知后，方能透過現象看到本質，不會被事物的假象所迷惑。

1）業務數據化

業務數據化可以理解為就是把我們現實世界中業務的對象、業務的生產過程，通過連接的方式虛擬到我們的數據世界，每一次的連接都有一個數據交互的產生，形成數據記錄，最終能夠和業務產生一一映射和對應。

業務數據化可以細分為：業務對象數據化、業務過程數據化以及業務規則數據化三種。

1. 業務對象數據化：所有企業的業務基本上都是基于人、物、場景三個維度來構建業務生態的，因此有人、物、管理等是重要信息對象 。比如，一個產品的產品屬性、產品的編碼、產品價格等，這些其實都是需要通過數據化的方式來進行數據建模。
2. 業務過程數據化：能夠自動記錄數據的流動過程。比如，購買商品的下單過程、日志記錄、數據埋點，以及結合各種應用場景產生的數據。
3. 業務規則數據化：其實比較難的事情，所有企業都在做，但是效果確都不是很好，需要不停地優化迭代。在業務過程中給業務行為提供業務流程上面的指引，可以落地的指引的邏輯規則和業務規則 。比如游戲規則、購買規則、業務規則等，這些規則都是行業人群總結出來的經驗與智慧，只有做到數字化才能變成數據，從而做到業務規則上和應用上真正意義上的解耦。

所以說，業務數據化是企業每個部門都要去做的事情，并不是數據中臺的事情，是整個企業的事情。

只有先從源頭保證數據的質量，才能發揮出數據的真正價值，無論是做業務數據化或者數據業務化都離不開數據，數據質量是很重要，不做好做數據中臺就沒有數據，真的會淪為巧婦難為無米之炊的窘境。

2）數據業務化

數據業務化是業務數據化的一種延伸，即將收集的數據用于業務或產品本身，將數據轉變為帶有建議性的信息幫助客戶實現商業目的與價值。數據服務化主要包含數據智能和數據創新兩個方面。

比如，現在有把用戶數據打包賣給其他人，其實還稱不上真正意義的數據業務化。因為，數據并未轉變為面向客戶實現商業目的的內容，可以定義為數據交換的一種方式。

比如，當一個電商平臺，根據用戶之前的購買、流量記錄，通過算法判斷用戶的購買偏好，推送商品給用戶，這個階段才真正意義上算的上是數據業務化的開始。

所以說，只有先用過業務數據化的方式，打破業務之間的數據壁壘，讓數據在各個業務之間像水一樣來回流通，才能滿足靈活多變的數據需求，讓全域流通和按需自助實現。

那么，需要建設那些數據服務呢？

數據來源于業務，服務來源于場景。只有先基于業務梳理出場景化需求，才能更好的使用數據、利用數據與應用數據。

常見的數據服務有基礎畫像服務、標簽畫像（用戶畫像、物品畫像）服務、用戶圈群服務、算法模型服務以及各種搜索/廣告/推薦SDK引擎服務等。

比如，接口的服務是通過數據接口標準化的方式，提供統一的數據服務在線查詢視圖，讓開發者能夠快速、簡單的訪問數據服務；用戶圈群服務是基于用戶標簽篩選人群，在推薦/精準營銷場景中，可以通過接入這個服務，來實現商品推薦和精準廣告投放等。

所以說，首先基于業務來源的數據做基礎數據的服務，提供數據指標跨域自助獲??；其次需要做好標簽畫像服務，為用戶和內容物品向量化處理；最后基于場景，提供數據服務和能力。

只有當數據在業務層面上做到全域級的流通，才能做好業務數據化，做好數據的能力延伸。

小結

任何企業的數據主要來源于業務，只有先打破業務之間的數據壁壘，實現業務數據化，才能真正的對應前臺靈活多變的數據需求。

基于業務面向的對象，把跨業務板塊、跨數據域的特定對象數據進行整合，形成對象的全域標簽體系（人的標簽體系、物的標簽體系、場景的標簽體系），才能方便后續數據的深度的分析、挖掘、應用。

中臺在構建服務時需要考慮到可復用性的，大家也都希望每個服務就像一塊積木，可以隨意組合，非常靈活，只需輕量級的組裝模塊服務就可以為前端快速的實現，從而達到降本增效的目的。

但是，是否業務中臺有車身和底盤，數據中臺發動機和電氣設備，就真的能做好一個汽車呢？

總結

“道”是宇宙萬物的根源，世間的萬事萬物都是由“道”產生的。萬事萬物都是深刻相連的事實，意味著“好與壞”、“錯與對”只是人內心的幻相，換個角度來思考都會變成相對的和短暫的真實。

萬事萬物每天都在不斷的變化，那么我們要如何認識事物的本質呢？

筆者認為，其實萬事萬物的本質是生命，生命的延續是時間，時間沒有了，生命也就結束了。企業建設中臺道理也是一樣的， 先通過連接的方式記錄著虛擬數字世界中的“精彩”，然后做數據在另一場景領域的能力延伸。

數據始終基于業務，如果業務死了，對于這個業務產生的數據來說，它的使命就暫時結束了，至于之后會用什么其他的方式延續“生命”，在數據的世界里真的無從知曉嗎？

企業建設中臺一定是一個持久而漫長的過程，絕非一蹴而就，能力和服務都需要不斷的業務滋養，才能逐漸走向成熟；這個過程一定是吃苦的過程，同時也請各家企業在建設中臺或者打算建設中臺的人，請一定不要短期高估，長期低估中臺的能力。

數據是企業真正能發揮價值的武器，能使用數據的場景有很多，希望大家一直對數據懷有敬畏之心，結合場景化需求去落地，將數據逐漸沉淀成企業的資產；其次更多的從數據的角度去發現問題、解決問題、改進問題。

畢竟，在大數據時代的我們，一切皆可量化。

【參考文獻】

[1] (美) 金博爾 (Kimball,R.) , (美) 羅斯 (Ross,M.) , 著《數據倉庫工具箱:維度建模權威指南(第3版)》[M].清華大學出版社,2015

[2] 阿里巴巴數據技術及產品部.《大數據之路：阿里巴巴大數據實踐》[M].電子工業出版社,2017

[3] 鐘華.《企業IT架構轉型之道：阿里巴巴中臺戰略思想與架構實戰》[M].機械工業出版社,2017

作者：Evans 公眾號：橙子解憂雜貨店

本文由 @Evans 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。