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

一、維度建模方法論

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

1、維度模型

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

1.1、星型模型

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

1.2、雪花模型

在星型模型的基礎(chǔ)上，維度表上又關(guān)聯(lián)了其他維度表，這種叫雪花模型。

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

1.3、星座模型

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

2、范式模型

即實體關(guān)系（ER）模型，從全企業(yè)的高度設(shè)計一個3NF模型，用實體加關(guān)系描述的數(shù)據(jù)模型描述企業(yè)業(yè)務(wù)架構(gòu)，在范式理論上符合3NF。

3、Data Vault模型

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

4、Anchor模型

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

二、維度建模流程

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

維度建模的步驟：

2.1、收集業(yè)務(wù)需求與數(shù)據(jù)實現(xiàn)

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

2.2、選擇業(yè)務(wù)過程

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

2.3、聲明粒度

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

2.4、確認(rèn)維度

維度是度量的環(huán)境，用來反映業(yè)務(wù)的一類屬性。這類屬性的集合構(gòu)成一個維度，也可以稱為實體對象。維度屬于一個數(shù)據(jù)域，如地理維度（其中包括國家、地區(qū)、省以及城市等級別的內(nèi)容）、時間維度（其中包括年、季、月、周、日等級別的內(nèi)容）。

2.5、確認(rèn)事實

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

2.6、數(shù)據(jù)建模

選擇一種維度模型進行數(shù)據(jù)建模，使用星型建模對業(yè)務(wù)數(shù)據(jù)進行建模。

三、數(shù)倉建模規(guī)范

3.1、數(shù)倉層級劃分

數(shù)據(jù)倉庫分層

ODS原始數(shù)據(jù)層

ODS層保存所有操作數(shù)據(jù)，不對原始數(shù)據(jù)做任何處理。在業(yè)務(wù)系統(tǒng)和數(shù)據(jù)倉庫之間形成一個隔離，源系統(tǒng)數(shù)據(jù)結(jié)構(gòu)的變化不影響其他數(shù)據(jù)分層。減輕業(yè)務(wù)系統(tǒng)被反復(fù)抽取的壓力，由ODS統(tǒng)一進行抽取和分發(fā)。記住ODS層數(shù)據(jù)要保留數(shù)據(jù)的原始性。

處理原則：

• 根據(jù)源業(yè)務(wù)系統(tǒng)表的情況以增量或全量方式抽取數(shù)據(jù)；
• ODS層以流水表和快照表為主，按日期對數(shù)據(jù)進行分區(qū)保存，不使用拉鏈表；
• ODS層的數(shù)據(jù)不做清洗和轉(zhuǎn)換，數(shù)據(jù)的表結(jié)構(gòu)和數(shù)據(jù)粒度與原業(yè)務(wù)系統(tǒng)保持一致。

DWD數(shù)據(jù)明細(xì)層

DWD層的數(shù)據(jù)是經(jīng)由ODS層數(shù)據(jù)經(jīng)過清洗、轉(zhuǎn)換后的明細(xì)數(shù)據(jù)，滿足對標(biāo)準(zhǔn)化數(shù)據(jù)需求。如對NULL值處理，對數(shù)據(jù)字典解析，對日期格式轉(zhuǎn)換，字段合并、臟數(shù)據(jù)處理等。

處理原則：

• 數(shù)據(jù)結(jié)構(gòu)與ODS層一致，但可以對表結(jié)構(gòu)進行裁剪和匯總等操作；
• 對數(shù)據(jù)做清洗、轉(zhuǎn)換；
• DWD層的數(shù)據(jù)不一定要永久保存，具體保存周期視業(yè)務(wù)情況而定。

DWS數(shù)據(jù)匯總層

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

處理原則：

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

ADS數(shù)據(jù)明細(xì)層

ADS應(yīng)用層是根據(jù)業(yè)務(wù)需要，由DWD、DWS數(shù)據(jù)統(tǒng)計而出的結(jié)果，可以直接提供查詢展現(xiàn)，或?qū)胫罯racle等關(guān)系型數(shù)據(jù)庫中使用。這一層的數(shù)據(jù)會面向特定的業(yè)務(wù)部門，不同的業(yè)務(wù)部門使用不同的數(shù)據(jù)，支持?jǐn)?shù)據(jù)挖掘。

處理原則：

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

數(shù)據(jù)倉庫分層模式作用

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

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

3.1.3、減少重復(fù)開發(fā)：數(shù)據(jù)分層規(guī)范化，開發(fā)一些通用的中間層數(shù)據(jù)，能夠減少重復(fù)計算，提高單張業(yè)務(wù)表的使用率。

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

3.1.5、減少業(yè)務(wù)的影響：業(yè)務(wù)可能會經(jīng)常變化，這樣做就不必改一次業(yè)務(wù)就需要重新接入數(shù)據(jù)。

3.2、數(shù)據(jù)域劃分和命名

數(shù)據(jù)域的劃分至關(guān)重要，在數(shù)據(jù)建模過程中，往往需要我們根據(jù)業(yè)務(wù)劃分?jǐn)?shù)據(jù)并約定命名。建議使用業(yè)務(wù)名稱結(jié)合數(shù)據(jù)層次約定相關(guān)命名的英文縮寫，這樣劃分層次更清晰，見名即可知意。

3.2.1、數(shù)據(jù)域劃分

按業(yè)務(wù)劃分：

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

按數(shù)據(jù)域劃分：

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

按業(yè)務(wù)過程劃分：

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

3.2.2、任務(wù)命名

針對數(shù)據(jù)域任務(wù)命名一定要按照規(guī)范執(zhí)行，這里以作者工作中常使用的命名方式為例，當(dāng)然每個人習(xí)慣不同，命名可能有所不同。

如：ods_jnxx_mbr_intgl_di
ods：代表ods層
jnxx：公司名稱英文縮寫
mbr：會員 的縮寫 mbr，表示會員業(yè)務(wù)
intgl：會員積分 英文的縮寫，會員積分相關(guān)任務(wù)
di：代表天增量。


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