資料治理一體化實踐之體系化建模

數字經濟的快速發展，給企業的經營帶來了新的機遇和挑戰，如何有效開展資料治理，打破資料孤島，充分發揮資料的業務價值，保護資料安全，已成為業界的熱門話題。本文基於美團配送資料治理的歷程，分享了資料定義、模型設計、資料生產三環節統一的配送資料“底座”的建設與實踐。

1 前言

2 什麼是體系化建模

3 為什麼要進行體系化建模

3.1 體系化建模可以對資料架構進行實質有效的管理，從源頭消除“煙囪式”開發

3.2 體系化建模沉澱的規範後設資料，可以有效消除業務在檢索和理解資料時的困擾

4 如何進行體系化建模

4.1 高層模型設計

4.2 詳細模型設計

4.3 上線前卡點

5 總結

1 前言

本文基於美團配送資料治理的歷程，重點和大家分享一下配送資料“底座”的建設與實踐，如何透過體系化建模建立起資料定義到資料生產的橋樑，達成資料定義、模型設計、資料生產三個環節的統一，消除因資料標準缺失和執行不到位引發的資料信任問題，在高質量地實現資料到資訊的轉化的同時，為後續的資料便捷消費提供資料和後設資料保障。希望能給從事資料治理方向的同學在實現資料到資產的轉化過程提供一些參考和借鑑。

2 什麼是體系化建模

體系化建模是以維度建模為理論基礎，以事前治理的理念驅動，讓後設資料貫穿其中的建模流程，上承指標、維度的定義，下接實際的資料生產。首先，透過高層模型設計，將業務指標結構化拆解為原子指標/計算指標+限定條件的組合方式，並將其歸屬到特定的業務過程和主題下，完成業務指標的計劃化定義;其次，基於高層模型設計自動生產詳細的物理模型設計;第三，基於產生的物理模型設計，半自動或自動地生成資料加工邏輯，以確保最終的業務定義和物理實現的統一。具體如下圖1所示：

圖1 體系化建模概述

從對體系化建模的定義來看，它強調了兩個統一，即資料需求與模型設計的統一和模型設計與物理實現的統一。

資料需求與模型設計的統一，模型設計是倉庫領域劃分和具體需求相結合的產物。倉庫領域劃分是對資料進行基於業務本身但超越和脫離業務需求限制的抽象，對資料完成主題、業務過程的抽象，作為業務指標、維度需求歸屬和實現資料建設高內聚、低耦合的重要依據;具體的需求模型設計，是在倉庫領域劃分基礎上的內容填充，將需求以指標、維度的形式歸屬到對應的主題與業務過程，以此驅動和約束具體詳細模型設計，勾勒出寶貴的資訊架構資產。

模型設計與物理實現的統一，基於模型設計環節沉澱的資訊架構後設資料，以此來驅動和約束實際的物理模型，約束對應物理模型的DDL，在資料加工時，防止因缺乏有效約束帶來的“煙囪式”開發，是模型上線前，自動完成業務定義與物理實現一致性驗證，確保DML實現的正確性。

3 為什麼要進行體系化建模

此前一段時期，配送資料建設存在著需求管理(指標、維度)、模型設計、模型開發相互割裂不統一的現象，資料架構規範無法進行實質、有效的管理，後設資料(指標、維度、模型設計)與實際物理模型割裂、不匹配，造成各種資料資產資訊缺失。而且由於缺乏系統抓手，無法完全規範研發的模型設計質量，導致部分需求直接進行了資料開發，引起惡化模型建設質量的問題。這種缺乏規範和約束帶來的“煙囪式”開發，在浪費技術資源的同時造成資料重複且不可信。配送體系化建模切入點是：以規範“基礎資料建設”，消除因“煙囪式”開發給業務帶來的困擾和技術上的浪費。

3.1 體系化建模可以對資料架構進行實質有效的管理，從源頭消除“煙囪式”開發

體系化建模不僅可以在工具上實現一體化設計和開發，而且能在機制上形成模型設計與開發實施的有效協同。以需求驅動模型設計，以模型設計驅動和約束開發實施，防止因模型設計與開發實施割裂、開發實施缺少約束帶來的無序、“煙囪式”開發。

3.2 體系化建模沉澱的規範後設資料，可以有效消除業務在檢索和理解資料時的困擾

體系化建模不但將原先割裂的資料規範定義、模型設計以及最終的物理模型實現連線在一起，而且以後設資料的形式將資料資產的刻畫沉澱了下來，每個指標不僅有規範的業務定義和清晰的加工口徑，而且還可以對映到對應的物理表上，有效地消除了業務在檢索和理解資料時的困擾。

