資料治理與資料中臺架構

分享嘉賓｜王琤 Datablau 創始人&CEO

編輯整理｜王吉東 崑崙資料

出品社群｜DataFun

01

資料架構與資料模型概述

1. DAMA DMBOK 資料架構與資料治理

資料架構及資料模型管理是資料治理體系的重要組成部分。類似於專案管理中的 PMI、PMP，國際上於 1980 年成立了 DAMA（資料資產管理協會）。DAMA 凝集了數百位專家的經驗，最終形成業界通用的資料管理框架（DMBOK）。DAMA-DMBOK 資料管理框架（又稱為 DAMA 車輪圖)，主要由 11 個知識領域構建而成，其中資料架構和資料模型是這套方法論最重要的兩個維度。

資料架構主要用來識別企業的資料需求，並設計藍圖，最終輸出資料架構設計和實施路線圖，詳見下圖所示。

2. 建設資料模型的流程

資料模型的建立，業界通用的方法論如下所述：

① 前期的設計主要聚焦於業務，基於客戶需求，完成概念模型和邏輯模型的設計；

② 進一步，基於企業現有的技術環境和效能要求，將概念模型和邏輯模型轉化成可落地的物理模型；

③ 再進一步，將物理模型結合實際資料轉化成資料庫表結構（以及建立表結構對應的 DDL 指令碼），最終形成資料庫表欄位；

④ 對於模型的設計和落地過程中的重要節點，往往會形成一套相應的企業標準，實現規範化。

不管源端系統有沒有進行模型設計，資料 schema 都存在，都可以透過逆向工程抽取出來提煉成模型，這些模型更多地描述業務系統涵蓋的資料範圍，以及資料之間的關係；如果模型質量高，可以更好地幫助企業理解資料資產的價值。因此可以認為，所有的系統都有資料模型，只是有些模型更容易理解，也更容易對企業產生價值。

3. 所有模型都是為了業務開展，不同視角，不同階段

對於如今流行的大資料概念，人們普遍將關注點聚焦在分析側（即 AP 側）。實際上，大資料模型不僅僅包含 AP 側，TP 側（即企業的源端業務系統）在資訊化或數字化過程中同樣會構建出各種各樣的資料產品（或系統），最終應用於企業內部或外部客戶。

對於資料庫底層設計，現階段大部分企業仍然使用傳統的資料庫構建正規化： 

① 在 TP 側，通常使用三正規化模型這類 Inmon 模型；

② 在 AP 側的資料集市，通常使用維度模型（如雪花模型、星型模型）這類 Kimball 模型；

此外，近期迭代出更多更加新型的資料模型正規化，如 Data Vault 模型、統一星型模型等，覆蓋範圍更加廣泛，可更加廣泛地應用於 TP 側和 AP 側。

4. 資料模型按階段分類

① 業務系統模型，通常選擇三正規化模型；

② ODS 模型通常從業務系統直接接入，因此也選擇三正規化模型；

③ DWD 模型和 DWS 模型作為企業級數倉，既可採用傳統的三正規化模型，也可使用現代的 Data Vault 模型來構建，都支援多對多的關係；

④ 集市模型一般使用維度模型，便於實現資料的上卷和下鑽等分析操作。

5. 資料模型介紹

資料的關係卻錯綜複雜，成千上萬個表透過各種關係或約束互聯形成複雜的結構。以生活中常見的場景為例，如房屋平面圖、地圖等，用不同的符號向相關使用者清晰展示相關資訊。

透過資料模型，使用者可以清晰看到現有資料庫的結構，並更直觀地理解關鍵的概念。資料模型主要包括概念模型、邏輯模型和物理模型這三個層次。

① 概念模型：主要用來描述世界的概念化結構，是一個高層次的資料模型，由核心的資料實體或其集合，以及實體間的關係組成；

② 邏輯模型：對概念資料模型進一步的分解和細化，描述實體、屬性以及實體關係；

③ 物理模型：面向特定的資料庫，結合資料庫特徵，便於計算機實現的模型。

開發者在進行模型設計的過程中，通常會將大部分時間和精力聚焦在概念模型和邏輯模型的設計和迭代最佳化；物理模型則類似於對概念模型和邏輯模型的“編譯”操作，透過生成並執行 DDL 指令碼最終實現資料庫以及相應 schema 的建立。

02

資料架構與模型解決方案

