這是傅一平的第361篇原創

【提醒：公眾號推送規則變了，如果您想及時收到推送，麻煩右下角點個在看，或者把本號置頂】

正文開始

很多年前阿里出了《大數據之路》一書，在數據技術層面給出了有價值的指導，算是一本經典的書籍。最近華為出版了《華為數據之道》一書，給出了非數字原生企業在數據管理方面的實戰經驗，特別適合于面臨數字化轉型的企業管理者、數據從業者。

這兩本書的特點都是體系化程度比較好，如果說《大數據之路》是魚，那《華為數據之道》就是水，沒有良好的數據治理體系保駕護航，數據技術要產生實際價值也很難。

一、整體框架

《華為數據之道》共有10個章節的內容，其中最核心的內容包括四大部分：數據湖、數據主題連接、數據消費及數據治理，見下圖的整體框架。

個人認為，數據治理對應著第二章的綜合治理體系、第三章的數據分類、第四章的信息架構、第八章的數據質量及第九章的數據安全，數據湖和數據主題聯結對應著第五章，合起來叫做數據底座，數據消費對應著第六章。

從框架角度來講，傳統的大數據平臺體系框架（如下圖所示）與華為的數據體系框架跟沒有大的區別，只是每個模塊的稱呼有所不同，模塊的劃分稍有區別。

1、數據交換層+數據處理層對應著華為的數據湖。

2、數據開放層中的基礎模型、融合模型及洞察主題對應著華為的主題聯結。

3、數據開放服務對應著華為的數據服務。

4、數據處理層的分析引擎+應用層對應著華為的數據消費，把數據分析這種引擎下沉歸類到平臺端還是上浮歸類到消費端就仁者見仁智者見智了。

5、數據資產管理+資源管理對應著華為的數據治理，但華為的數據治理模塊不僅僅指治理平臺工具，還包括組織、機制和流程等等。

二、數據治理

《華為數據之道》提到，只有構筑一套企業級的數據綜合治理體系，才能確保關鍵數據資產有清晰的業務管理責任，IT建設有穩定的原則和依據，作業人員有規范的流程和指導。當面臨爭議時，有裁決機構和升級處理機制，治理過程所需的人才、組織、預算有充足的保障，最終建立有效的數據治理環境，數據的質量和安全得到保障，數據的價值才能真正發揮出來。

這段話很精辟，衡量一個企業數據治理水平的高低，最關鍵的一是有沒有公司級的數據治理政策，二是這個政策有沒有組織的保障，三是這個保障流程運行的質量如何，我不知道華為是否真的全做到了，但政策和組織保障這部分內容寫得比較詳細。

1、數據治理政策的頂層設計

數據治理政策是華為數據治理的頂層設計，該政策在華為公司EMT(經營管理團隊)匯報通過后，由總裁簽發，該政策明確了數據工作在華為公司治理體系的地位，體現了公司管理層對數據工作重要性的統一認知。

華為數據管理總綱明確了數據治理最基本的原則，包括信息架構、數據產生、數據應用及數據質量的職責和分工。在這個基礎上，華為針對信息架構、數據質量及數據源還給出了具體的管理政策。

比如信息架構管理原則第二條規定：所有變革項目須遵從數據管控要求，對于不遵從管控要求的變革項目，數據管控組織擁有一票否決權。

比如數據產生管理原則第三條規定：關鍵數據須定義單一數據源，一點錄入，多點調用，數據質量問題應在源頭解決。

比如信息架構管理政策第一條：各數據Owner負責其所轄數據的信息架構建設和維護，承接及落實公司的數據規劃要求。

有時候我們連公司級的數據政策針對的管理對象都描述不清楚，比如信息架構到底是什么，華為不僅明確了，還把原則政策化了，這一點難能可貴。

2、業務負責制的責任體系

華為公司的每一個數據，必須由對應的業務部門承擔管理責任，且必須有唯一的數據Owner。業務負責制的數據管理責任體系，是華為數據治理體系多年實踐經驗的結晶，是確保體系發揮作用的基石。

這個真的非常好，但知易行難。

