通透！數(shù)據(jù)倉庫領域常見建模方法及實例演示

一、為什么需要數(shù)據(jù)建模？

在開始今天的話題之前，我們不妨思考下，到底為什么需要進行數(shù)據(jù)建模？

隨著從IT時代到DT時代的跨越，數(shù)據(jù)開始出現(xiàn)爆發(fā)式的增長，這當中產(chǎn)生的價值也是不言而喻。如何將這些數(shù)據(jù)進行有序、有結(jié)構(gòu)地分類組織存儲，是我們所有數(shù)據(jù)從業(yè)者都要面臨的一個挑戰(zhàn)。

如果把數(shù)據(jù)看作圖書館里的書，我們希望看到它們在書架上分門別類地放置，而不是亂糟糟的堆砌在一起。

大數(shù)據(jù)的數(shù)倉建模正是通過建模的方法，更好的組織、存儲數(shù)據(jù)，以便在性能、成本、效率和數(shù)據(jù)質(zhì)量之間找到最佳平衡點，一般我們會從以下面四點考慮：

• 性能：能夠快速查詢所需的數(shù)據(jù)，減少數(shù)據(jù)I/O的吞吐。
• 成本：減少不必要的數(shù)據(jù)冗余，實現(xiàn)計算結(jié)果的復用，降低大數(shù)據(jù)系統(tǒng)中的存儲成本和計算成本。
• 效率：改善用使用數(shù)據(jù)的體驗，提高使用效率。
• 質(zhì)量：改善數(shù)據(jù)統(tǒng)計口徑的不一致性，減少數(shù)據(jù)計算錯誤的可能性，提供高質(zhì)量的、一致的數(shù)據(jù)訪問平臺。

因此，毋庸置疑，大數(shù)據(jù)系統(tǒng)、數(shù)據(jù)平臺都需要數(shù)據(jù)模型方法來幫助更好的組織和存儲數(shù)據(jù)，數(shù)據(jù)建模的工作，也正是圍繞上述四個指標取得最佳的平衡而努力。

二、從 OLTP 和 OLAP 系統(tǒng)的區(qū)別看模型方法論的選擇

OLTP系統(tǒng)通常面向的主要數(shù)據(jù)操作是隨機讀寫，主要采用3NF的實體關系模型存儲數(shù)據(jù)，從而在事務處理中解決數(shù)據(jù)的冗余和一致性問題。

OLAP系統(tǒng)面向的主要數(shù)據(jù)操作是批量讀寫，事務處理中的一致性不是OLAP所關注的，其主要關注數(shù)據(jù)的整合，以及在一次性的復雜大數(shù)據(jù)查詢和處理的性能，因此它需要采用不同的建模方法，例如維度建模。

如果大家想進一步了解 OLAP系統(tǒng)，可以學習這篇文章：關于OLAP數(shù)倉，這大概是史上最全面的總結(jié)！

三、典型的數(shù)據(jù)倉庫建模方法論

數(shù)據(jù)倉庫本質(zhì)是從數(shù)據(jù)庫衍生出來的，所以數(shù)據(jù)倉庫的建模也是不斷衍生發(fā)展的。

從最早的借鑒關系型數(shù)據(jù)庫理論的范式建模，到逐漸提出維度建模等等，越往后建模的要求越高，越需滿足3NF、4NF等。但是對于數(shù)據(jù)倉庫來說，目前主流還是維度建模，會夾雜著范式建模。

數(shù)據(jù)倉庫建模方法論可分為：E-R模型、維度模型、Data Vault模型、Anchor模型。

（1）E-R模型

將事物抽象為“實體”、“屬性”、“關系”來表示數(shù)據(jù)關聯(lián)和事物描述，這種對數(shù)據(jù)的抽象建模通常被稱為E-R實體關系模型。

數(shù)據(jù)倉庫之父 Bill Inmon 提出的建模方法，從全企業(yè)的高度設計一個3NF模型，用實體關系（Entity Relationship）模型來描述企業(yè)業(yè)務，滿足3NF。

數(shù)據(jù)倉庫的3NF與OLTP系統(tǒng)中的3NF的區(qū)別在于，它是站在企業(yè)角度面向主題的抽象，而不是針對某個具體的業(yè)務流程。

采用 E-R模型建設數(shù)據(jù)倉庫模型的出發(fā)點是整合數(shù)據(jù)，對各個系統(tǒng)的數(shù)據(jù)以整個企業(yè)角度按主題進行相似的組合和合并，并進行一致性處理，為數(shù)據(jù)分析決策服務，但是并不能直接用于分析決策。

作為一種標準的數(shù)據(jù)建模方案，它的實施周期非常長，一致性和擴展性比較好，能經(jīng)得起時間的考驗。但是隨著企業(yè)數(shù)據(jù)的高速增長、復雜化，數(shù)倉如果全部使用E-R模型進行建模就顯得越來越不適合現(xiàn)代化復雜、多變的業(yè)務組織，因此一般只有在數(shù)倉底層ODS、DWD會采用E-R關系模型進行設計。