1. 解決方案 1——模型設計和開發平臺一體化

透過 ER 圖視覺化，可實現邏輯模型或物理模型的設計。以下圖為例，資料包括 hub、link、Satellite 三個核心概念；使用 Data Vault 模型，可實現更加靈活的數倉自動化操作，以更便捷的方式實現模型的解耦，來構建複雜的、具有業務深度的行業模型。

完成模型的設計後，生成相應的 DDL 指令碼，透過 Create 功能或 Alter 功能，最終實現模型的管理和迭代。

2. 解決方案 2——資料標準管控，資料規範檢查

（1）資料標準管控

在模型設計階段，所涉及的模型欄位要實現標準化；透過指定或引用相關的企業級資料標準，利用智慧推薦，更加方便地實現資料表欄位的選取。

資料建模工具一般具有資料標準的功能，在模型設計期間，研發人員可以透過拖拉的方式直接引用資料標準，也可以在實體設計器中，使用智慧推薦的資料標準，最佳化資料應用模式，提升模型設計效率。

如下圖所示，以電力系統模型為例，在表結構設計過程中，透過關鍵詞（如變壓器）可以直接關聯到相應的資料標準，進而查詢到標準的欄位名稱、物理型別、長度精度、業務定義等資訊，進而將標準引入到實體屬性中，同時實現了欄位名稱、資料型別、資料精度的規範，進而實現了源端業務系統資料模型質量的把控。

（2）命名詞典構建

如果相關的企業或部門沒有制定嚴格的企業資料標準，企業可以基於業務術語構建統一術語詞典庫（即命名詞典）；藉助這一詞典庫，解決研發人員建模時常見的“同一指標多種命名”這類易發生歧義的問題；開發人員在模型構建的過程中，對於模型實體及屬性命名，自動基於詞典庫進行翻譯，實現資料模型的命名規範，使物理模型的設計質量更高。

（3）中央模型庫

多人協作整合模型，會涉及複雜的版本迭代、版本對比等版本管理問題。因此，可建立類似 git 的中央模型庫，基於資料模型伺服器實現資料模型設計規範、資料標準及模型設計成果的線上化管理；提供模型設計工具，實現模型設計規範、資料標準以及模型線上應用，為資料標準落地提供手段；支撐設計態及執行態模型匹配監測，實現資料模型從規範化設計到應用全過程線上管理。 

（4）資料規範工具

將開發規則內建到建模過程中，開發對應的資料規範工具和資料標準一致性檢查工具，以解決研發人員設計不規範、缺少資料標準約束等業務痛點，最大程度地降低資料治理的成本：

① 資料規範工具可以檢測以下內容：表和欄位中文名稱不能為空；表和欄位物理名稱不能為空等多項內容。 

② 資料標準一致性檢查工具可以檢測：資料型別、中文名、英文簡稱是否和標準一致性等多項內容。

3. 解決方案 3——模型變更自動化、智慧化

基於資料模型伺服器構建資料模型庫，資料庫承載資料標準、命名詞典、規範報告等資訊；迭代最佳化的模型透過統一的發版系統（如 jira、confluence 等）進行統一發版，實現資料模型的儲存管理和版本變更管理，並提供模型線上檢視編輯和多人協作等功能。

其核心功能點在於：

① 統一模型儲存，Web 模型共享和查詢；

②實現模型版本管理，模型變更全歷史記錄；

③ 自動進行模型合規檢查，標準落標報告；

④ 多人協作，同時編輯和修改模型；

⑤ 自動生成建庫指令碼，資料字典管理。

採用類似 git 的程式碼管理方式，模型設計工具從模型，分支，版本三個層面對模型進行管理，最終有效解決研發人員的模型版本管理，實現協同共享。

4. 解決方案 4——資料模型和業務場景業務物件對應

大型企業除了資料模型設計，還需要對大量的業務場景做整合。業務架構包括業務流程、業務活動等，涉及大量的業務表單和對應的業務物件。在資料模型的資料實體頁面，將每一個實體和業務場景中的每一個業務物件進行繫結，進而透過 Datablau 自研的模型管控體系實現血緣關係的跟蹤和分析。

5. Datablau 模型管控體系簡介

Datablau 模型管控體系包括事前、事中和事後這 3 個部分：

① 事前：透過統一的建模工具，進行模型設計；

② 事中：增加模型評審環節，由領域架構師、企業架構師負責模型的評審，透過資產平臺進行完整性檢查；

