前文已經簡單介紹了什么是數據倉庫，數據倉庫事實表、維表等相關概念。在了解這些概念之后，我們要建設符合企業要求，能支持業務使用、運營分析的數據倉庫。然而在對數據建模之前，我們要對整個業務系統有深刻的理解，只有深度理解了公司內的業務，在數倉建設過程中才會抽象出公共維度的事實寬表，減少數據重復建模、提升數據質量。

一、維度建模方法論

數據倉庫建模方法論有多種：分別是維度建模、范式建模、Data Vault模型、Anchor模型。而在企業中最流行，最常用的數倉建模方式便是維度建模。

1、維度模型

按數據組織建模類型劃分可分為星型模型、雪花模型、星座模型。前文中已經介紹了相關概念，這里不再做過多贅述。

1.1、星型模型

星型模型是維表和事實表，以事實表為中心，所有維度直接關聯在事實表上，呈星型分布，即是 星型模型。

1.2、雪花模型

在星型模型的基礎上，維度表上又關聯了其他維度表，這種叫雪花模型。

雪花模型維護成本高，性能較差，一般很少使用。尤其在基于Hadoop體系構建數據倉庫時，盡可能的要減少join的操作。

1.3、星座模型

星座模型，是對星型模型的擴展延伸，多張事實表共享維度表。

2、范式模型

即實體關系（ER）模型，從全企業的高度設計一個3NF模型，用實體加關系描述的數據模型描述企業業務架構，在范式理論上符合3NF。

3、Data Vault模型

DataVault由Hub（關鍵核心業務實體）、Link（關系）、Satellite（實體屬性） 三部分組成 ，它是在ER關系模型上的衍生，同時設計的出發點也是為了實現數據的整合，并非為數據決策分析直接使用。

4、Anchor模型

高度可擴展的模型，所有的擴展只是添加而不是修改，因此它將模型規范到6NF，基本變成了K-V結構模型，基本很少使用。

二、維度建模流程

下面通過一個業務場景來簡單論述維度建模的過程，我們以微商城下單為例：一個會員購買一件商品，會生成一條記錄數據。這條記錄包含了會員的ID、商品的ID、時間，支付金額，支付方式等等諸多業務信息，我們對這條記錄進行拆分。

維度建模的步驟：

2.1、收集業務需求與數據實現

在進行數據建模之前，我們要跟業務方進行充分溝通，理解整個鏈路的業務，對底層數據要充分認識。通過溝通交流、查看數據庫數據或現有報表數據，理解他們需要的關鍵性指標，運營指標。同時數據實際情況要跟多開發組進行反復核驗，確保數據的 原子性(原生業務數據，未進行任何加工處理的數據)。

2.2、選擇業務過程

業務過程是業務活動事件，如下單，支付，退款都是業務過程，把這些過程轉換為事實表中的事實，多數事實表只記錄某一業務過程的結果。業務過程的選擇非常重要，因為業務過程定義了特定的設計目標以及對粒度、維度、事實的定義。

2.3、聲明粒度

聲明粒度是維度設計的重要步驟，粒度用于確定某一事實表中的行表示什么。在選擇維度或事實前必須聲明粒度，因為每個維度或事實必須與定義的粒度保持一致。在從給定的業務過程獲取數據時，原子粒度是最低級別的粒度。

2.4、確認維度

維度是度量的環境，用來反映業務的一類屬性。這類屬性的集合構成一個維度，也可以稱為實體對象。維度屬于一個數據域，如地理維度（其中包括國家、地區、省以及城市等級別的內容）、時間維度（其中包括年、季、月、周、日等級別的內容）。

2.5、確認事實

事實 涉及來自業務過程事件的度量，基本上都是以數據值表示。事實表作為數據倉庫維度建模的核心，緊緊圍繞著業務過程來設計，通過獲取描述業務過程的度量來表達業務過程，包含了引用的維度和與業務過程有關的度量。在設計過程中，可以選擇不同類型的事實表，它們有各自的適用場景

2.6、數據建模

選擇一種維度模型進行數據建模，使用星型建模對業務數據進行建模。

三、數倉建模規范

3.1、數倉層級劃分

數據倉庫分層

ODS原始數據層

ODS層保存所有操作數據，不對原始數據做任何處理。在業務系統和數據倉庫之間形成一個隔離，源系統數據結構的變化不影響其他數據分層。減輕業務系統被反復抽取的壓力，由ODS統一進行抽取和分發。記住ODS層數據要保留數據的原始性。

處理原則：

