目錄

一、什么是建模？（為什么建模）

二、模型的好處

三、建模的方法

四、維度建模

4.1 基本概念

4.2 為啥選擇維度建模（優缺點）

4.2.1 優點

4.2.2 缺點

4.3 維度建模-星型模型

4.4 維度建模-維度

4.4.1 維度之緩慢變化維

?4.4.2 維度層次

4.4.3 維度之常見應用

4.5 維度建模-事實

4.5.1 事實的分類

4.5.2 事實表的分類

4.6 維度建模-建模步驟

4.6.1 業務建模（Conceptual Data Model）

4.6.2 邏輯建模（Logical Data Model）

4.6.3 物理建模（Physical Data Model）

4.7 數倉整體分層

4.7.1 分層規范

4.7.2 為什么分層（分層好處

一、什么是建模？（為什么建模）

數倉建模的本質是通過模型完成對復雜業務的抽象，清晰準確完整的刻畫業務場景，以便用戶通過業務視角便捷的獲取所需數據，完成對業務活動的度量。

從上面這句話，我們可以得出建模的四要素：一個過程(抽象)和三個目標(清晰、準確、完整)。

抽象：是指從眾多的事物中抽取出共同的、本質性的特征，而舍棄其非本質的特征的過程。通過抽象我們可以屏蔽繁瑣的底層細節，聚焦業務本質，同時提升模型的穩定性，減少業務系統變更帶來的沖擊。

清晰：清晰是指模型信息必須是清楚、明了有條理的；通過抽象，我們可以將繁雜無章的數據進行歸納總結，以結構化的方式清晰的描述業務。

準確：準確是指模型表達的語義和用戶理解的語義是一致的；通過理清業務關系，明確統一業務概念，就可以對業務活動進行準確的描述。

完整：完整是指業務信息必須是完整的，沒有信息丟失的；信息丟失會造成業務描述的不完整，最終導致無法滿足業務訴求。

二、模型的好處

質量:??通過數據集成和一致性建設，提升數據指標的一致性及及時性

效率：提升計算、存儲、查詢效率，提升用戶體驗

成本：減少不必要的數據冗余、提升模型復用度，降低存儲、計算以及維護開發、降低成本????????

擴展：屏蔽業務及上游系統的變更影響，能靈活快速兼容業務變更以及支撐新業務

三、建模的方法

范式建模(Normal Forms)：符合數據庫規范化設計的數據模型，強調模型的規范性，減少數據冗余，增強一致性，目前有1NF~6NF，大部分場景要求達到3NF。

維度建模：從便于分析的角度，按照維度、事實的形式來構建數據模型，主要以星型模式來展現

DataVault建模：面向細節的、可追蹤歷史的、一組有連接關系的規范化的表的集合。它綜合了三范式建模和星型模型的優點，由中心表、鏈接表、附屬表三部分構成，其核心是中心表，用于存儲業務主鍵，鏈接表用于存儲業務關系，附屬表用于存儲業務描述。

Anchor建模：對DataVault模型做了進一步規范化處理，其核心思想是所有的擴展只是添加而不是修改，模型規范到6NF，基本變成K-V結構化模型。

Anchors： 類似于Data Vault的Hub，代表業務實體，且只有主鍵。

Attributes: 功能類似于DataVault的Satellite,但是它更加規范化，將其全部KV結構化，一個表只有一個Anchors的屬性描述

四、維度建模

4.1 基本概念

數據域：從業務的角度，對數據進行總體的歸類和劃分，形成的有邊界的數據范圍。面向業務分析，將業務過程或者維度進行抽象的集合。

業務過程：業務操作活動或事件，如下單、支付、退款等。業務過程一般是一個不可拆分的事務行為事件。

維度：是觀察事物的視角或角度，包含與業務過程度量事件有關的環境信息。它們用于描述與“誰、什么、哪里、何時、如何、為什么”有關的事件。有時候實體對象也可以是維度。

事實：即度量。基于某一個業務活動事件下的規格、指數及度量標準，一般是數值類型。指標一般具有明確的業務含義的名詞，如支付金額，用戶數等

維度使用主鍵標識，主鍵分兩種：代理鍵和自然鍵

① 代理鍵：無業務意義，如自增ID