③ 事後：部署生產環境後，透過資料資產平臺檢查並監控模型的一致性、完整性並出具相關報告。

6. Datablau 模型管控體系與資料開發

將 Datablau DDM 工具納入開發投產流程後，各業務模組需要進行相應的模型遷移，並使用平臺提供的典型能力進行模型設計、開發測試和投產。

（1）模型匯入

① 模型匯入：透過匯入工具，將 PD、ERWin 等工具的模型匯入 DDM 中。

② 逆向工程：透過直聯資料庫的方式，逆向生成模型。

③ 資訊補全：補充模型中缺失的欄位資訊，例如欄位中文名稱。

（2）設計階段

① 模型設計：使用客戶端設計器進行模組設計與維護。

② 影響分析：設計階段能夠顯示模型的修改對下游系統的影響。

③ 欄位引標：設計工具中能夠引用資料標準。

（3）評審階段

① 任務管理：提交模型時需要與任務進行關聯。

② 分支管理：按照推薦的最佳實踐進行分支管理，分支間按照任務進行內容合併。

③ 模型評審：模型的變更必須經過線上評審。

（4）投產階段

① DDL 校驗：將投產 DDL 與模型工具匯出 DDL 比對。對於不匹配的部分，近期可以人工確認，遠期改為系統認定。

7. Datablau 模型分支管理策略

版本分支管理包括設計態和執行態這兩部分。資料模型按照開發與測試環境進行對應的版本管理，並基於每個分支的開發、SIT、UAT、版本等不同釋出狀態進行相應的管理，最終形成統一的分支管理策略。

8. 模型設計和開發平臺一體化

構建模型設計和開發平臺一體化管理流程，實現模型設計人員從模型設計到資料架構師審批模型，再到模型指令碼入業務系統庫，並生成程式碼嵌入資料標準給到開發平臺。

這套資料建模管理流程，可有效地將資料模型轉化為企業資料資產。相比於直接抽取技術後設資料，資料資產化模型一方面大大提升了資料的質量，另一方面增加了資料間的關係，以及各類資料背後的業務定義，使得資料資訊更加全面和系統。

03

1. 企業資料架構——製造業概念模型

以製造業為例，下圖呈現了製造業高階概念模型，涉及管理類、運營類、支援類等業務板塊。

2. 建立企業資料架構-開發路線圖——主題域模型

將上述業務板塊轉化為高階的主題域模型。以汽車廠為例，首先是進行產品研發，輸出產品部品即 BOM 清單；基於 BOM 清單進行裝配、生產，並關聯銷售清單；同時 BOM 也會關聯銷售專案管理，最終和客戶管理、訂單管理、銷售管理、財務管理等一系列資料進行多重關聯，構建出高階主題域模型。

3. 業務現狀

（1）業務現狀梳理：成果（1）L1-L3 高階流程架構

將上述主題域模型進一步細化，以採購部為例，基於採購部組織職能定位，與業務訪談輸入，全面梳理採購域所包含高階業務架構。

① L1 Category 域：企業業務的最高階別，可基於業務能力或端到端場景定義。 

② L2 Process Group 流程組：企業一級域的下級能力或流程集合。

③ L3 Process 流程：一系列將輸入轉化為輸出的相互關聯的活動。流程消耗資源並且需要制定可重複執行的標準；流程需要遵從一個面向質量、速度、成本績效要求的控制體系。 

（2）業務現狀梳理：成果（2）L1-L3 業務側資料目錄

基於採購部門職能，梳理採購域不同資訊域下所包含標準化業務資訊/表單，將其轉化為業務側的資料資產目錄，支援資料認責工作。

（3）業務現狀梳理：成果（3）L1-L3 業務全景圖

基於採購業務價值鏈，繪製業務資訊流圖：以端到端視角審視採購業務全貌，識別業務資訊來龍去脈。

4. 資料資產

（1）資料資產梳理：成果 – 資料目錄（L1-L5 資產清單）

以上圖所示資料資產目錄為例，分成主題域組、主題域、業務物件、資料實體、屬性 5級；每增加一個層級，可理解成新增一個的葉子節點。

5. 資料標準

（1）資料標準制定：成果 – 資料標準（L5 屬性標準）