數據誰生成，誰負責，本來天經地義，但現在IT背鍋不在少數，大多數企業的數據由于沒有明確Owner，因此一旦出現數據質量問題就會相互扯皮，這是數據質量問題始終無法解決的一個根源，有時候業務數據出現問題還要IT倒過來求著業務去規范錄入，完全是本末倒置。

華為按分層分級原則任命數據Owner，在公司層面設置公司數據Owner，在各業務領域設置領域數據Owner，這樣既能確保公司數據工作統籌規劃，也能同時兼顧各業務領域靈活多變的特征。

為落實公司制定的數據管理目標，在各業務領域要建立實體化的數據管理專業組織，實線向GPO(各業務領域的全球流程Owner，通常是業務領域的最高主管)匯報，承接并落實GPO的數據管理責任，虛線向公司管理部匯報，遵從公司統一的數據管理政策、流程和規則要求，見下圖所示。

筆者今年在文章《如何解決企業各個部門間的“數據孤島”問題？》中也提到了業務部門組織保障的重要性，見下圖，兩者有異曲同工之妙。

最后，圍繞組織、機制和流程，要制定全生命周期的治理規范和方案，華為給了一張全景圖，大家可以參考。

3、信息架構是數據治理的關鍵對象

企業在運作過程中，首先需要管理好人和物等“資源”，然后管理好各類資源之間的聯系，即各類業務交易“事件”，再對各類事件的執行效果進行“整體描述和評估”，最終實現組織目標和價值。但如果運作過程中各類數據在企業各業務單元間無法高效、準確、一致的傳遞，就會影響企業運作的效率，比如主數據不一致就會問題頻發。

而要解決這個問題，就要對企業的信息架構進行治理，即構建一套對業務運作數據進行有效管理的信息架構方法論，用于指導企業內部個部門的信息架構建設工作，讓管理者、專家和員工之間有共同語言。

上面這段話說明了信息架構治理的業務價值。

（1）信息架構的組成

信息架構主要包括數據資產目錄、數據標準、企業級數據模型和數據分布四個組件，如下圖所示：

數據資產目錄決定了數據治理的邊界和對象，通過數據資產的分門別類不僅能讓數據模型歸位，幫助企業更好的對業務變革進行規劃設計、避免重復建設，也能讓數據資產找得到、看得清，為數據資產有效使用奠定基礎。

數據標準定義公司層面需要共同遵守的屬性層數據含義和業務規則，是公司層面對某個數據的共同理解，這些理解一旦確定下來，就應作為企業層面的標準在企業內被共同遵守。

例如合同是公司最重要的數據之一，有必要對合同編號制訂統一的數據標準，包括編號的位數，一旦合同編號數據標準制定下來，那么整個公司所有業務部門都必須共同遵守，除了數據Owner以外，任何部門都不允許自定義合同編號，否則一旦不同業務環節各自定義，那么數據就無法在上下游業務之間快速流轉，往往需要額外的人工轉換和翻譯，這極大增加人工成本，延長業務執行周期。

數據模型是從數據視角對現實世界特征的模擬和抽象，根據業務需求抽取信息的主要特征，反應業務信息（對象）之間的關聯關系。數據模型不僅能比較真實地模擬業務（場景），同時也是對重要業務模型和規則的固化。

數據分布定義了數據產生的源頭及在各流程和IT系統間的流動情況，數據分布的核心是數據源，指業務上首次正式發布某項數據的應用系統，并經過數據管理專業組織認證，作為企業范圍內唯一數據源頭被周邊系統調用，為了更好地識別、管理數據在流程和IT系統間的流動，可以通過信息鏈、數據流來進行描述，體現某一數據在流程或應用系統中是如何被創建、讀取、更新、刪除的。

（2）信息架構治理原則

華為首先確定了“數據同源一致”的治理目標，圍繞目標的實現，制定了五條架構原則。

原則一：數據按對象管理，明確數據Owner