E-R建模步驟分為三個階段：

• 高層模型：一個高度抽象的模型，描述主要的主題以及主題間的關系，用于描述企業(yè)的業(yè)務總體概況。
• 中層模型：在高層模型的基礎上，細化主題的數(shù)據(jù)項。
• 物理模型（底層模型）：在中層模型的基礎上，考慮物理存儲，同時基于性能和平臺特點進行物理屬性的設計，也可能做一些表的合并、分區(qū)的設計等。

E-R模型在實踐中最典型的代表是 Teradata 公司基于金融業(yè)務發(fā)布的 FS-LDM (Financial Services Logical Data Model ），它通過對金融業(yè)務的高度抽象和總結(jié)，將金融業(yè)務劃分為10大主題，企業(yè)基于此模型適當調(diào)整和擴展就能快速實施落地。

（2）維度模型

維度模型是數(shù)據(jù)倉庫領域 Ralph Kimball 大師倡導的，是數(shù)據(jù)倉庫工程領域最流行的數(shù)倉建模經(jīng)典。

維度建模以分析決策的需求出發(fā)構(gòu)建模型，構(gòu)建的數(shù)據(jù)模型為分析需求服務，因此它重點解決用戶如何更快速完成分析需求，同時還有較好的大規(guī)模復雜查詢的響應性能。

其中典型的代表就是使用星型模型，以及在一些特殊場景下使用的雪花模型。

其設計主要分為以下幾個步驟：

1. 選擇需要進行分析決策的業(yè)務過程。業(yè)務過程可以是單個業(yè)務事件，比如交易的支付、退款等；也可以是某個事件的狀態(tài)，比如當前賬戶的余額；還有就是一系列相關業(yè)務事件組成的業(yè)務流程，具體需要我們分析的是某些事件發(fā)生的情況，還是當前狀態(tài)，或是事件流轉(zhuǎn)效率。
2. 選擇粒度。在事件分析中，我們要預判所有分析需要細分的程度，從而決定選擇的粒度。粒度是維度的一個組合。
3. 識別維表。選擇好粒度之后，就需要基于這個粒度來設計維表，包括維度屬性，用于分析時進行分組和篩選。
4. 選擇事實。確定分析需要衡量的指標。

在 Ralph Kimball 提出對數(shù)據(jù)倉庫維度建模，我們將數(shù)據(jù)倉庫中的表劃分為事實表、維度表兩種類型。

針對維度建模中事實表和維度表的設計，之前有詳細介紹過，感興趣的同學可以看：維度建模技術實踐——深入事實表 、維度建模的靈魂所在——維度表設計。

在這里，我就以常見的電商場景為例：在一次購買的事件中，涉及主體包括客戶、商品、商家，產(chǎn)生的可度量值會包括商品數(shù)量、金額、件數(shù)等。

事實表根據(jù)粒度的角色劃分不同，可分為事務事實表、周期快照事實表、累積快照事實表等。

1. 事務事實表：用于承載事務數(shù)據(jù)，任何類型的事件都可以被理解為一種事務，比如商家在交易過程中的常見訂單、買家付款，物流過程中的攬貨、發(fā)貨、簽收，退款中的申請退款。
2. 周期快照事實表：快照事實表以預定的間隔采樣狀態(tài)度量，比如自然年至今或者歷史至今的下單金額、支付金額、支付買家數(shù)、支付商品件數(shù)等等狀態(tài)度量。
3. 累計快照事實表：數(shù)據(jù)不斷更新，選取多業(yè)務過程日期。用來記錄具有時間跨度的業(yè)務處理過程的整個過程的信息，每個生命周期一行，通常這類事實表比較少見。

我們繼續(xù)就上述的電商場景，聊聊在維表設計時需要關注的一些東西：

1. 緩慢變化維度：例如會員表的手機號、地址、生日等屬性。
2. 退化維度 ：訂貨單表的訂單編號、物流表的物流編號等。
3. 雪花維度：滿足第三范式的維度關系結(jié)構(gòu)。
4. 非規(guī)范化扁平維度：商品維表中產(chǎn)品、品牌、類目、品類等。
5. 多層次維度：地區(qū)維度的省、市、區(qū)縣，商品的類目層級。
6. 角色維度：日期維度在物流中扮演發(fā)貨日期、送貨日期、收獲日期等不同角色。

接下來就是針對維度建模按照數(shù)據(jù)的組織類型，可以劃分為星型模型、雪花模型、星座模型。

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

2. 雪花模型：在星型模型的基礎上，維度表上又關聯(lián)了其他維度表。這種模型維護成本高，性能方面會差一些。

3. 星座模型：是對星型模型的擴展延伸，多張事實表共享維度表。實際上數(shù)倉模型建設后期，大部分維度建模都是星座模型。

簡單總結(jié)下就是：

1. 星型模型和雪花模型主要區(qū)別就是對維度表的拆分。
2. 對于雪花模型，維度表的設計更加規(guī)范，一般符合3NF，有效降低數(shù)據(jù)冗余，維度表之間不會相互關聯(lián)。
3. 星型模型，一般采用降維的操作，反規(guī)范化，不符合3NF，通過利用冗余來避免模型過于復雜，提高易用性和分析效率，效率相對較高。
   
   

（3）DataVault 模型

Data Vault 是 Dan Linstedt 發(fā)起創(chuàng)建的一種模型，它是 E-R 模型的衍生，其設計的出發(fā)點也是為了實現(xiàn)數(shù)據(jù)的整合，但不能直接用于數(shù)據(jù)分析決策。

它強調(diào)建立一個可審計的基礎數(shù)據(jù)層，也就是強調(diào)數(shù)據(jù)的歷史性、可追溯性和原子性，而不要求對數(shù)據(jù)進行過度的一致性處理和整合。

同時它基于主題概念將企業(yè)數(shù)據(jù)進行結(jié)構(gòu)化組織，并引入了更進一步的范式處理來優(yōu)化模型，以應對源系統(tǒng)變更的擴展性。Data Vault 模型由以下幾部分組成：

1. Hub - 中心表：是企業(yè)的核心業(yè)務實體，由實體 Key、數(shù)倉序列代理鍵、裝載時間、數(shù)據(jù)來源組成，不包含非鍵值以外的業(yè)務數(shù)據(jù)屬性本身。
2. Link - 鏈接表：代表 Hub 之間的關系。這里與 ER 模型最大的區(qū)別是將關系作為一個獨立的單元抽象，可以提升模型的擴展性。它可以直接描述 1:1、1:2和n:n的關系，而不需要做任何變更。它由 Hub的代理鍵、裝載時間、數(shù)據(jù)來源組成。
3. Satellite - 衛(wèi)星表：數(shù)倉中數(shù)據(jù)的主要載體，包括對鏈接表、中心表的數(shù)據(jù)描述、數(shù)值度量等信息。

Data Vault 模型比 E-R 模型更容易設計和產(chǎn)出，它的 ETL 加工可實現(xiàn)配置化。我們可以將 Hub 想象成人的骨架，那么 Link 就是連接骨架的韌帶，而 SateIIite 就是骨架上面的血肉。

（4）Anchor 模型

Anchor 對 Data Vault 模型做了進一步的規(guī)范化處理，它的核心思想是所有的擴展只是添加而不是修改，因此將模型規(guī)范到6NF，基本變成了 k-v 結(jié)構(gòu)化模型。

1. Anchors ：類似于 Data Vault 的 Hub ，代表業(yè)務實體，且只有主鍵。
2. Attributes ：功能類似于 Data Vault 的 Satellite，但是它更加規(guī)范化，將其全部 k-v 結(jié)構(gòu)化， 一個表只有一個 Anchors 的屬性描述。
3. Ties ：就是 Anchors 之間的關系，單獨用表來描述，類似于 Data Vault 的 Link ，可以提升整體模型關系的擴展能力。
4. Knots ：代表那些可能會在 Anchors 中公用的屬性的提煉，比如性別、狀態(tài)等這種枚舉類型且被公用的屬性。

由于過度規(guī)范化，使用中牽涉到太多的Join操作，這里我們就僅作了解。

四、總結(jié)

針對以上四種基本的建模方法，目前主流的是：E-R模型、維度模型。

E-R模型通常用于OLTP數(shù)據(jù)庫建模，應用到構(gòu)建數(shù)倉時就更偏向于數(shù)據(jù)整合，站在企業(yè)整體考慮，將各個系統(tǒng)的數(shù)據(jù)按相似性一致性、合并處理，為數(shù)據(jù)分析、決策服務，但并不便于直接用來支持分析。

維度建模是面向分析場景而生，針對分析場景構(gòu)建數(shù)倉模型；重點關注快速、靈活的解決分析需求，同時能夠提供大規(guī)模數(shù)據(jù)的快速響應性能。針對性強，主要應用于數(shù)據(jù)倉庫構(gòu)建和OLAP引擎低層數(shù)據(jù)模型。

數(shù)據(jù)倉庫模型的設計是靈活的，不會局限于某一種模型，需要以實際的需求場景為導向，需要兼顧靈活性、可擴展性以及技術可靠性及實現(xiàn)成本。

(歡迎大家加入數(shù)據(jù)工匠知識星球獲取更多資訊。)

了解更多精彩內(nèi)容

長按，識別二維碼，關注我們吧！

數(shù)據(jù)工匠俱樂部

微信號：zgsjgjjlb

專注數(shù)據(jù)治理，推動大數(shù)據(jù)發(fā)展。