對於資料目錄中 L5 層屬性的標準化定義，透過補全資料的業務屬性（名稱、業務規則等）、技術屬性（資料型別、長度等）以及管理屬性（資料維護責任人、資料管家等），最終形成資料標準。

6. 資料模型

基於資料標準構建資料模型。上圖為採購域的資料模型，模型中的每個欄位都與資料標準形成了對映關係。

（1）資料模型設計：ONE ID 邏輯設計

基於上述資料模型，結合實際業務構建資料應用。以採購域為例，對每個供應商進行全方位畫像，包括財務資訊、經營狀態、業務資訊等維度，構成一套供應鏈金融的服務模式。

（2）資料模型是資料中臺的核心位置

資料模型是資料中臺的核心資料資產，關係到基礎資料整合，開發效率，和資料質量。資料中臺主要包括 ODS 層、DWS/DWD 層，以及資料集市層等，這些中間層模型設計的規範性和靈活性，決定了資料資產的管理和應用效率。因此，如何整合好資料模型是資料中臺成功的標誌。

（3）全面管理和升級模型資料資產

傳統的資料模型構建，往往是開發人員基於業務邏輯透過 SQL 指令碼實現相應功能，並轉化成儲存過程，進而透過任務排程實現資料的轉化。這種方式靈活、便於實現，然而會給後續的資料資產梳理、資料質量排查以及資料修復等相關工作帶來麻煩。

因此，以資料模型為核心，透過對資料中臺模型的管理，實現從孤井式的程式碼開發，到模型驅動的程式碼開發階段的轉變。實現了模型驅動的資料模型資產化，開發過程可審查，程式碼質量可靠性等轉變，使中臺成為企業資料資產的沉澱和釋出中心，進而形成行業模型的影響力。 

（4）一體化建模架構

從資料戰略角度看，將業務流程、業務架構、資料責任、資料安全和入戶標準等相關模組都承載到業務模型上；進一步，業務模型透過資料模型落地實現，結合相應的企業標準進行模型評審，評審透過的資料模型釋出成資料資產目錄，並最終進入資料湖。

由於資料模型存在迭代更新的週期性，因此在模型設計的過程中，資料標準的維護至關重要。所有的模型都是由資料標準組裝而來；模型評審和模型釋出作為重要的中間管控節點，最終實現自助入湖，並週期性地和生產後設資料做比對。

（5）企業級資訊架構的四個元件

企業級資訊架構，本質上是基於一套核心的資訊架構，展現成資料資產目錄、資料標準、資料模型、資料分佈 4 種不同的形式：

① 資料資產目錄

1）透過分層架構表達；

2）對資料的分類和定義；

3）釐清資料資產；

4）建立資料模型的輸入 。

② 資料標準

1）業務定義的規範；

2）統一語言，消除歧義；

3）為資料資產梳理提供標準的業務含義和規則。

③ 資料模型

1）透過 E-R 建模實現對資料及其關係的描述；

2）指導 IT 開發，是應用系統實現的基礎。

④ 資料分佈

1）資料在業務流程和 IT 系統上流動的全景檢視；

2）識別資料的“來龍去脈” ；

3）定位資料問題的導航。

這套核心的資訊架構本質上是從 4 個角度詮釋企業的資料資產資訊：

資料模型作為最初的設計原型，經過評審釋出後形成資料資產目錄最終開放到業務部門；模型內部最細顆粒度的規範形成資料標準；資料分佈則體現的是某個具體的表或欄位在整個業務流程體系中所處的位置，定位到對應的具體業務物件並直觀地體現該業務物件的上下游關係。

（6）六項入湖標準

資料入湖的評審標準，大概包括以下這 6 個方面：

① 明確資料 Owner 

由資料產生對應的流程 Owner 擔任，是所轄資料端到端管理的責任人，負責對入湖的資料定義資料標準和密級，承接資料消費中的資料質量問題，並制定資料管理工作路標，持續提升資料質量 

② 釋出資料標準

入湖資料要有相應的業務資料標準。業務資料標準描述公司層面需共同遵守的“屬性層”資料的含義和業務規則，是公司層面對某個資料的共同理解，這些理解一旦明確併發布，就需要作為標準在企業內被共同遵守。

③ 認證資料來源 

透過認證資料來源，能夠確保資料從正確的資料來源頭入湖。認證資料來源應遵循公司資料來源管理的要求，一般資料來源是指業務上首次正式釋出某項資料的應用系統，並經過資料管理專業組織認證。認證過的資料來源作為唯一資料來源頭被資料湖呼叫。當承載資料來源的應用系統出現合併、分拆、下線情況時，應及時對資料來源進行失效處理，並啟動新資料來源認證流程。