4 如何進行體系化建模

實現體系化建模要從源頭開始，將資料規範定義、資料模型設計和ETL開發連結在一起，以實現“設計即開發，所建即所得”。整體策略是從源頭開始，先在需求層面解決指標定義的問題，然後依次約束和驅動模型設計進而約束資料加工，將產生於線上業務流程各環節的資料進行領域化抽象，並實現業務規則的數字化，完成“物理世界”的數字孿生，形成“數字世界”。在工具層面實現基於需求的一體化設計和開發，在機制上形成模型設計與資料開發的有效協同。

圖2 體系化建模思路

體系化建模不僅在工具上基於需求實現一體化設計和開發，而且在機制上形成模型設計與資料加工的有效協同。首先，基於數倉規劃，將業務提的指標、維度對映到對應的主題、業務過程，然後基於資料定義標準，對業務指標進行結構化拆解，實現指標的技術定義，完成高層模型設計;其次，基於高層模型設計環節沉澱的後設資料，驅動和約束最終的物理模型設計，為後續的資料加工確定最終的DDL，完成物理模型設計，以此來約束後續的資料開發。

圖3 體系化建模流程

4.1 高層模型設計

一線的資料需求都是以指標和維度的形式提給資料工程師的，資料工程師首先要根據拿到的指標需求確定要分析的業務過程，完成業務過程的劃分和定義，同時將指標歸屬到對應的業務過程下;其次，根據指標的業務口徑，將業務指標拆分成原子指標+限定條件+時間週期或計算指標+限定條件+時間週期形式，完成指標的技術定義;第三，綜合各方分析視角，完成該業務過程一致維度的設計，多個業務過程一致性維度的設計構成該主題下的匯流排矩陣。

上述高層模型設計，涉及兩個環節。第一，透過業務抽象完成領域模型劃分，我們基於業務的實際流程來劃分業務過程，並按照分析領域完成業務過程的歸屬。在特定的業務下，分析領域和對應的業務流程不會隨著分析需求的變化而變化，領域劃分也不會隨著分析需求的變化而變化，可以基於此劃分，構建穩定的資產目錄。第二，透過完成業務指標的技術定義並將其歸屬到特定的業務過程下，以及確定特定業務過程的分析維度完成邏輯建模。邏輯建模進一步勾勒出了在特定的分析領域和業務過程下，具體的分析度量和分析維度，完成最終的高層模型設計，高層模型的設計決定了在特定的分析域和分析業務過程下的具體物理產出。

圖4 高層模型設計

更具體的講，確定業務過程下的分析度量需要完成業務指標的技術定義，並將其歸屬到特定的業務過程下。在這一步中，我們從技術角度對業務指標產出了結構化的技術定義，形成了一套結構化指標體系。一方面結構化定義容易統一併形成標準，避免全文字描述帶來理解上的歧義，另一方面結構化的定義有助於系統來保障其一致性，解決靠人工來保障一致性難以實施的難題。我們的結構化指標方案將指標分為：原子指標、計算指標和衍生指標，並針對這三類指標做了如下明確的定義：

原子指標：指在某一業務過程下不可再拆分的指標，具有明確業務含義的名詞。在物理實現上，它是特定業務過程下業務實體欄位加特定聚合運算元的組合。

計算指標：由原子指標與限定條件組合並經過加減乘除四則運算得到的指標。計算指標有明確的計算公式作為計算指標的定義，可以與多個限定條件進行組合。對於計算指標的歸屬，我們遵循2個原則①由於原子指標都能歸屬到相應的業務過程，業務過程一般來說都有時間前後順序，將計算指標歸屬到順序靠後的業務過程中;②如果涉及到多個業務過程，同時這些業務過程沒有時間的先後順序，這種情況下需要判斷指標描述內容與主題業務過程的相關性，然後再歸屬到對應的業務過程。在物理實現上，計算指標可以由其定義的計算公式直接自動的生成其實現邏輯。

衍生指標：由 “時間週期+多個限定條件+原子指標/計算指標” 組成的指標。由於衍生指標是由原子指標/計算指標衍生出來的，所以衍生指標需要歸屬到原子指標/計算指標所屬的業務過程。

限定條件：限定條件是指標業務口徑的一個邏輯封裝，時間週期也可以算作一類特殊的限定條件，是衍生指標必須包含的。在物理實現上我們將其加工成衍生事實的一個邏輯標籤。

