维度建模基本流程总结
一、維度建模基本流程圖
數據RD進行業務調研和數據現狀調研，產出符合相關模版規范的業務知識文檔和數據現狀文檔。數據PM也會調研相關業務產出需求設計文檔，三方參與需求評審，評審通過后基建數據RD進行需求拆解，產出技術方案，三方進行技術方案評審，如果技術方案評審通過進入基建需求池、排期、開發、上線并做相關數據運營動作。
二、維度建模流程詳情
詳細流程主要介紹每個步驟的參與方、行動詳情、產出結果并明確相關的check機制。
2.1 業務調研
關鍵動作
業務調研主要是業務方、數據PM、數據RD參與，數據RD具體動作如下：
1.理解業務環境，通過和業務方代表交流發現需求，用于理解他們基于關鍵性能指標、競爭性商業問題、決策制定過程、支持分析需求的目標。
2.梳理業務過程，通過和源系統專家交流信息、業務方的描述信息梳理業務過程，業務過程是一個不可拆分的行為事件。
3.分析關鍵業務和核心問題，分析關鍵業務及其動作是什么，明確業務現階段所關注的核心問題，對核心問題的理解有助于我們覆蓋業務場景。
核心成果
業務調研完成后，需要編寫業務知識文檔，此文檔可以按照如下思路整理
1.業務簡介，源系統業務簡單概述，明確決策過程和分析目標等。
2.統一業務概念，將源數據（即業務系統）中隱含的、有歧義的概念進行清晰化。
3.業務流程介紹，重點關注源系統的ER模型，整理業務流程圖，梳理業務基本動作等。
4.總結業務對數據的需求，重點梳理業務指標。
業務調研步驟可重可輕，重：基建層面從質量、效率、成本和擴展性長遠考慮需要深入調研并理解。①質量: 通過數據集成和一致性建設，提升數據指標的一致性及及時性；②效率：提升計算、存儲、查詢效率，提升用戶體驗；③成本：減少不必要的數據冗余、提升模型復用度，降低存儲、計算以及維護開發、降低成本。④擴展：屏蔽業務及上游系統的變更影響，能靈活快速兼容業務變更以及支撐新業務。
輕：根據需求緊急程度，結合原有調研的相關知識，快速支持業務需求。
2.2 數據現狀調研
關鍵動作
數據現狀調研主要是數據PM、數據RD參與，關鍵動作如下：
1.數據PM需要梳理歷史定義的數據指標口徑，這部分口徑解決什么問題（隨著時間推移歷史指標口徑不明確，解釋不清等）。
2.從數據RD角度需要梳理之前產出的模型、看板、數據產品，不同的交付方式所對應的模型是否相同，有沒有口徑不統一的風險。同時將這部分涉及的底表列出來，還沒有接入的提前接入。
核心成果
1.數據RD明確指標如何使用：主要是通過表格描述清楚之前的看板和產品使用的模型、模型對應的指標。
2.歷史指標及其口徑，從數據PM角度需要了解之前定義的數據指標口徑，這部分口徑解決什么問題。
3.初步給出一些優化改進建議，比如重復邏輯下沉、重復開發優化等。
2.3 主題抽象&總線矩陣
關鍵動作
主要由數據RD完成，關鍵動作如下：
1.明確數倉建設的相關分層和命名規范。
2.明確數據域的抽象劃分。
3.明確主題、業務過程及其對應關系。
4.明確業務過程和一致性維度關系。
核心成果
產出相關文檔，主要包含①主題、詞根和主題對應業務過程關系表；②主題和一致性維度矩陣，方便從宏觀認識整個數倉；③每個主題下業務過程和一致性維度關系矩陣。
2.4 數據需求設計
關鍵動作
主要由數據PM完成，關鍵動作如下：
1.明確背景和業務價值。
2.如果是涉及到產品化的項目需要明確產品或報表工具，設計相關原型圖。如果只提供數據集，需要明確指標如何使用，作用的結果。
3.定義清楚維度和指標（偏應用層指標）
4.明確期望交付時間、交付結果，數據回刷范圍等。
關鍵產出就是需求文檔（PRD）。
需求PRD產出后需要組織業務方、數據RD和PM進行需求評審，主要check 需求評審文檔，是否符合既定規范，價值描述清晰、維度和指標口徑，數據范圍、交付時間等。
2.5 數據需求拆解
關鍵動作
主要由數據RD完成，關鍵動作如下：
事實表設計：
1.選擇業務過程：選擇主題域明確主題下的業務過程，選擇具體的業務過程（在主題域內根據情況會抽象新增/合并業務過程）開始拆解。
2.確定事實表，根據需求設計合適的事實表類型，事務事實表、周期快照事實表、累積快照事實表。
3.聲明粒度，在從給定的業務過程中獲取數據時，原子粒度是最低級別的粒度，建議優先關注原子粒度數據開始設計，原子粒度數據能承受無法預期的用戶查詢，然后根據針對業務公共問題和性能出發設計上卷匯總粒度數據表。
4.確認維度：維度是度量的環境，用來反映業務的一類屬性，這類屬性的集合構成一個維度，也可以成為實體對象。在實際工作中好的維度設計可以層次遞進的反應業務情況
5.確認事實（指標）：事實就是度量，一般是對某個業務事件的衡量，通常為數字，如定單量，訂單金額等。盡可能包含業務過程下所有原子指標，只選擇和業務過程相關的原子指標，統一同類指標的單位。根據規范對指標拆解：①確定原子指標：基于某一業務時間行為下的度量，是業務定義中不可再拆分的指標（比率等指標除外），具有明確業務含義和業務完整定義的名詞。原子指標=業務過程（動作）+度量，比如推單量，下單金額，支付金額；②確定派生指標：派生指標=一個原子指標+多個修飾詞（可選）+時間周期。可以理解為對原子指標業務統計范圍的圈定。比如昨日新用戶下單量
6.梳理具體業務過程下的指標維度矩陣。
維表表設計
1.選擇實體
維度表設計首先要選擇實體，也就是維度表所要描述的抽象對象。如，互聯網電商在交易過程中涉及到的實體有：買家、賣家、訂單、廣告等等，當然還有一些在不同業務場景下衍生出來的一些業務抽象實體，如優惠券、活動、商圈等都可以作為維度實體。 實體的選擇主要是結合業務流程，在需要建模的業務流程環節涉及到了哪些參與者，這些不同的參與者便是維度表描述的實體對象，維度表中的屬性，就是用來區分不同實體的特性。
2.確定主維表
確定主維表，主要是識別出維度表的主要數據來源。通常，業務系統中也會將相同類型業務實體進行統一存儲（即一張表），亦或是在大型企業有建設業務中臺會提前做同類業務實體的數據融合（如，商品中心、用戶中心等）。但在沒有類似業務中臺可以直接獲取全量維度實體數據的情況下，就需要自行確定業務實體數據的來源，并做融合。一般情況會將常規主要業務流程中產生的業務系統數據做為主維度表，因為其一般是維度表的主要數據來源，并且數據準確、豐富。
3.確定輔維表
輔維表存在的目的有兩方面。一方面是補全主維表在維度實體的數據；另一方面是為了尋找維度表所表示的業務實體的一些其他屬性描述輔助表，這些輔維表用來豐富維度表的屬性描述，增強維度表的表現性，同樣也能擴展維度表的分析能力。
4.識別維度屬性
維度表的維度屬性一般可以分為相對穩定的“固化屬性”和變動頻繁“動態屬性“。由于“固化屬性”和“動態屬性”的變更周期差異巨大，一般會在維度表的構建過程中結合具體的場景進行拆分，一方面是保證維度表能夠高效的產出，另一方面也是為追溯歷史數據提供合理的技術實現。
注意點：增加文字描述（枚舉和中文對應關系）；統一單位；統一標志值（0/1，Y/N）等。
關鍵結果
產出業務過程下的指標維度矩陣。
2.6 技術方案設計和評審
主要由數據RD完成技術方案設計，然后組織PM和RD進行技術方案評審，關鍵動作如下：
1.原則上遵循公司數倉建模規范或數據倉庫工具箱相關規范。
2.編寫技術方案，背景部分主要闡述業務痛點和目標；需求梳理主要是明確我們開發的指標維度矩陣；核心模型設計即數倉整體架構設計（服務規范）和表詳情設計，表詳情設計部分主要明確三個部分①表的中英文名稱②指標名和口徑③指標加工邏輯和相關數據調研；最后技術方案中明確上線事項和分工排期。
關鍵結果
產出技術方案，技術方案可以分如下幾個模塊①項目背景，附上相關PRD和說明文檔鏈接，介紹清楚背景收益等；②問題和風險，對于存在的問題和風險（業務風險、技術風險）應當有對應的方案，如存在風險或問題情況下，仍按需求進行，需要明確相關責任人。③項目計劃，明確相關責任人和具體開發排期。④需求調研，調研需求的指標、維度和相關接口。⑤詳細設計，第一部分給出整體的設計架構圖；第二部分接口設計詳情；第三部分數倉模型設計；⑥技術選型，重點關注查詢引擎，查詢量級，QPS等；⑦上線事項：測試case、上線順序、上線Check List、承諾產出時間，穩定性保障、降級策略（數據延遲、集群異常等兜底方案是否可以使用T+2的數據，前端進行banner文案提示“數據暫不可用”，對外提供接口方式，應當與數據使用方商定出現無數據情況的后端兜底或者前端兜底。數據內容本身的錯誤和BUG無法進行兜底，責任由數倉RD來進行負責并處理。）
2.7 數據交付&運營
對相關指標進行綁定錄入，編寫使用文檔等。
總結
以上是生活随笔為你收集整理的维度建模基本流程总结的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 分形在山地生成中的应用[1]---中点位
- 下一篇： 维度建模入门