② 自然鍵：具有業務意義，如商品ID

有時不清楚一個數值是事實屬性還是維度屬性，區別事實屬性還是維度屬性的小技巧：

1.是多值并參與計算

2.一個常量，一個約束或行標識 往往維度屬性

3.連續值很大可能是事實，低基數的是維度屬性

4.2 為啥選擇維度建模（優缺點）

4.2.1 優點

維度建模同時滿足（1）以商業用戶可理解的方式發布數據；（2）提供高效的查詢性能，這兩大需求。

1、便于理解

維度建模是將層次化的數據結構展開為單一層次，構建出來的數據庫結構表更加符合人的直覺、易于被人所理解，從而有利于數據的推廣使用。易于達成共識，方便查詢，不必理解業務系統規范化復雜的3NF模型。

按照事實表、維度表來構建數據倉庫、數據集市。在維度建模方法體系中，維度是描述事實的角度，如日期、地址、商品等，事實是要度量的指標，如配送員人數、完成單量等。

2、快速的響應業務

面向分析構建的，每次不需要編寫冗長的SQL，查詢大寬表，減少join，方便分析人員和業務人員（不太懂技術，不會寫復雜SQL）使用，能快速的響應業務需求。

3、標準框架

數據倉庫工具書，定義了業界廣泛理解的概念。

新員工可以快速的掌握數倉的結構，不需要熟悉具體的業務系統數據。工程師和分析師對事實、維度、粒度這些概念都比較了解，可以促進協作。

4.2.2 缺點

1、數據預處理開銷和數據冗余

由于在構建星型模式之前需要進行大量的數據預處理，因此會導致大量的數據處理工作。而且，當業務發生變化，需要重新進行維度的定義時，往往需要重新進行維度數據的預處理。而在這些預處理過程中，往往會導致大量的數據冗余。

2、一致性維度發生變化，每個主題表都要同步相關維度，對模型沖擊比較大，相比范式建模擴展性不好。

3、如果只是依靠單純的維度建模， 不能保證數據來源的一致性和準確性，而且在數據倉庫的底層，不是特別適用于維度建模的方法。

在建設數據倉庫的過程中，明細層和集市層分別采用不同的建模方法，比如：

明細層采用傳統的三范式關系模型：將業務過程描述清楚，將源數據（即業務系統）中隱含的、有歧義的概念進行清晰化。此層靈活地表達業務過程，要保證數據一致性、唯一性、正確性，以盡量少的代價與源數據保持數據同步。（面向技術人員）

集市層采用維度模型。集市層是按照業務主題、分主題構建出來的、面向特定部門或人員的數據集合，該層次的數據模型會開放給業務人員使用，進行數據挖掘及業務分析。（面向不懂技術的業務人員，需要簡單易理解）

4.3 維度建模-星型模型

星型模型VS雪花模型，根據事實表和維度表之間的關系，我們將常見的模型分為星型模型和雪花模型。星型模型更適用于做指標分析，而雪花模型更適用于做維度分析。

星型模型

雪花模型

概念	當所有的維度表都是和事實表直接相連的時候，整個圖形看上去就像是一個星星，我們稱之為星型模型。	當有多個維度表沒有直接和事實表相連，而是通過其它的維度表，間接的連接在事實表上，其圖形就像是一個雪花，因此我們稱之為雪花模型，雪花模型的優點是減少了數據冗余，在辦進行數據統計或分析的時候，需要和其他的表進行關聯
圖
查詢速度	快 有數據的冗余，很多的統計情況下，不需要和外表關聯進行查詢和數據分析，因此效率相對較高。	慢 在分析數據的時候，需要join的表?較多所以其性能并不?定?星型模型?。
冗余度	高 星型架構是?種?正規化的結構，多維數據集的每?個維度都直接與事實表相連接，不存在漸變維度，所以數據有?點的冗余。如在地域維度表中，存在國家 A 省 B 的城市 C 以及國家 A 省 B 的城市 D 兩條記錄，那么國家 A 和省 B 的信息分別存儲了兩次，即存在冗余	低 它對星型模型的維表進?步層次化，原有的各維表可能被擴展為?的事實表，形成?些局部的 "層次 " 表，去重冗余。如將地域維表分解為國家，省份，城市等維表。
可讀性	容易	差
表數量	少	多