在這樣的定義後，衍生指標便清晰地分為原子衍生指標和計算衍生指標兩類，都可以比較容易地透過結構化的方式半自動生成定義和實現。衍生指標覆蓋了使用者生成報表等資料產品的所有指標，而原子指標和計算指標作為指標體系的核心內容不直接提供給使用者使用。在指標的實現方式上也容易明確，原子指標和計算指標的邏輯儘量下沉在基礎事實層中，而衍生指標在中間層和應用層根據需求實現。

4.2 詳細模型設計

詳細模型設計是將高層模型設計轉化為實際物理生產的橋樑，詳細模型設計必須結合資料的生產流程，給出與其分層模型相匹配的實際物理模型。根據數倉不同分層間的職責邊界，詳細模型設計又呈現出不同特點。

具體說來，需要資料工程師結合業務需求，對應的邏輯建模產出的DDL完成最終物理模型的加工生產，這是我們詳細模型設計的核心。對於中間層彙總模型，是為提高查詢效能，基於明細模型進行預計算的過程，不涉及任務業務口徑的加工，只要後設資料定義清晰，完全可以透過工具實現“TEXT2SQL”進而實現配置化生產。我們的工程師只需要關注基建層的開發，中間和應用層建設交給工具完成，節省了大量的時間和精力。在展開詳細模型設計之前，我們先介紹一下數倉分層，然後透過資料分層來介紹與之匹配的詳細模型設計。

4.2.1 數倉分層簡介

按照整個資料生產的流轉鏈路看，資料會經歷產生、接入、加工到最後的消費，數倉的建設主要集中在資料的接入和加工環節。資料的接入包含資料的獲取和清洗兩個過程，透過該過程完成了資料從業務系統到倉庫的流轉，為後續基於分析場景的資料建模提供了原始資料，我們將該過程產生的資料定義為準備區資料，該過程基本透過工具實現了自動化，不需要太多的人為參與和設計。

另一過程，為了支援使用者、報表製作者以及其他BI應用的查詢，我們需要為使用者提供開放區資料，目前採取維度建模和倉庫分層理論，透過星型明細模型+多維彙總模型的方式分別滿足使用者固定的線上分析，以及無法預期的、隨意查詢的即席分析訴求。該區域是資料工程師整體工作的核心，可以利用線上建模沉澱的後設資料，輔助我們完成資料生產的提效和提質。在資料準備區，我們將資料模型分為基礎明細層(B3)、中間彙總層(B2、B1)來支撐不同場景的資料需求。

圖5 資料分層模型

4.2.2 後設資料驅動的詳細模型設計

設計理念

後設資料驅動的詳細模型設計，是基於高層模型設計產出的邏輯模型，進而來驅動和約束後續要加工的物理模型DDL，大致分成三步：第一，確定物理模型名稱;第二，基於模型歸屬自動生成基礎事實，基於需求確定衍生事實，完成事實確定;第三，基於匯流排矩陣，確定模型一致性維度。

每一步具體操作的內容因模型所屬的倉庫分層不同而有所區別。對於中間彙總層而言，只是在基礎模型基礎上的多維上卷，基礎模型確定以後，人工透過簡單的指標拖拽，就可以自動生產DDL而且可以自動生產DML，相對較簡單，在此不做詳述。接下來，我們重點描述一下基礎事實層的詳細模型設計，具體如下圖所示：

圖6 詳細模型設計

第一步，根據模型的出處確定模型名稱，經過此處，不僅規範了模型命名，而且在資料生產前自動實現了資產掛載，方便了後續資料的管理和運營;第二步，根據第一步的模型掛載，約束並確定該模型要生產的事實，即該模型所包含的基礎事實欄位由對應業務過程下的快照表決定，自動生產基礎事實欄位，該模型所包含的衍生事實由由對應業務過程下的衍生指標所需的限定條件決定，確保了需求、模型設計、物理實現三者的統一。

透過該過程，我們約束了實際生產環節物理模型的隨意加工，從源頭消除了“煙囪式”開發帶來的冗餘。透過後設資料約束了對應主題應該生產哪些事實，從源頭防止了邊界不清帶來的交叉耦合問題，保障了最終物理模型的高內聚、低耦合。

圖7 後設資料驅動的模型設計從源頭消除煙囪式開發

第三步，基於匯流排矩陣確定物理模型的一致性維度，不是基於需求來新增維度，後期如果因需求變動而頻繁調整基礎模型，這樣會導致基礎模型複用性差，而是在模型生產之初，一次性完成維度的設計和生產，以提升模型的穩定性和複用性。

圖8 採用匯流排矩陣約束模型保障模型複用性和穩定性

產品實現

