1 前言
隨着數字經濟的快速發展，數據已經成爲新的生產要素。如何有效地開展數據治理工作，提升數據質量，打破數據孤島，充分發揮數據的業務價值，已成爲業界的熱門話題。本文基於美團配送數據治理的歷程，重點和大家分享一下配送數據“底座”的建設與實踐，如何通過體系化建模建立起數據定義到數據生產的橋樑，達成數據定義、模型設計、數據生產三個環節的統一，消除因數據標準缺失和執行不到位引發的數據信任問題，在高質量地實現數據到信息的轉化的同時，爲後續的數據便捷消費提供數據和元數據保障。希望能給從事數據治理方向的同學在實現數據到資產的轉化過程提供一些參考和借鑑。
2 什麼是體系化建模
體系化建模是以維度建模爲理論基礎，以事前治理的理念驅動，讓元數據貫穿其中的建模流程，上承指標、維度的定義，下接實際的數據生產。首先，通過高層模型設計，將業務指標結構化拆解爲原子指標/計算指標+限定條件的組合方式，並將其歸屬到特定的業務過程和主題下，完成業務指標的計劃化定義；其次，基於高層模型設計自動生產詳細的物理模型設計；第三，基於產生的物理模型設計，半自動或自動地生成數據加工邏輯，以確保最終的業務定義和物理實現的統一。具體如下圖所示：
從對體系化建模的定義來看，它強調了兩個統一，即數據需求與模型設計的統一和模型設計與物理實現的統一。
數據需求與模型設計的統一，模型設計是倉庫領域劃分和具體需求相結合的產物。倉庫領域劃分是對數據進行基於業務本身但超越和脫離業務需求限制的抽象，對數據完成主題、業務過程的抽象，作爲業務指標、維度需求歸屬和實現數據建設高內聚、低耦合的重要依據；具體的需求模型設計，是在倉庫領域劃分基礎上的內容填充，將需求以指標、維度的形式歸屬到對應的主題與業務過程，以此驅動和約束具體詳細模型設計，勾勒出寶貴的信息架構資產。
模型設計與物理實現的統一，基於模型設計環節沉澱的信息架構元數據，以此來驅動和約束實際的物理模型，約束對應物理模型的DDL，在數據加工時，防止因缺乏有效約束帶來的“煙囪式”開發，是模型上線前，自動完成業務定義與物理實現一致性驗證，確保DML實現的正確性。
3 爲什麼要進行體系化建模
此前一段時期，配送數據建設存在着需求管理（指標、維度）、模型設計、模型開發相互割裂不統一的現象，數據架構規範無法進行實質、有效的管理，元數據（指標、維度、模型設計）與實際物理模型割裂、不匹配，造成各種數據資產信息缺失。而且由於缺乏系統抓手，無法完全規範研發的模型設計質量，導致部分需求直接進行了數據開發，引起惡化模型建設質量的問題。這種缺乏規範和約束帶來的“煙囪式”開發，在浪費技術資源的同時造成數據重複且不可信。配送體系化建模切入點是：以規範“基礎數據建設”，消除因“煙囪式”開發給業務帶來的困擾和技術上的浪費。
3.1 體系化建模可以對數據架構進行實質有效的管理，從源頭消除“煙囪式”開發
體系化建模不僅可以在工具上實現一體化設計和開發，而且能在機制上形成模型設計與開發實施的有效協同。以需求驅動模型設計，以模型設計驅動和約束開發實施，防止因模型設計與開發實施割裂、開發實施缺少約束帶來的無序、“煙囪式”開發。
3.2 體系化建模沉澱的規範元數據，可以有效消除業務在檢索和理解數據時的困擾
體系化建模不但將原先割裂的數據規範定義、模型設計以及最終的物理模型實現連接在一起，而且以元數據的形式將數據資產的刻畫沉澱了下來，每個指標不僅有規範的業務定義和清晰的加工口徑，而且還可以映射到對應的物理表上，有效地消除了業務在檢索和理解數據時的困擾。
4 如何進行體系化建模
實現體系化建模要從源頭開始，將數據規範定義、數據模型設計和ETL開發鏈接在一起，以實現“設計即開發，所建即所得”。整體策略是從源頭開始，先在需求層面解決指標定義的問題，然後依次約束和驅動模型設計進而約束數據加工，將產生於線上業務流程各環節的數據進行領域化抽象，並實現業務規則的數字化，完成“物理世界”的數字孿生，形成“數字世界”。在工具層面實現基於需求的一體化設計和開發，在機制上形成模型設計與數據開發的有效協同。
體系化建模不僅在工具上基於需求實現一體化設計和開發，而且在機制上形成模型設計與數據加工的有效協同。首先，基於數倉規劃，將業務提的指標、維度映射到對應的主題、業務過程，然後基於數據定義標準，對業務指標進行結構化拆解，實現指標的技術定義，完成高層模型設計；其次，基於高層模型設計環節沉澱的元數據，驅動和約束最終的物理模型設計，爲後續的數據加工確定最終的DDL，完成物理模型設計，以此來約束後續的數據開發。
4.1 高層模型設計
一線的數據需求都是以指標和維度的形式提給數據工程師的，數據工程師首先要根據拿到的指標需求確定要分析的業務過程，完成業務過程的劃分和定義，同時將指標歸屬到對應的業務過程下；其次，根據指標的業務口徑，將業務指標拆分成原子指標+限定條件+時間週期或計算指標+限定條件+時間週期形式，完成指標的技術定義；第三，綜合各方分析視角，完成該業務過程一致維度的設計，多個業務過程一致性維度的設計構成該主題下的總線矩陣。
上述高層模型設計，涉及兩個環節。第一，通過業務抽象完成領域模型劃分，我們基於業務的實際流程來劃分業務過程，並按照分析領域完成業務過程的歸屬。在特定的業務下，分析領域和對應的業務流程不會隨着分析需求的變化而變化，領域劃分也不會隨着分析需求的變化而變化，可以基於此劃分，構建穩定的資產目錄。第二，通過完成業務指標的技術定義並將其歸屬到特定的業務過程下，以及確定特定業務過程的分析維度完成邏輯建模。邏輯建模進一步勾勒出了在特定的分析領域和業務過程下，具體的分析度量和分析維度，完成最終的高層模型設計，高層模型的設計決定了在特定的分析域和分析業務過程下的具體物理產出。
更具體的講，確定業務過程下的分析度量需要完成業務指標的技術定義，並將其歸屬到特定的業務過程下。在這一步中，我們從技術角度對業務指標產出了結構化的技術定義，形成了一套結構化指標體系。一方面結構化定義容易統一併形成標準，避免全文字描述帶來理解上的歧義，另一方面結構化的定義有助於系統來保障其一致性，解決靠人工來保障一致性難以實施的難題。我們的結構化指標方案將指標分爲：原子指標、計算指標和衍生指標，並針對這三類指標做了如下明確的定義：
- 原子指標：指在某一業務過程下不可再拆分的指標，具有明確業務含義的名詞。在物理實現上，它是特定業務過程下業務實體字段加特定聚合算子的組合。
- 計算指標：由原子指標與限定條件組合並經過加減乘除四則運算得到的指標。計算指標有明確的計算公式作爲計算指標的定義，可以與多個限定條件進行組合。對於計算指標的歸屬，我們遵循2個原則①由於原子指標都能歸屬到相應的業務過程，業務過程一般來說都有時間前後順序，將計算指標歸屬到順序靠後的業務過程中；②如果涉及到多個業務過程，同時這些業務過程沒有時間的先後順序，這種情況下需要判斷指標描述內容與主題業務過程的相關性，然後再歸屬到對應的業務過程。在物理實現上，計算指標可以由其定義的計算公式直接自動的生成其實現邏輯。
- 衍生指標：由 “時間週期+多個限定條件+原子指標/計算指標” 組成的指標。由於衍生指標是由原子指標/計算指標衍生出來的，所以衍生指標需要歸屬到原子指標/計算指標所屬的業務過程。
- 限定條件：限定條件是指標業務口徑的一個邏輯封裝，時間週期也可以算作一類特殊的限定條件，是衍生指標必須包含的。在物理實現上我們將其加工成衍生事實的一個邏輯標籤。
在這樣的定義後，衍生指標便清晰地分爲原子衍生指標和計算衍生指標兩類，都可以比較容易地通過結構化的方式半自動生成定義和實現。衍生指標覆蓋了用戶生成報表等數據產品的所有指標，而原子指標和計算指標作爲指標體系的核心內容不直接提供給用戶使用。在指標的實現方式上也容易明確，原子指標和計算指標的邏輯儘量下沉在基礎事實層中，而衍生指標在中間層和應用層根據需求實現。
4.2 詳細模型設計
詳細模型設計是將高層模型設計轉化爲實際物理生產的橋樑，詳細模型設計必須結合數據的生產流程，給出與其分層模型相匹配的實際物理模型。根據數倉不同分層間的職責邊界，詳細模型設計又呈現出不同特點。
具體說來，需要數據工程師結合業務需求，對應的邏輯建模產出的DDL完成最終物理模型的加工生產，這是我們詳細模型設計的核心，對於中間層彙總模型，是爲提高查詢性能，基於明細模型進行預計算的過程，不涉及任務業務口徑的加工，只要元數據定義清晰，完全可以通過工具實現“TEXT2SQL”進而實現配置化生產。我們的工程師只需要關注基建層的開發，中間和應用層建設交給工具完成，節省了大量的時間和精力。在展開詳細模型設計之前，我們先介紹一下數倉分層，然後通過數據分層來介紹與之匹配的詳細模型設計。
4.2.1 數倉分層簡介
按照整個數據生產的流轉鏈路看，數據會經歷產生、接入、加工到最後的消費，數倉的建設主要集中在數據的接入和加工環節。數據的接入包含數據的獲取和清洗兩個過程，通過該過程完成了數據從業務系統到倉庫的流轉，爲後續基於分析場景的數據建模提供了原始數據，我們將該過程產生的數據定義爲準備區數據，該過程基本通過工具實現了自動化，不需要太多的人爲參與和設計。
另一過程，爲了支持用戶、報表製作者以及其他BI應用的查詢，我們需要爲用戶提供開放區數據，目前採取維度建模和倉庫分層理論，通過星型明細模型+多維彙總模型的方式分別滿足用戶固定的在線分析，以及無法預期的、隨意查詢的即席分析訴求。該區域是數據工程師整體工作的核心，可以利用在線建模沉澱的元數據，輔助我們完成數據生產的提效和提質。在數據準備區，我們將數據模型分爲基礎明細層（B3）、中間彙總層（B2、B1）來支撐不同場景的數據需求。
4.2.2 元數據驅動的詳細模型設計
設計理念
元數據驅動的詳細模型設計，是基於高層模型設計產出的邏輯模型，進而來驅動和約束後續要加工的物理模型DDL，大致分成三步：第一，確定物理模型名稱；第二，基於模型歸屬自動生成基礎事實，基於需求確定衍生事實，完成事實確定；第三，基於總線矩陣，確定模型一致性維度。
每一步具體操作的內容因模型所屬的倉庫分層不同而有所區別。對於中間彙總層而言，只是在基礎模型基礎上的多維上卷，基礎模型確定以後，人工通過簡單的指標拖拽，就可以自動生產DDL而且可以自動生產DML，相對較簡單，在此不做詳述。接下來，我們重點描述一下基礎事實層的詳細模型設計，具體如下圖所示：
第一步，根據模型的出處確定模型名稱，經過此處，不僅規範了模型命名，而且在數據生產前自動實現了資產掛載，方便了後續數據的管理和運營；第二步，根據第一步的模型掛載，約束並確定該模型要生產的事實，即該模型所包含的基礎事實字段由對應業務過程下的快照表決定，自動生產基礎事實字段，該模型所包含的衍生事實由由對應業務過程下的衍生指標所需的限定條件決定，確保了需求、模型設計、物理實現三者的統一。
通過該過程，我們約束了實際生產環節物理模型的隨意加工，從源頭消除了“煙囪式”開發帶來的冗餘。通過元數據約束了對應主題應該生產哪些事實，從源頭防止了邊界不清帶來的交叉耦合問題，保障了最終物理模型的高內聚、低耦合。
第三步，基於總線矩陣確定物理模型的一致性維度，不是基於需求來添加維度，後期如果因需求變動而頻繁調整基礎模型，這樣會導致基礎模型複用性差，而是在模型生產之初，一次性完成維度的設計和生產，以提升模型的穩定性和複用性。
產品實現
在闡述了詳細模型設計的理念和約束後，我們再詳細看一下在具體產品層面是如何實現的。詳細模型設計就是基於上一階段的高層模型設計和物理建模的基本原則，採用系統化的方式引導數據工程師按照標準的流程完成對應的物理模型設計，以最終產出的DDL作爲該環節的交付物，指導數據工程師在生產環節，完成最終的DML編寫。
這個環節除了輔助數據工程師完成規範化的模型設計外，還通過物理模型完備了上下文描述，包括完成了物理表與資產目錄的映射關係、物理字段與指標維度的映射關係，爲後續資產消費環節提供了完備的基礎元數據。按照物理模型設計最終的交付物來看，它的設計流程主要包括兩部分：第一，按照規範和標準，確定物理模型的名稱；第二，按照規範和標準，確定物理模型的數據字典。
- 通過確定所建物理模型對應的數倉層級、主題域和業務過程，自動生成該物理表的名稱。
- 基於高層模型設計環節確定的分析度量和維度，自動生成物理表對應的數據字典，確保模型設計與最終物理落地的一致性，從源頭杜絕不規範的開發。
4.3 上線前卡點
高層模型設計和詳細模型設計約束和規範了數據工程師如何確定一個模型的DDL，對於如何約束和保證實際的加工邏輯（模型的DML）和業務定義保持一致，並沒有與之匹配的約束卡點。上線前卡點就是利用高層模型和詳細模型設計這兩個環節產生的元數據，通過自動化的方式來完成DML與業務定義的一致性驗證，消除人工驗證帶來的成本問題。具體卡點驗證包括四類：
- 相同指標不同出處的數據一致性驗證，將來自不同出處的相同指標上捲到相同維度，它們具有相同的數值；
- 業務定義與具體實現的一致性驗證，此類驗證主要針對碼值類字段，具體數值必須與其對應的業務定義一致；
- 研發合規的約束類驗證，例如，主鍵必須唯一、全表掃描、代碼流程分支覆蓋（T+1重導、批量重導、全量重導）；
- 變更時的級聯影響，包括下游的生產任務影響和消費任務影響。
5 總結
體系化建模是配送數據團隊圍繞着數據資產化建設“提質降本和數據應用提效”這一目標孵化的產物，本着將標準流程工具化的思路，我們通過工具來約束和規範數據工程師的生產，力圖將模型的規範化治理做到事前，避免重蹈業務快速發展階段“先建設後治理”的覆轍。在模型提質方面，我們實現了高層模型設計、物理模型設計的統一以及業務定義與物理實現的統一，而且在提效方面，在線建模通過系統的方式爲我們沉澱了寶貴的元數據，是我們後續基於元數據進行應用提效的關鍵。
① 體系化建模，搭建起了數據定義到生產的橋樑，實現數據到信息的轉化，提供了完備的流程保障，並在配送內部實現了涉及10多個主題、180多個原子指標、300多個計算指標和90多個衍生指標的統一。
在美團內部，涉及配送交易、履約等核心主題的規範性建設方面治理評分均取得了優秀的成績，特別是在指標完整性建設得分和物理模型維度完整性得分方面，均取得90分以上優秀成績。
② 得益於體系化建模實現的元數據和數據的統一，我們實現了數據建設從“保姆”模式到“服務+自助”模式的轉變。
在數據檢索方面，得益於體系化建模沉澱的高質量元數據，我們構建了數據地圖，解決了數據“可搜索/可獲取”問題，並在檢索內容方面實現了所建即所得。
在數據消費方面，得益於體系化建模沉澱的高質量元數據，我們實現了“服務+自助”的數據服務模式，不僅消除了傳統報表開發完全依賴產研帶來的開發流程長、需求響應慢、覆蓋用戶少等問題，而且解決了無法“零SQL”即席分析的難題，滿足了業務人員通過“拖、拉、拽”即可快速產生分析報告的訴求。
目前，該模式廣泛應用於所有業務大區”零SQL“數據運營人員早報、週報、季度述職等業務場景，得益於上述模式，不僅得到了一線人員廣泛好評，而且也將我們的數據RD從“取數”、“跑數”的繁重工作中解脫出來。