④ 定義資料密級

定義資料密級是資料入湖的必要條件，為了確保資料湖中的資料能充分地共享，同時又不發生資訊保安問題，入湖的資料必須要定密。資料定密的責任主體是資料 Owner，資料管家有責任審視入湖資料密級的完整性，並推動、協調資料定密工作。資料定級密度在屬性層級，根據資產的重要程度，定義不同等級。不同密級的資料有相應的資料消費要求，為了促進公司資料的消費，資料湖中的資料有相應的降密機制，到降密期或滿足降密條件的資料應及時降密，並重新整理密級資訊。

⑤ 制定資料質量方案 

資料質量是資料消費結果的保證，資料入湖不需要對資料進行清洗，但需要對資料質量進行評估，讓資料的消費人員瞭解資料的質量情況，並瞭解消費該資料的質量風險。同時資料 Owner 和資料管家可以根據資料質量評估的情況，推動源頭資料質量的提升，滿足資料質量的消費要求。

⑥ 註冊後設資料

後設資料註冊是指將入湖資料的業務後設資料和技術後設資料進行關聯，包括邏輯實體與物理表的對應關係，以及業務屬性和表欄位的對應關係。透過連線業務後設資料和技術後設資料的關係，能夠支撐資料消費人員透過業務語義快速地搜尋到資料湖中的資料，降低資料湖中資料消費的門檻，能讓更多的業務分析人員理解和消費資料。

（7）資料模型管控組織

從公司部門的組織架構角度考慮，資料模型管控的推進，需要配備相應的組織架構予以監督和支援。一方面，基於 DAMA 方法論，企業構建不同的資料治理體系維度，如資料標準、資料質量、資料模型、資料資產目錄等相關內容；另一方面，基於傳統的 IT 相關部門下屬的各個專案小組，建議安排部分開發人員以 part-time 的方式承擔部分資料治理角色，使得資料治理架構更加立體。此外，可以專門成立企業架構辦（一般包括資料架構、應用架構、技術架構、業務架構這 4 層架構），與專案組聯合，實現更全面、更深入的資料模型管理服務。

因此，建立虛實結合的資料組織設定，是確保數工作能充分融入業務，同時能夠在應用系統中有效落地的關鍵。

以交通銀行為例，企業共計超過 500 套業務系統，全部透過上述組織架構協作實現模型管控。

04

Q1：按照全套組合架構實現企業級資料治理，往往會帶來較高的時間成本；因此，如何平衡資料治理和開發效率？

A1：① 資料治理架構的開展，需要一定的契機；可以以企業新構建的系統作為試點；尤其是金融系統，往往 5 年左右進行一次更新換代。因此，可以選擇合適的系統更新換代節點，推進資料治理架構。

② 如果企業的資料資產需求較為強烈和迫切，那麼源端管控就是必要的工作。在此基礎上，可以先針對部分部門或專案組，透過小範圍試點方式進行推進，後期再逐步進行大範圍推廣。此外，可藉助一些更高效的工具以提高開發效率。

Q2：主資料在資料模型中如何體現？

A2：這類問題在業內曾引起廣泛的討論。對於金融行業，客戶管理系統即是客戶的主資料；對於業務鏈條較長的企業，例如製造業企業，常用的方式是針對主資料進行模型建模。而對於主資料建模，較為傳統的方式是開發相應的 MDM（主資料關係系統），典型的企業實踐案例是中石油系統；然而 MDM 系統較為龐大，因此近年來主資料建模的趨勢是更加輕量化，通常是在各個系統（如組織機構、客戶、物料、產品等系統）對應的資料庫中預留少量區域來儲存對應的主資料模型，實現該系統主資料模型與各個系統的對接。總之，核心在於主資料模型的構建，輕量化是趨勢。

A3：如果企業的模型設計已經落標，質量管理這部分工作相對會容易很多；由於每個物理欄位對應的標準已經確定，因此基礎的資料質量檢測規則往往可以自動生成，而複雜的資料質量檢測規則和資料標準中的認責板塊掛鉤，相應部門提供各自的資料質量檢測相關的業務規則，最後再由業務規則轉成技術規則，嵌入到系統中進行週期性執行。