4.4 維度建模-維度

4.4.1 維度之緩慢變化維

什么是緩慢變化維：隨著業務的發展，維度表中的屬性會隨著業務的發展而變化，但變化的頻率一般比較慢，故稱為緩慢變化維。

處理緩慢變化維的方法

?

?4.4.2 維度層次

同一類屬性存在多對一的關系，具有上卷的形式，可以設計為層次維度

1）固定深度的層次

層次已固定的維度屬性，例如右側的日期維度，日、月，季度，年。處理方案：采用列打平的方式來設計
2）可變深度的層次

層次不固定的維度屬性，

例如物流業務線的組織架構，不僅層次不一致，而且會在某一個層次中間和末尾增加一層。

處理方案：

?1.采用類似固定深度層次的方案，提前預留足夠的列打平設計。

?2.采用遞歸父子關系方式，同時保存每個葉子節點到各個層次的關系和深度值。

4.4.3 維度之常見應用

1、角色扮演維

同一個物理維度在不同的場景中，代表不同的業務含義，通常會被事實表多次引用，技術上通過創建視圖來引用。

設計案例：日期維度可以作為下單日期，可以作為支付日期，物流站點維度可以作為快遞員的組織歸屬站點，也可以作為快遞員綁點站點。

2、雜項維度

1）業務系統的一些非關鍵的標識維度，不適合單獨常見維度，可以合并到統雜項維度

2）利用雜項維度，減少維度模型的結構變更

設計案例：配送員匯總事實表，設置了雜項維度，合并【是否過風控】+【是否自然日】+【是否高峰期】等維度組成合并成一個維度，避免了維度模型的調整

3、退化維度

業務系統的標識符，沒有維度表與它連接，所以叫退化維度

4、其它維度

微型維度、多值維度、步驟維度

4.5 維度建模-事實

事實就是一種度量

4.5.1 事實的分類

?可加型事實：?? 可以按維度進行聚合，例如金額、件數

?半可加型事實：僅在特定的維度下有含義，例如賬戶余額

?不可加型事實：不具備可加性，例如比率值

4.5.2 事實表的分類

事務事實表、周期快照事實表、累計快照事實

1、事務事實：記錄的事務操作過程的事實，最原子的數據，粒度通常是每個事務記錄一條記錄，只有當天數據才會進入當天的事實表中，相當于每個分區里面都是每天的數據。

id	name	regist_time	dt
100356	張XX	2021-10-01 08:02:10	20211001
200389	李xxx	2021-10-02 11:09:20	20211002

2、周期快照事實表

具有規律性的、可預見的時間間隔來記錄事實，用來觀察在間隔周期內的度量，時間間隔如每天、每月、每年等，粒度是每個時間段一條記錄，通常比事務事實表的粒度要粗，是在事務事實表之上建立的聚集表。

id	order_cnt	user_cnt	dt
130000356	32	28	20211001
224000389	12	12	20211001

3、累積快照事實表

適合流水線過程中的已明確關鍵里程信息或已建立好的可預測的工作流，不存儲發生的每一個事務信息，累積事實表源于事務，提供了關鍵過程時間的連續場景描述，代表的是完全覆蓋一個事件或產品的生命周期時間跨度，它通常具有多個日期字段，用來記錄整個生命周期中的關鍵時間點。

例如訂單累計快照事實表會有下單日期、付款日期，發貨日期，收貨日期等時間點。

order_id	poi_id	user_id	push_time	grap_time	arrived_time	status	dt
16589600009723	300876	100356	2021-10-01 11:02:10	2021-10-01 08:02:10	9999-01-01 01:00:00	30	20211001
16200000003455	300087	200389	2021-10-01 09:10:33	2021-10-01 09:12:33	2021-10-01 10:02:09	50	20211001

事實表的比對

	事務事實表	周期快照事實表	累積快照事實表
時間特點	離散事務時間點	固定的時間間隔	時間跨度不確定
粒度	每行代表一個事務度量事件	每行代表一個周期內的實體狀態	每行代表一個實體的生命周期
日期維度	事務事件
適用場景	針對業務過程的事務分析	針對實體的狀態分析	針對實體的生命周期分析
更新策略	不更新	周期結束時定期更新	業務過程更新時同步更新

