一、數據架構與數據模型概述

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 的創建。

二、數據架構與模型解決方案

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、模型設計和開發平臺一體化

構建模型設計和開發平臺一體化管理流程，實現模型設計人員從模型設計到數據架構師審批模型，再到模型腳本入業務系統庫，并生成代碼嵌入數據標準給到開發平臺。

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

 

 

三、大型企業實踐案例

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 套業務系統，全部通過上述組織架構協作實現模型管控。

四、問答環節

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

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

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

Q2：主數據在數據模型中如何體現？

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

Q3：數據質量和數據標準該如何解決？

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