一、前言

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

二、什么是體系化建模

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

圖1 體系化建模概述

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

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

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

三、為什么要進行體系化建模

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

1、對數據架構實質有效的管理，從源頭消除“煙囪式”開發

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

2、沉淀的規范元數據，可以有效消除業務在檢索和理解數據時的困擾

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

四、如何進行體系化建模

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

圖2 體系化建模思路

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

圖3 體系化建模流程

1、高層模型設計

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

上述高層模型設計，涉及兩個環節。

第一，通過業務抽象完成領域模型劃分，我們基于業務的實際流程來劃分業務過程，并按照分析領域完成業務過程的歸屬。在特定的業務下，分析領域和對應的業務流程不會隨著分析需求的變化而變化，領域劃分也不會隨著分析需求的變化而變化，可以基于此劃分，構建穩定的資產目錄。

第二，通過完成業務指標的技術定義并將其歸屬到特定的業務過程下，以及確定特定業務過程的分析維度完成邏輯建模。邏輯建模進一步勾勒出了在特定的分析領域和業務過程下，具體的分析度量和分析維度，完成最終的高層模型設計，高層模型的設計決定了在特定的分析域和分析業務過程下的具體物理產出。

圖4 高層模型設計

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

• 原子指標：指在某一業務過程下不可再拆分的指標，具有明確業務含義的名詞。在物理實現上，它是特定業務過程下業務實體字段加特定聚合算子的組合。
• 計算指標：由原子指標與限定條件組合并經過加減乘除四則運算得到的指標。計算指標有明確的計算公式作為計算指標的定義，可以與多個限定條件進行組合。對于計算指標的歸屬，我們遵循2個原則①由于原子指標都能歸屬到相應的業務過程，業務過程一般來說都有時間前后順序，將計算指標歸屬到順序靠后的業務過程中;②如果涉及到多個業務過程，同時這些業務過程沒有時間的先后順序，這種情況下需要判斷指標描述內容與主題業務過程的相關性，然后再歸屬到對應的業務過程。在物理實現上，計算指標可以由其定義的計算公式直接自動的生成其實現邏輯。
• 衍生指標：由 “時間周期+多個限定條件+原子指標/計算指標” 組成的指標。由于衍生指標是由原子指標/計算指標衍生出來的，所以衍生指標需要歸屬到原子指標/計算指標所屬的業務過程。
• 限定條件：限定條件是指標業務口徑的一個邏輯封裝，時間周期也可以算作一類特殊的限定條件，是衍生指標必須包含的。在物理實現上我們將其加工成衍生事實的一個邏輯標簽。

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

2、詳細模型設計

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

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

1)數倉分層簡介

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

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

圖5 數據分層模型

2)元數據驅動的詳細模型設計

① 設計理念

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

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

圖6 詳細模型設計

第一步，根據模型的出處確定模型名稱，經過此處，不僅規范了模型命名，而且在數據生產前自動實現了資產掛載，方便了后續數據的管理和運營;

第二步，根據第一步的模型掛載，約束并確定該模型要生產的事實，即該模型所包含的基礎事實字段由對應業務過程下的快照表決定，自動生產基礎事實字段，該模型所包含的衍生事實由由對應業務過程下的衍生指標所需的限定條件決定，確保了需求、模型設計、物理實現三者的統一。

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

圖7 元數據驅動的模型設計從源頭消除煙囪式開發

第三步，基于總線矩陣確定物理模型的一致性維度，不是基于需求來添加維度，后期如果因需求變動而頻繁調整基礎模型，這樣會導致基礎模型復用性差，而是在模型生產之初，一次性完成維度的設計和生產，以提升模型的穩定性和復用性。

圖8 采用總線矩陣約束模型保障模型復用性和穩定性

② 產品實現

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

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

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

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

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

圖10 詳細模型設計之確定物理表的字段信息并完成指標、維度與字段的映射

3、上線前卡點

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

• 相同指標不同出處的數據一致性驗證，將來自不同出處的相同指標上卷到相同維度，它們具有相同的數值;
• 業務定義與具體實現的一致性驗證，此類驗證主要針對碼值類字段，具體數值必須與其對應的業務定義一致;
• 研發合規的約束類驗證，例如，主鍵必須唯一、全表掃描、代碼流程分支覆蓋(T+1重導、批量重導、全量重導);
• 變更時的級聯影響，包括下游的生產任務影響和消費任務影響。

五、總結

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

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

圖11 數據定義、生產、加工全流程統一

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

圖12 健康的主題得分

得益于體系化建模實現的元數據和數據的統一，我們實現了數據建設從“保姆”模式到“服務+自助”模式的轉變。

在數據檢索方面，得益于體系化建模沉淀的高質量元數據，我們構建了數據地圖，解決了數據“可搜索/可獲取”問題，并在檢索內容方面實現了所建即所得。

圖13 數據可檢索

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

圖14 按需自由組裝指標獲取數據

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