• 根據源業務系統表的情況以增量或全量方式抽取數據；
• ODS層以流水表和快照表為主，按日期對數據進行分區保存，不使用拉鏈表；
• ODS層的數據不做清洗和轉換，數據的表結構和數據粒度與原業務系統保持一致。

DWD數據明細層

DWD層的數據是經由ODS層數據經過清洗、轉換后的明細數據，滿足對標準化數據需求。如對NULL值處理，對數據字典解析，對日期格式轉換，字段合并、臟數據處理等。

處理原則：

• 數據結構與ODS層一致，但可以對表結構進行裁剪和匯總等操作；
• 對數據做清洗、轉換；
• DWD層的數據不一定要永久保存，具體保存周期視業務情況而定。

DWS數據匯總層

DWS層數據 按主題對數據進行抽象、歸類，提供業務系統細節數據的長期沉淀。這一層是一些匯總后的寬表，是根據DWD層數據按照各種維度或多種維度組合，把需要查詢的一些事實字段進行匯總統計。可以滿足一些特定查詢、數據挖掘應用，面向業務層面，根據需求進行匯總。

處理原則：

• 面向全局、數據整合；
• 存放最全的歷史數據，業務發生變化時易于擴展，適應復雜的實際業務情況；
• 盡量減少數據訪問時的計算量，優化表的關聯。維度建模，星形模型；
• 事實拉寬，度量預先計算， 基本都是快照表。反規范化，有數據冗余。

ADS數據明細層

ADS應用層是根據業務需要，由DWD、DWS數據統計而出的結果，可以直接提供查詢展現，或導入至Oracle等關系型數據庫中使用。這一層的數據會面向特定的業務部門，不同的業務部門使用不同的數據，支持數據挖掘。

處理原則：

• 形式各式，主要按不同的業務需求來處理；
• 保持數據量小，定時刷新數據；
• 數據同步到不同的關系型數據庫或hbase等其他數據庫中。
• 提供最終數據，來滿足業務人員、數據分析人員的數據需求。

數據倉庫分層模式作用

3.1.1、數據結構化更清晰：對于不同層級的數據，他們作用域不相同，每一個數據分層都有它的作用域，這樣我們在使用表的時候能更方便地定位和理解。

3.1.2、數據血緣追蹤：提供給外界使用的是一張業務表，但是這張業務表可能來源很多張表。如果有一張來源表出問題了，我們可以快速準確的定位到問題，并清楚每張表的作用范圍。

3.1.3、減少重復開發：數據分層規范化，開發一些通用的中間層數據，能夠減少重復計算，提高單張業務表的使用率。

3.1.4、簡化復雜的問題：把一個復雜的業務分成多個步驟實現，每一層只處理單一的步驟，比較簡單和容易理解。而且便于維護數據的準確性，當數據出現問題之后，可以不用修復所有的數據，只需要從有問題的步驟開始修復。有點類似Spark RDD的容錯機制。

3.1.5、減少業務的影響：業務可能會經常變化，這樣做就不必改一次業務就需要重新接入數據。

3.2、數據域劃分和命名

數據域的劃分至關重要，在數據建模過程中，往往需要我們根據業務劃分數據并約定命名。建議使用業務名稱結合數據層次約定相關命名的英文縮寫，這樣劃分層次更清晰，見名即可知意。

3.2.1、數據域劃分

按業務劃分：

命名時按主要的業務劃分，以指導物理模型的劃分原則、命名原則及使用。如公司有多條業務線，可以按照不同業務線進行劃分。

按數據域劃分：

命名時按照數據域進行劃分，以便有效地對數據進行管理。例如，交易 數據的英文縮寫可定義為“trd”，會員數據的英文縮寫可以定義為 mbr。

按業務過程劃分：

當一個數據域由多個業務過程組成時，命名時可以按業務流程劃分。業務過程是從數據分析角度看客觀存在的或者抽象的業務行為動作。例如，交易數據域中的“退款”這個業務過程的英文縮寫可約定命名為“rfd_ent”。

3.2.2、任務命名

針對數據域任務命名一定要按照規范執行，這里以作者工作中常使用的命名方式為例，當然每個人習慣不同，命名可能有所不同。

如：ods_jnxx_mbr_intgl_di
ods：代表ods層
jnxx：公司名稱英文縮寫
mbr：會員 的縮寫 mbr，表示會員業務
intgl：會員積分 英文的縮寫，會員積分相關任務
di：代表天增量。


d：代表日全量同步
ri：代表小時增量同步
m：代表月
等等，這里就不一一舉例了。