數據要發揮作用，必然會在多個IT系統和流程中流轉，并且越是重要的數據資產，所流經的業務環節就越多，比如產品、人員、客戶的數據幾乎在所有流程中都會涉及，因此不應以IT系統、業務流程邊界來管理數據，而應該從數據本身出發，按對象進行數據全生命周期管理。

原則二：從企業視角定義信息架構

任何一個數據Owner都不只代表自己所轄業務范圍的數據管理訴求，而是代表公司對數據進行管理，比如任何業務部門對合同編號的訴求，都可以提交數據Owner解決。

原則三：遵從公司的數據分類管理框架

原則四：業務對象結構化、數字化

原則五：數據服務化，同源共享

（3）信息架構建設核心要素

按業務對象進行架構設計：業務對象是指業務領域中重要的人、事、物對象。業務對象承載了業務運作和管理涉及的重要信息，是信息架構中最重要的管理要素，在進行信息架構設計時，架構師、業務代表、數據Owner通常會對業務對象的判定存在理解偏差，數據治理部門需要制定一套確定性規則，通過確定性規則促進形成穩定的架構，主要包括四個原則，分別是不可或缺、唯一身份標識、相對獨立及可實例化。

按業務對象進行架構落地：信息架構向IT側落地的主要交付件是數據模型，華為公司過去長期存在信息架構與IT開發實施“兩張皮”的現象，數據人員和IT開發實施人員缺乏協同，數據架構遵從無法進行實質、有效管理，信息架構資產和產品實現的物理表割裂、不匹配、同時各種數據模型資產缺失。

為了解決這個問題，華為推行了一體化模型設計，不僅在工具上實現了一體化設計和開發，而且確保了元數據驗證、發布和注冊的一致性，使得產品數據模型管理和資產可視，比如構建數據標準池、實體屬性只能從標準池選擇、產品元數據和數據庫自動比對驗證、產品元數據發布認證和信息資產打通、基于交易側產品元數據自助如何等等，具體見下圖：

筆者在《業務系統的數據資產管理為什么這么難？》一文中對于“兩張皮”問題有過詳細的論述，大家有時間可以看下。

4、不同數據類別宜采用不同的治理手段

華為對數據進行分類的目的，是為了針對不同特性的數據采取不同的治理方法，以期實現最大的投入產出比。

華為根據數據特性及治理方法的不同對數據進行了分類定義：內部數據和外部數據、結構化數據和非結構化數據、元數據。其中，結構化數據又進一步劃分為基礎數據（也叫參考數據，維度數據）、主數據、事務數據、報告數據、觀測數據和規則數據，數據分類框架如圖所示：

這里以基礎數據為例介紹華為的治理方法。

基礎數據用于對其他數據進行分類，也叫參考數據。當基礎數據的取值發生變化的時候，通常需要對流程和IT系統進行分析和修改，以滿足業務需求。因此，基礎數據的管理重點在于變更管理和統一標準管控。

華為建立了一個完整的基礎數據管理框架，通過明確各方的管理責任，發布相關的流程和規范以及建立基礎數據管理平臺等來確保基礎數據的有效管理，如下圖所示：

《華為數據之道》數據治理相關章節給了我很大啟發，強烈建議大家閱讀。

三、數據湖

1、華為數據湖的3個特點

華為數據湖是邏輯上對內外部的結構化、非結構化的原始數據的邏輯匯聚，有三個特點：

（1）邏輯統一

華為數據湖不是單一的物理存儲，而是根據數據類型、業務區域等由多個不同的物理存儲構成，并通過統一的元數據語義層進行定義、拉通和管理。

（2）類型多樣

數據湖存放所有不同類型的數據，包括企業內部IT系統產生的結構化數據、業務交易和內部管理的非結構的文本數據、公司內部園區各種傳感器檢測到的設備運行數據，以及外部的媒體數據等。

（3）原始記錄

華為數據湖是對原始數據的匯聚，不對數據做任何的轉換、清晰、加工等處理，保留數據最原始特征，為數據的加工和消費提供豐富的可能。

2、數據入湖的6個標準