設計的注意事項

粒度：每行中的數據是一個特定級別的細節數據

存儲：應該盡量將來源于 同一個業務過程的底層度量結果存儲于一個維度模型中。

4.6 維度建模-建模步驟

業務建模=>邏輯建模=>物理建模。

4.6.1 業務建模（Conceptual Data Model）

梳理業務流程、業務概念統一、收集業務指標。

梳理業務流程，輸入：（1）閱讀BRD/MRD/PRD、技術方案、ER模型文檔深入了解業務背景知識、各個系統的數據存儲關系。（2）對相關業務人員進行調研，了解業務操作和日常工作，收集業務對數據的訴求，收集存量的報表。輸出：（1）業務流程圖；（2）業務知識文檔；（3）特殊業務場景和坑點；（4）業務指標定義。

業務建模-劃分主題

為什么劃分主題？（1）明確主題邊界，確認主題建設范圍，分而治之，達成共識。例如：物流主題負責物流承運相關流程的核心數據，派單相關的劃分到調度。（2）便于用戶從較高層次理解使用數倉，提升檢索數據效率。例如：數據地圖提供按主題引導。（3）數據倉庫管理的基礎。例如：主題分工各負其責、業務過程歸屬，指標體系歸類，元數據管理。

主題：指面向業務分析的場景下，將業務數據或分析視角數據進行重新抽象組織的集合，是從較高層次對企業業務進行劃分的方式和組織。

常見分類如下：

業務主題：交易，履約、運力? (在B3層劃分)

分析主題:?? 運力體驗、盈虧分析，活動效果分析 (在B1層劃分)

如何劃分主題？

（1）按主業務流程進行劃分

例如：提供物流履約服務就是主業務流程，根據業務上下游相關性，提供物流履約服務可以進一步拆解為銷售、定價、交易、調度、履約、結算、售后(體驗)等不同業務領域，可以對相應的業務領域構建對應的主題。

?此類主題的特點是有多個參與主體參與；例如：履約主題需要由商家、配送員、用戶等共同參與。

（2）對支撐業務流程按參與主體劃分

例如：對于物流來說，參與主體有商家、配送員、用戶等；可以對參與主體分別構建主題，用于存放與參與主體相關的支撐性業務流程。

例如：對人員招募、人員注冊、人員入職、人員在職、人員離職等業務過程構建人員運營主題。

（3）按分析的視角劃分

結合業務分析的場景進行抽象的主題，例如：人員體驗、盈虧分析，人員留存，可以對這些分析主題進行專題的建設。

4.6.2 邏輯建模（Logical Data Model）

梳理總線矩陣、劃分業務過程、確定粒度/維度/事實/維度表/事實表設計。

1、構建總線矩陣

一致性維度：在數據倉庫體系內部統一的維度關鍵字、一致的列名稱、屬性定義和屬性值

一致性事實：在數據倉庫體系內部每個度量統一的統計口徑，對應唯一的業務概念術語

業務流程是由各個具體的事務流程組成，而事務是由各個業務系統支撐的業務過程來組成的，

可以轉換成總線矩陣上的行、列最終形成維度模型

?行：代表公司組織的一個業務過程

列：業務過程的維度

2、維度表設計

確定維度、填充維度屬性、審查相關屬性。

是否應該分層，是否可以拆分或整合。

3、事實表設計

1）選擇業務過程，在主題域內根據情況會抽象新增/合并業務過程。

2）確定事實表，根據需求設計合適的事實表類型，事務事實表、周期快照事實表、累積快照事實表。

3）確定粒度，對于事務表，盡量保持最明細的粒度。

4）確定事實表的維度，盡可能包含業務過程下所有維度；考慮是否退化維度；識別剩余的維度或維度屬性是否必須； 避免出現蜈蚣表；

5）確定指標，統一同一類指標的單位。盡可能包含業務過程下所有原子指標，只選擇和業務過程相關的原子指標，統一同類指標的單位。

4.6.3 物理建模（Physical Data Model）

定義物理模型、存儲方式。

確定表名稱/表文件格式/字段名稱/字段類型及存儲路徑等

確定分區方式，一級分區/雙分區/多級分區，分區字段的選擇(時間年月日、業務字段)

確定數據初始范圍

