目錄
一、什麼是模組化？（為什麼模組化）
二、模型的好處
三、模組化的方法
四、次元模組化
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 為什麼分層（分層好處）
分層能使結構更加清晰：每一層都有它的作用和職責，我們在使用表的時候能更快速地定位和了解。
分層能使血緣關系更加清晰：高層依賴低層，不允許跨層依賴（例如：不允許明細層表依賴應用層的表）這樣我們的血緣關系會更加清晰，使用也比較友善。
友善維護資料的準确性：如果有一張表出了問題，我們能夠根據層級快速定位影響，通過字段血緣，快速識别影響範圍。當資料出現問題之後，可以不用修複所有的資料，隻需要修複問題表回刷下遊影響表即可。
減少重複開發：規範資料分層，開發一些通用的中間層資料，能夠減少一些重複計算，可以節省計算資源。
把複雜問題簡單化：将一個複雜的任務分解成多個步驟來完成，每一層有不同定位，比較簡單和容易了解。
屏蔽業務變動影響，屏蔽原始資料的異常。即使原始資料變動，在明細層相容處理，不會影響模型和下遊業務。
權限控制：對不同人員，選擇性開放對應的層，可以粗粒度的管理權限。