數據入湖是數據消費的基礎，需要嚴格滿足入湖的6項標準，包括明確數據Owner、發布數據標準、定義數據密級、明確數據源、數據質量評估、元數據注冊。通過這6項標準保證入湖的數據都有明確的業務負責人，各項數據都可理解，同時都能在相應的信息安全保障下進行消費。

3、數據入湖方式

數據入湖有5種技術手段，包括批量集成、數據復制同步、消息集成、流集成、數據虛擬化，5種數據入湖方式比對參考如下：

下圖示例了結構化數據入湖的流程：

不過筆者認為，華為定義的數據湖和傳統的數據倉庫沒有本質區別，雖然數據存儲的多樣化和原始化是數據湖的一個特征，但還不足以構成一個數據湖，筆者在《數據湖與數據倉庫的根本區別，在于前者是“市場經濟”，而后者是“計劃經濟”》對數據湖談過自己的理解，大家有興趣可以看一下。

四、數據主題聯結

華為在數據湖的基礎上通過建立數據聯結層，基于不同的分析場景，通過5類聯結方式將跨域的數據聯結起來，將數據由“原材料”加工成“半成品”和“成品”，支撐不同場景的數據消費需求，數據聯結其實就是數據倉庫建模，當然華為對于聯結的定義更為廣泛，包括多維模型、圖模型、標簽、指標和算法模型，如下圖所示。

多維模型是面向業務的多視角、多維度的分析，通過明確的業務關系，建立基于事實表、維度表以及相互間聯接關系，實現多維數據查詢和分析。例如對訂貨數據從時間、區域、產品等維度進行多視角、不同粒度的查詢和分析。

圖模型面向數據間的關聯影響分析，通過建立數據對象以及數據實例之間的關系，幫助業務快速定位關聯影響。例如查看某國家原產地的項目的數據具體關聯到哪個客戶以及合同、訂單、產品的詳細信息時，可以通過圖模型快速分析關聯影響，支撐業務決策。

標簽是對特定業務范圍的圈定。在業務場景的上下文背景中，運用抽象、歸納、推理等算法計算并生成目標對象特征的表示符號，是用戶主觀觀察、認識和描述對象的一個角度。例如對用戶進行畫像，識別不同的用戶群，為產品設計和營銷提供策略支持。

指標是對業務結果、效率和質量的度量。依據明確的業務規則，通過數據計算得到衡量目標總體特征的統計數值，能客觀表征企業某一業務活動中業務狀況。例如促銷員覆蓋率指標就是衡量一線銷售門店促銷員的覆蓋程度。

算法模型是面向智能分析的場景，通過數據建模對現實世界進行抽象、模擬和仿真，提供支撐業務判斷和決策的高級分析方法。例如預測未來18個月的銷售量。

五、數據消費

在數據供應側和消費側的雙重推動下，華為公司進行了基于數據服務提供“自助消費”的實踐，打造了從數據供應到消費的完整鏈條。

1、數據服務：實現數據自助、高效、復用

過去數據獲取大部分依賴于傳統集成方式，即將數據從一個系統復制到另一個系統。隨著企業規模的擴大，需要在幾十個甚至上百個IT系統中進行數據集成，這樣一來，隨著系統集成的復雜度提升，會帶來一系列數據質量問題，比如數據經過多次不同系統間搬家后，源頭數據和下游各系統之間的數據差異巨大，在這樣的背景下，華為進行了大規模的數據服務建設，通過數據服務替代原有數據集成方式，取得了數據獲取效率和數據安全之間的平衡，下圖示例了數據服務和傳統集成方法的對比：

數據服務給企業帶來五個價值：（1）保障“數出一孔”，提升數據一致性 （2）數據消費者不用關注技術細節 （3）提升數據敏捷響應能力 （4）滿足用戶靈活多樣的消費訴求 （5）兼顧數據安全，具體見下圖：

華為公司為確保整個數據供應鏈條的高效協同，制訂了“三個1”作為拉通各個供應環節的整體目標，確保每個環節能夠形成合力并對準最終用戶，如下圖所示：

1天：對已發布數據服務的場景，從需求提出到消費者通過服務獲取數據，在一天內完成。