4.7 數倉整體分層

4.7.1 分層規范

層次

定義

對各層含義的具體理解

引擎

ODS	ods接入層,主要負責各種數據源的接入	接入層由工具完成，當前主要有mysql 和流量日志數據源。該層不對外開放	hive
	ods準備區，主要完成進入dwd數據的準備工作，完成和接入層的解耦合。	由于接入層由工具完成，不受我們控制。我們需要在此基礎上做一些解耦操作(生成快照表)，同時完成進入dwd的準備工作，例如過濾壓測數據、脫敏操作等。 在建模方式上基本和源系統結構保持一致。對于部分臨時性探索分析，不一定會構建dwd，可以考慮對外開放這部分數據權限；其它場景均應該訪問dwd處理過后的數據	hive
DIM	一致性維度層，對業務過程中的維度進行統一定義，消除不一致性，是實現總線架構基礎。維度分為普通維度和衍生維度，區別在于衍生維度需要通過復雜計算(跨事實表、跨時間周期匯總）等才能產生	基于維度建模理念思想，建立整個企業的一致性維度。降低數據計算口徑和算法不統一風險。公共維度層的表通常也被稱為邏輯維度表，維度和維度邏輯表通常一一對應	hive
DWD	Data Warehouse Detail 明細數據層，作為數據倉庫最核心的區域，主要作用是通過數據加工與整合，完成對業務的抽象，對外提供簡單、準確、詳盡、一致的數據模型。	這部分主要完成以下工作： 1) 按業務主題域，采用維度建模面向業務過程構建明細事實表，完成對業務的抽象，及邏輯的封裝，屏蔽數據源變化 2）完成統一指標的定義，指標定義規范 注：DWD層的原子指標、衍生指標均不跨業務主題 3）數據質量保證	hive
DWS	Data Warehouse Summary匯總數據層，完成明細數據的匯總	主要對DWD層按照常用維度組合進行預聚合，不做任何邏輯封裝，提升查詢性能。 時間類的衍生指標也存于該層，例如最近30天接單量。 對于不可加指標(例如count distinct)，有三種實現方案，基于doris的ROLAP，基于kylin的MOLAP和基于hive的cube表，具體可以根據實際場景選擇 通常會有三類匯總表，分別是最近1天、最近N天、歷史截止當天 注：為了保證低耦合，高內聚，DWS層的聚合不跨業務主題	hive、kylin、doris
DM	為滿足具體分析場景的數據特點和易用性，而構建的面向不同垂直領域的數據集市層，例如盈虧集市、AB集市、運力集市、商集市等；	基于DWD、DWS層和DIM的數據構建，內部數據可跨B3層主題域整合，或基于商業模型進行場景化的數據加工，滿足業務、商分和產研的具體分析訴求，達成低成本、易使用的獲取和分析數據的訴求；	hive、kylin、doris
APP	Application數據應用層，面向具體應用(報表、數據服務)構建，用于滿足不同應用的個性化需求（例如行列轉換，特殊排序要求)	?面向具體應用構建，滿足性能和客戶化展示需求	kylin、doris、mysql、es

4.7.2 為什么分層（分層好處）

分層能使結構更加清晰：每一層都有它的作用和職責，我們在使用表的時候能更快速地定位和理解。

分層能使血緣關系更加清晰：高層依賴低層，不允許跨層依賴（例如：不允許明細層表依賴應用層的表）這樣我們的血緣關系會更加清晰，使用也比較方便。

方便維護數據的準確性：如果有一張表出了問題，我們能夠根據層級快速定位影響，通過字段血緣，快速識別影響范圍。當數據出現問題之后，可以不用修復所有的數據，只需要修復問題表回刷下游影響表即可。

減少重復開發：規范數據分層，開發一些通用的中間層數據，能夠減少一些重復計算，可以節省計算資源。

把復雜問題簡單化：將一個復雜的任務分解成多個步驟來完成，每一層有不同定位，比較簡單和容易理解。

屏蔽業務變動影響，屏蔽原始數據的異常。即使原始數據變動，在明細層兼容處理，不會影響模型和下游業務。

權限控制：對不同人員，選擇性開放對應的層，可以粗粒度的管理權限。

總結

以上是生活随笔為你收集整理的数仓建模（维度建模）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。