在闡述了詳細模型設計的理念和約束後，我們再詳細看一下在具體產品層面是如何實現的。詳細模型設計就是基於上一階段的高層模型設計和物理建模的基本原則，採用系統化的方式引導資料工程師按照標準的流程完成對應的物理模型設計，以最終產出的DDL作為該環節的交付物，指導資料工程師在生產環節，完成最終的DML編寫。

這個環節除了輔助資料工程師完成規範化的模型設計外，還透過物理模型完備了上下文描述，包括完成了物理表與資產目錄的對映關係、物理欄位與指標維度的對映關係，為後續資產消費環節提供了完備的基礎後設資料。按照物理模型設計最終的交付物來看，它的設計流程主要包括兩部分：第一，按照規範和標準，確定物理模型的名稱;第二，按照規範和標準，確定物理模型的資料字典。

透過確定所建物理模型對應的數倉層級、主題域和業務過程，自動生成該物理表的名稱。

圖9 詳細模型設計之確定物理表的名稱和資產歸屬

基於高層模型設計環節確定的分析度量和維度，自動生成物理表對應的資料字典，確保模型設計與最終物理落地的一致性，從源頭杜絕不規範的開發。

圖10 詳細模型設計之確定物理表的欄位資訊並完成指標、維度與欄位的對映

4.3 上線前卡點

高層模型設計和詳細模型設計約束和規範了資料工程師如何確定一個模型的DDL，對於如何約束和保證實際的加工邏輯(模型的DML)和業務定義保持一致，並沒有與之匹配的約束卡點。上線前卡點就是利用高層模型和詳細模型設計這兩個環節產生的後設資料，透過自動化的方式來完成DML與業務定義的一致性驗證，消除人工驗證帶來的成本問題。具體卡點驗證包括四類：

相同指標不同出處的資料一致性驗證，將來自不同出處的相同指標上捲到相同維度，它們具有相同的數值;

業務定義與具體實現的一致性驗證，此類驗證主要針對碼值類欄位，具體數值必須與其對應的業務定義一致;

研發合規的約束類驗證，例如，主鍵必須唯一、全表掃描、程式碼流程分支覆蓋(T+1重導、批次重導、全量重導);

變更時的級聯影響，包括下游的生產任務影響和消費任務影響。

5 總結

體系化建模是配送資料團隊圍繞著資料資產化建設“提質降本和資料應用提效”這一目標孵化的產物，本著將標準流程工具化的思路，我們透過工具來約束和規範資料工程師的生產，力圖將模型的規範化治理做到事前，避免重蹈業務快速發展階段“先建設後治理”的覆轍。在模型提質方面，我們實現了高層模型設計、物理模型設計的統一以及業務定義與物理實現的統一，而且在提效方面，線上建模透過系統的方式為我們沉澱了寶貴的後設資料，是我們後續基於後設資料進行應用提效的關鍵。

① 體系化建模，搭建起了資料定義到生產的橋樑，實現資料到資訊的轉化，提供了完備的流程保障，並在配送內部實現了涉及10多個主題、180多個原子指標、300多個計算指標和90多個衍生指標的統一。

圖11 資料定義、生產、加工全流程統一

在美團內部，涉及配送交易、履約等核心主題的規範性建設方面治理評分均取得了優秀的成績，特別是在指標完整性建設得分和物理模型維度完整性得分方面，均取得90分以上優秀成績。

圖12 健康的主題得分

② 得益於體系化建模實現的後設資料和資料的統一，我們實現了資料建設從“保姆”模式到“服務+自助”模式的轉變。

在資料檢索方面，得益於體系化建模沉澱的高質量後設資料，我們構建了資料地圖，解決了資料“可搜尋/可獲取”問題，並在檢索內容方面實現了所建即所得。

圖13 資料可檢索

在資料消費方面，得益於體系化建模沉澱的高質量後設資料，我們實現了“服務+自助”的資料服務模式，不僅消除了傳統報表開發完全依賴產研帶來的開發流程長、需求響應慢、覆蓋使用者少等問題，而且解決了無法“零SQL”即席分析的難題，滿足了業務人員透過“拖、拉、拽”即可快速產生分析報告的訴求。

圖14 按需自由組裝指標獲取資料

目前，該模式廣泛應用於所有業務大區”零SQL“資料運營人員早報、週報、季度述職等業務場景，得益於上述模式，不僅得到了一線人員廣泛好評，而且也將我們的資料RD從“取數”、“跑數”的繁重工作中解脫出來。

作者簡介：王鵬、新興、曉飛，均來自美團配送事業部資料團隊。