1周：對于已進底座但無數據服務的場景，從需求提出到數據服務設計落地、消費者通過服務獲取數據，在一周內完成。

1月：對于已結構化但未進底座的場景，從需求提出到匯聚入湖、數據主題聯接、數據服務設計落地、消費者通過服務獲取數據，在1個月內完成。

數據供應“三個1”并不是單純的度量指標，而是一整套瞄準最終數據消費體驗的能力體系以及確保數據供應能力的管理機制，還包括組織職責的明確、流程規范的制定與落實、IT平臺的建設和管理，如下圖所示：

2、構建以用戶體驗為核心的數據地圖

在解決數據的“可供應性”之后，企業應該幫助業務更便捷、更準確地找到它們所需要的數據，這就需要打造一個能夠滿足用戶體驗的“數據地圖”。

數據地圖（DMAP）是華為面向數據的最終消費用戶針對數據“找得到” “讀得懂”的需求而設計的，基于元數據應用，以數據搜索為核心，通過可視化方式，綜合反映有關數據的來源、數量、質量、分布、標準、流向、關聯關系，讓用戶高效率找到數據，讀懂數據，支撐數據消費。

數據地圖作為數據治理成果的集散地，需要提供多種數據，滿足多類用戶、多樣場景的數據消費需求，所以華為公司結合實際業務制定了如下圖的數據地圖框架。

3、人人都是分析師

數據服務解決了“可供應性”，數據地圖解決了“可搜索/可獲取性”，當消費方獲取數據后，提供“可分析”能力，幫助數據消費者結合自身需要獲取想要的分析結果。過去各業務部門的分析訴求往往通過“保姆式”開發模式來滿足，從獲取數據、建模到設計報告，均需要IT人員的支撐，在這種背景下，提出了“服務+自助”模式，即IT只提供統一的數據服務和分析能力組件服務，各業務部門可以根據業務需要進行靈活的數據分析消費，數據分析的方案和結果由業務自己完成。

華為公司將自助分析作為一種公共能力，在企業層面進行了統一構建，一方面面向不同的消費用戶提供差異化的能力和工具支撐；另一方面引入了“租戶”概念，不同類型的用戶可以在一定范圍內分析數據，共享數據結果。

（1）針對三類角色提供的差異化服務

面向業務分析師，提供自助分析能力，業務人員通過“拖、拉、拽”即可快速產生分析報告。

面向數據科學家，提供高效的數據接入能力和常用的數據分析組件，快速搭建數據探索和分析環境。

面向IT開發人員，提供云端數據開發、計算、分析、應用套件，支撐海量數據的分析與可視化，實現組件重用。

（2）以租戶為核心的自助分析關鍵能力

租戶是指把數據、分析工具、計算資源有機組合的工作環境，用戶可以在租戶內自助完成數據搜索、數據加工、在線分析、報表共享等工作。

為了合理分配軟硬件資源，滿足各領域在線、自助、個性化的數據分析訴求，明確了租戶申請、租戶命名、數據準備、數據同步、數據加工、數據申請、權限管理、安全與隱私、運維與運營等方面的要求，旨在通過正確的引導，確保數據消費的便捷、高效與安全合規。

租戶自助分析能力架構如下圖所示：

以上就是《華為數據之道》一書最核心的內容概覽，建議大家選擇這些核心章節重點閱讀，其它的章節還包括數據感知、數據質量及數據安全等，有時間也可以了解下。

這本書是DAMA等數據管理指南書的一個實例，筆者發現其中的很多理念在華為獲得了實踐，很多模糊不清的概念得到了澄清，這對于我的幫助很大。當然由于覆蓋的內容太多，很多地方沒有講透，但已經足夠好了。

數據治理：90%的人搞不清的事情

如何解決企業各個部門間的“數據孤島”問題？

元數據的生死時速

企業數據治理的十個最佳實踐

美團配送數據治理實踐

如何實施有效的報表治理？

右下角分享、點贊、在看，三連、三連！

總結

以上是生活随笔為你收集整理的读透《华为数据之道》的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。