詳解數(shù)據(jù)倉庫建設體系

詳解數(shù)據(jù)倉庫建設體系

詳解數(shù)據(jù)倉庫建設體系..............................................1

一、數(shù)據(jù)倉庫的基本概念............................................3

1.1數(shù)據(jù)倉庫概念：...........................................3

1.2數(shù)據(jù)倉庫基本特征：......................................3

1.2.1面向主題...........................................3

1.2.2集成性.............................................3

1.2.3非易失性（不可更新性）.........................4

1.2.4時變性.............................................5

1.3數(shù)據(jù)倉庫與數(shù)據(jù)庫的區(qū)別..............................5

1.4數(shù)據(jù)倉庫分層架構........................................7

1.5數(shù)據(jù)倉庫元數(shù)據(jù)的管理..................................8

二、數(shù)倉建模方式..................................................9

2.1范式建模法............................................10

2.2維度建模法............................................11

2.3實體建模法............................................12

三、維度建模......................................................12

3.1.維度建模中表的類型.................................13

3.1.1事實表............................................13

3.1.2維度表.............................................14

3.2維度建模三種模式......................................15

3.2.1星型模式...........................................15

3.2.2雪花模式...........................................16

3.2.3星座模式...........................................16

3.3維度建模過程...........................................17

3.3.1選擇業(yè)務過程......................................18

3.3.2聲明粒度...........................................19

3.3.3確認維度...........................................19

3.3.4確認事實..........................................19

四、實際業(yè)務中數(shù)倉分層..........................................20

4.1數(shù)據(jù)源層ODS...........................................21

4.2數(shù)據(jù)明細層DW...........................................22

4.3數(shù)據(jù)輕度匯總層DM......................................23

4.4數(shù)據(jù)應用層APP..........................................23

五、小結.........................................................24

一、數(shù)據(jù)倉庫的基本概念

1.1數(shù)據(jù)倉庫概念：

英文名稱為DataWarehouse,可簡寫為DW或DWH。數(shù)據(jù)倉

庫的目的是構建面向分析的集成化數(shù)據(jù)環(huán)境，為企業(yè)提供決策

支持(DecisionSupport)。它出于分析性報告和決策支持目

的而創(chuàng)建。

數(shù)據(jù)倉庫本身并不“生產(chǎn)”任何數(shù)據(jù)，同時自身也不需要“消

費”任何的數(shù)據(jù)，數(shù)據(jù)來源于外部，并且開放給外部應用，這

也是為什么叫“倉庫”，而不叫“工廠”的原因。

1.2數(shù)據(jù)倉庫基本特征：

數(shù)據(jù)倉庫是面向主題的、集成的、非易失的和時變的數(shù)據(jù)

集合，用以支持管理決策。

1.2.1面向主題

傳統(tǒng)數(shù)據(jù)庫中，最大的特點是面向應用進行數(shù)據(jù)的組織，

各個業(yè)務系統(tǒng)可能是相互分離的。而數(shù)據(jù)倉庫則是面向主題

的。主題是一個抽象的概念，是較高層次上企業(yè)信息系統(tǒng)中的

數(shù)據(jù)綜合、歸類并進行分析利用的抽象。在邏輯意義上，它是

對應企業(yè)中某一宏觀分析領域所涉及的分析對象。

1.2.2集成性

通過對分散、獨立、異構的數(shù)據(jù)庫數(shù)據(jù)進行抽取、清理、

轉換和匯總便得到了數(shù)據(jù)倉庫的數(shù)據(jù)，這樣保證了數(shù)據(jù)倉庫內(nèi)

的數(shù)據(jù)關于整個企業(yè)的一致性。

數(shù)據(jù)倉庫中的綜合數(shù)據(jù)不能從原有的數(shù)據(jù)庫系統(tǒng)直接得

到。因此在數(shù)據(jù)進入數(shù)據(jù)倉庫之前，必然要經(jīng)過統(tǒng)一與綜合，

這一步是數(shù)據(jù)倉庫建設中最關鍵、最復雜的一步，所要完成的

工作有：

?要統(tǒng)一源數(shù)據(jù)中所有矛盾之處，如字段的同名異義、異名

同義、單位不統(tǒng)一、字長不一致，等等。

?進行數(shù)據(jù)綜合和計算。數(shù)據(jù)倉庫中的數(shù)據(jù)綜合工作可以在

從原有數(shù)據(jù)庫抽取數(shù)據(jù)時生成，但許多是在數(shù)據(jù)倉庫內(nèi)部

生成的，即進入數(shù)據(jù)倉庫以后進行綜合生成的。

下圖說明一個保險公司綜合數(shù)據(jù)的簡單處理過程，其中數(shù)

據(jù)倉庫中與“保險”主題有關的數(shù)據(jù)來自于多個不同的操作型

系統(tǒng)。這些系統(tǒng)內(nèi)部數(shù)據(jù)的命名可能不同，數(shù)據(jù)格式也可能不

同。把不同來源的數(shù)據(jù)存儲到數(shù)據(jù)倉庫之前，需要去除這些不

一致。

業(yè)

務

系

統(tǒng)主題=保險

數(shù)倉主題

1.2.3非易失性（不可更新性）

數(shù)據(jù)倉庫的數(shù)據(jù)反映的是一段相當長的時間內(nèi)歷史數(shù)據(jù)的

內(nèi)容，是不同時點的數(shù)據(jù)庫快照的集合，以及基于這些快照進

行統(tǒng)計、綜合和重組的導出數(shù)據(jù)。

數(shù)據(jù)非易失性主要是針對應用而言。數(shù)據(jù)倉庫的用戶對數(shù)

據(jù)的操作大多是數(shù)據(jù)查詢或比較復雜的挖掘，一旦數(shù)據(jù)進入數(shù)

據(jù)倉庫以后，一般情況下被較長時間保留。數(shù)據(jù)倉庫中一般有

大量的查詢操作，但修改和刪除操作很少。因此，數(shù)據(jù)經(jīng)加工

和集成進入數(shù)據(jù)倉庫后是極少更新的，通常只需要定期的加載

和更新。

1.2.4時變性

數(shù)據(jù)倉庫包含各種粒度的歷史數(shù)據(jù)。數(shù)據(jù)倉庫中的數(shù)據(jù)可

能與某個特定日期、星期、月份、季度或者年份有關。數(shù)據(jù)倉

庫的目的是通過分析企業(yè)過去一段時間業(yè)務的經(jīng)營狀況，挖掘

其中隱藏的模式。雖然數(shù)據(jù)倉庫的用戶不能修改數(shù)據(jù)，但并不

是說數(shù)據(jù)倉庫的數(shù)據(jù)是永遠不變的。分析的結果只能反映過去

的情況，當業(yè)務變化后，挖掘出的模式會失去時效性。因此數(shù)

據(jù)倉庫的數(shù)據(jù)需要更新，以適應決策的需要。從這個角度講，

數(shù)據(jù)倉庫建設是一個項目，更是一個過程。數(shù)據(jù)倉庫的數(shù)據(jù)隨

時間的變化表現(xiàn)在以下幾個方面：

(1)數(shù)據(jù)倉庫的數(shù)據(jù)時限一般要遠遠長于操作型數(shù)據(jù)的

數(shù)據(jù)時限。

(2)操作型系統(tǒng)存儲的是當前數(shù)據(jù)，而數(shù)據(jù)倉庫中的數(shù)

據(jù)是歷史數(shù)據(jù)。

(3)數(shù)據(jù)倉庫中的數(shù)據(jù)是按照時間順序追加的，它們都

帶有時間屬性。

1.3數(shù)據(jù)倉庫與數(shù)據(jù)庫的區(qū)別

數(shù)據(jù)庫與數(shù)據(jù)倉庫的區(qū)別實際講的是OLTP與OLAP的

區(qū)別。

操作型處理，叫聯(lián)機事務處理OLTP(On-Line

TransactionProcessing,),也可以稱面向交易的處理系

統(tǒng)，它是針對具體業(yè)務在數(shù)據(jù)庫聯(lián)機的日常操作，通常對少數(shù)

記錄進行查詢、修改。用戶較為關心操作的響應時間、數(shù)據(jù)的

安全性、完整性和并發(fā)支持的用戶數(shù)等問題。傳統(tǒng)的數(shù)據(jù)庫系

統(tǒng)作為數(shù)據(jù)管理的主要手段，主要用于操作型處理，像

Mysql,Orac1e等關系型數(shù)據(jù)庫一般屬于OLTP。

分析型處理，叫聯(lián)機分析處理OLAP(On-LineAnalytical

Processing)一般針對某些主題的歷史數(shù)據(jù)進行分析，支持管

理決策。

首先要明白，數(shù)據(jù)倉庫的出現(xiàn)，并不是要取代數(shù)據(jù)庫。數(shù)

據(jù)庫是面向事務的設計，數(shù)據(jù)倉庫是面向主題設計的。數(shù)據(jù)庫

一般存儲業(yè)務數(shù)據(jù)，數(shù)據(jù)倉庫存儲的一般是歷史數(shù)據(jù)。

數(shù)據(jù)庫設計是盡量避免冗余，一般針對某一業(yè)務應用進行

設計，比如一張簡單的User表，記錄用戶名、密碼等簡單數(shù)據(jù)

即可，符合業(yè)務應用，但是不符合分析。數(shù)據(jù)倉庫在設計是有

意引入冗余，依照分析需求，分析維度、分析指標進行設計。

數(shù)據(jù)庫是為捕獲數(shù)據(jù)而設計，數(shù)據(jù)倉庫是為分析數(shù)據(jù)而設

計。

以銀行業(yè)務為例。數(shù)據(jù)庫是事務系統(tǒng)的數(shù)據(jù)平臺，客戶在

銀行做的每筆交易都會寫入數(shù)據(jù)庫，被記錄下來，這里，可以

簡單地理解為用數(shù)據(jù)庫記賬。數(shù)據(jù)倉庫是分析系統(tǒng)的數(shù)據(jù)平

臺，它從事務系統(tǒng)獲取數(shù)據(jù)，并做匯總、加工，為決策者提供

決策的依據(jù)。比如，某銀行某分行一個月發(fā)生多少交易，該分

行當前存款余額是多少。如果存款又多，消費交易又多，那么

該地區(qū)就有必要設立ATM了。

顯然，銀行的交易量是巨大的，通常以百萬甚至千萬次來

計算。事務系統(tǒng)是實時的，這就要求時效性，客戶存一筆錢需

要幾十秒是無法忍受的，這就要求數(shù)據(jù)庫只能存儲很短一段時

間的數(shù)據(jù)。而分析系統(tǒng)是事后的，它要提供關注時間段內(nèi)所有

的有效數(shù)據(jù)。這些數(shù)據(jù)是海量的，匯總計算起來也要慢一些，

但是，只要能夠提供有效的分析數(shù)據(jù)就達到目的了。

數(shù)據(jù)倉庫，是在數(shù)據(jù)庫已經(jīng)大量存在的情況下，為了進一

步挖掘數(shù)據(jù)資源、為了決策需要而產(chǎn)生的，它決不是所謂的

“大型數(shù)據(jù)庫”。

1.4數(shù)據(jù)倉庫分層架構

按照數(shù)據(jù)流入流出的過程，數(shù)據(jù)倉庫架構可分為：源數(shù)

據(jù)、數(shù)據(jù)倉庫、數(shù)據(jù)應用

數(shù)據(jù)應用報表展示即席查詢數(shù)據(jù)分析數(shù)據(jù)挖掘

元

數(shù)

聚合數(shù)據(jù)多維數(shù)據(jù)模型據(jù)

管

數(shù)據(jù)倉庫理

源數(shù)據(jù)

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

數(shù)據(jù)倉庫的數(shù)據(jù)來源于不同的源數(shù)據(jù)，并提供多樣的數(shù)據(jù)

應用，數(shù)據(jù)自下而上流入數(shù)據(jù)倉庫后向上層開放應用，而數(shù)據(jù)

倉庫只是中間集成化數(shù)據(jù)管理的一個平臺。

源數(shù)據(jù)：此層數(shù)據(jù)無任何更改，直接沿用外圍系統(tǒng)數(shù)據(jù)結構和

數(shù)據(jù)，不對外開放；為臨時存儲層，是接口數(shù)據(jù)的臨時存儲區(qū)

域，為后一步的數(shù)據(jù)處理做準備。

數(shù)據(jù)倉庫：也稱為細節(jié)層，DW層的數(shù)據(jù)應該是一致的、準確

的、干凈的數(shù)據(jù)，即對源系統(tǒng)數(shù)據(jù)進行了清洗（去除了雜質(zhì)）

后的數(shù)據(jù)。

數(shù)據(jù)應用：前端應用直接讀取的數(shù)據(jù)源；根據(jù)報表、專題分析

需求而計算生成的數(shù)據(jù)。

數(shù)據(jù)倉庫從各數(shù)據(jù)源獲取數(shù)據(jù)及在數(shù)據(jù)倉庫內(nèi)的數(shù)據(jù)轉換

和流動都可以認為是ETL(抽取Extra,轉化Transfer,裝載

Load)的過程，ETL是數(shù)據(jù)倉庫的流水線，也可以認為是數(shù)據(jù)

倉庫的血液，它維系著數(shù)據(jù)倉庫中數(shù)據(jù)的新陳代謝，而數(shù)據(jù)倉

庫日常的管理和維護工作的大部分精力就是保持ETL的正常和

穩(wěn)定。

那么為什么要數(shù)據(jù)倉庫進行分層呢？

?用空間換時間，通過大量的預處理來提升應用系統(tǒng)的用戶

體驗(效率)，因此數(shù)據(jù)倉庫會存在大量冗余的數(shù)據(jù)；不

分層的話，如果源業(yè)務系統(tǒng)的業(yè)務規(guī)則發(fā)生變化將會影響

整個數(shù)據(jù)清洗過程，工作量巨大。

?通過數(shù)據(jù)分層管理可以簡化數(shù)據(jù)清洗的過程，因為把原來

一步的工作分到了多個步驟去完成，相當于把一個復雜的

工作拆成了多個簡單的工作，把一個大的黑盒變成了一個

白盒，每一層的處理邏輯都相對簡單和容易理解，這樣我

們比較容易保證每一個步驟的正確性，當數(shù)據(jù)發(fā)生錯誤的

時候，往往我們只需要局部調(diào)整某個步驟即可。

1.5數(shù)據(jù)倉庫元數(shù)據(jù)的管理

元數(shù)據(jù)(MetaDate),主要記錄數(shù)據(jù)倉庫中模型的定義、各

層級間的映射關系、監(jiān)控數(shù)據(jù)倉庫的數(shù)據(jù)狀態(tài)及ETL的任務運行

狀態(tài)。一般會通過元數(shù)據(jù)資料庫(MetadataRepository)來統(tǒng)

一地存儲和管理元數(shù)據(jù)，其主要目的是使數(shù)據(jù)倉庫的設計、部署、

操作和管理能達成協(xié)同和一致。

元數(shù)據(jù)是數(shù)據(jù)倉庫管理系統(tǒng)的重要組成部分，元數(shù)據(jù)管理是

企業(yè)級數(shù)據(jù)倉庫中的關鍵組件，貫穿數(shù)據(jù)倉庫構建的整個過程，

直接影響著數(shù)據(jù)倉庫的構建、使用和維護。

?構建數(shù)據(jù)倉庫的主要步驟之一是ETL。這時元數(shù)據(jù)將發(fā)揮

重要的作用，它定義了源數(shù)據(jù)系統(tǒng)到數(shù)據(jù)倉庫的映射、數(shù)

據(jù)轉換的規(guī)則、數(shù)據(jù)倉庫的邏輯結構、數(shù)據(jù)更新的規(guī)則、

數(shù)據(jù)導入歷史記錄以及裝載周期等相關內(nèi)容。數(shù)據(jù)抽取和

轉換的專家以及數(shù)據(jù)倉庫管理員正是通過元數(shù)據(jù)高效地構

建數(shù)據(jù)倉庫。

?用戶在使用數(shù)據(jù)倉庫時，通過元數(shù)據(jù)訪問數(shù)據(jù)，明確數(shù)據(jù)

項的含義以及定制報表。

?數(shù)據(jù)倉庫的規(guī)模及其復雜性離不開正確的元數(shù)據(jù)管理，包

括增加或移除外部數(shù)據(jù)源，改變數(shù)據(jù)清洗方法，控制出錯

的查詢以及安排備份等。

元數(shù)據(jù)可分為技術元數(shù)據(jù)和業(yè)務元數(shù)據(jù)。技術元數(shù)據(jù)為開

發(fā)和管理數(shù)據(jù)倉庫的IT人員使用，它描述了與數(shù)據(jù)倉庫開

發(fā)、管理和維護相關的數(shù)據(jù)，包括數(shù)據(jù)源信息、數(shù)據(jù)轉換描

述、數(shù)據(jù)倉庫模型、數(shù)據(jù)清洗與更新規(guī)則、數(shù)據(jù)映射和訪問權

限等。而業(yè)務元數(shù)據(jù)為管理層和業(yè)務分析人員服務，從業(yè)務角

度描述數(shù)據(jù)，包括商務術語、數(shù)據(jù)倉庫中有什么數(shù)據(jù)、數(shù)據(jù)的

位置和數(shù)據(jù)的可用性等，幫助業(yè)務人員更好地理解數(shù)據(jù)倉庫中

哪些數(shù)據(jù)是可用的以及如何使用。

由上可見，元數(shù)據(jù)不僅定義了數(shù)據(jù)倉庫中數(shù)據(jù)的模式、來

源、抽取和轉換規(guī)則等，而且是整個數(shù)據(jù)倉庫系統(tǒng)運行的基

礎，元數(shù)據(jù)把數(shù)據(jù)倉庫系統(tǒng)中各個松散的組件聯(lián)系起來，組成

了一個有機的整體。

二、數(shù)倉建模方式

數(shù)據(jù)倉庫的建模方法有很多種，每一種建模方法代表了哲

學上的一個觀點，代表了一種歸納、概括世界的一種方法。常

見的有范式建模法、維度建模法、實體建模法等，每種方法

從本質(zhì)上將是從不同的角度看待業(yè)務中的問題。

2.1范式建模法

范式建模法其實是我們在構建數(shù)據(jù)模型常用的一個方法，

該方法的主要由Inmon所提倡，主要解決關系型數(shù)據(jù)庫的數(shù)

據(jù)存儲，利用的一種技術層面上的方法。目前，我們在關系型

數(shù)據(jù)庫中的建模方法，大部分采用的是三范式建模法。

范式是符合某一種級別的關系模式的集合。構造數(shù)據(jù)庫必

須遵循一定的規(guī)則，而在關系型數(shù)據(jù)庫中這種規(guī)則就是范式，

這一過程也被稱為規(guī)范化。目前關系數(shù)據(jù)庫有六種范式：第一

范式（1NF）、第二范式（2NF）、第三范式（3NF）、Boyce-

Codd范式（BCNF）、第四范式（4NF）和第五范式（5NF）。

在數(shù)據(jù)倉庫的模型設計中，一般采用第三范式。一個符合

第三范式的關系必須具有以下三個條件：

?每個屬性值唯一，不具有多義性；

?每個非主屬性必須完全依賴于整個主鍵，而非主鍵的一部

分；

?每個非主屬性不能依賴于其他關系中的屬性，因為這樣的

話，這種屬性應該歸到其他關系中去。

范式建模

根據(jù)Inmon的觀點，數(shù)據(jù)倉庫模型的建設方法和業(yè)務系

統(tǒng)的企業(yè)數(shù)據(jù)模型類似。在業(yè)務系統(tǒng)中，企業(yè)數(shù)據(jù)模型決定了

數(shù)據(jù)的來源，而企業(yè)數(shù)據(jù)模型也分為兩個層次，即主題域模型

和邏輯模型。同樣，主題域模型可以看成是業(yè)務模型的概念模

型，而邏輯模型則是域模型在關系型數(shù)據(jù)庫上的實例化。

2.2維度建模法

維度模型是數(shù)據(jù)倉庫領域另一位大師RalphKimall所倡

導，他的《數(shù)據(jù)倉庫工具箱》是數(shù)據(jù)倉庫工程領域最流行的數(shù)

倉建模經(jīng)典。維度建模以分析決策的需求出發(fā)構建模型，構建

的數(shù)據(jù)模型為分析需求服務，因此它重點解決用戶如何更快速

完成分析需求，同時還有較好的大規(guī)模復雜查詢的響應性能。

維度建模

典型的代表是我們比較熟知的星形模型(Star-schema),

以及在一些特殊場景下適用的雪花模型(Snow-schema)。

維度建模中比較重要的概念就是事實表(Facttable)和

維度表(Dimensiontable)。其最簡單的描述就是，按照事實

表、維度表來構建數(shù)據(jù)倉庫、數(shù)據(jù)集市。

目前在互聯(lián)網(wǎng)公司最常用的建模方法就是維度建模，稍后

將重點講解。

2.3實體建模法

實體建模法并不是數(shù)據(jù)倉庫建模中常見的一個方法，它來

源于哲學的一個流派。從哲學的意義上說，客觀世界應該是可

以細分的，客觀世界應該可以分成由一個個實體，以及實體與

實體之間的關系組成。那么我們在數(shù)據(jù)倉庫的建模過程中完全

可以引入這個抽象的方法，將整個業(yè)務也可以劃分成一個個的

實體，而每個實體之間的關系，以及針對這些關系的說明就是

我們數(shù)據(jù)建模需要做的工作。

雖然實體法粗看起來好像有一些抽象，其實理解起來很容

易。即我們可以將任何一個業(yè)務過程劃分成3個部分，實

體，事件，說明，如下圖所示：

學校

工五力鐘學欠級據(jù)

實體建模法

實體建模

上圖表述的是一個抽象的含義，如果我們描述一個簡單的

事實：“小明開車去學校上學”。以這個業(yè)務事實為例，我們

可以把“小明”，“學?！笨闯墒且粋€實體，“上學”描述的

是一個業(yè)務過程，我們在這里可以抽象為一個具體“事件”，

而“開車去”則可以看成是事件“上學”的一個說明。

三、維度建模

維度建模是目前應用較為廣泛的，專門應用于分析型數(shù)據(jù)

庫、數(shù)據(jù)倉庫、數(shù)據(jù)集市建模的方法。數(shù)據(jù)集市可以理解為是

一種〃小型數(shù)據(jù)倉庫〃。

3.1.維度建模中表的類型

3.1.1事實表

發(fā)生在現(xiàn)實世界中的操作型事件，其所產(chǎn)生的可度量數(shù)

值，存儲在事實表中。從最低的粒度級別來看，事實表行對應

一個度量事件，反之亦然。

事實表表示對分析主題的度量。比如一次購買行為我們就

可以理解為是一個事實。

維度表

維度表

商品表

商品ID

商品名

商品價格

維度表

事實與維度

圖中的訂單表就是一個事實表，你可以理解他就是在現(xiàn)實

中發(fā)生的一次操作型事件，我們每完成一個訂單，就會在訂單

中增加一條記錄。事實表的特征：表里沒有存放實際的內(nèi)容，

他是一堆主鍵的集合，這些ID分別能對應到維度表中的一條記

錄。事實表包含了與各維度表相關聯(lián)的外鍵，可與維度表關

聯(lián)。事實表的度量通常是數(shù)值類型，且記錄數(shù)會不斷增加，表

數(shù)據(jù)規(guī)模迅速增長。

明細表（寬表）：

事實表的數(shù)據(jù)中，有些屬性共同組成了一個字段（糅合在

一起），比如年月日時分秒構成了時間，當需要根據(jù)某一屬性進

行分組統(tǒng)計的時候，需要截取拼接之類的操作，效率極低。

如：

local_time

2021-03-1806:31:42

為了分析方便，可以事實表中的一個字段切割提取多個屬

性出來構成新的字段，因為字段變多了，所以稱為寬表，原來

的成為窄表。

將上述的localtime字段擴展為如下6個字段：

yearmonthdayhourms

20210318063142

又因為寬表的信息更加清晰明細，所以也可以稱之為明細

表。

3.1.2維度表

每個維度表都包含單一的主鍵列。維度表的主鍵可以作為

與之關聯(lián)的任何事實表的外鍵，當然，維度表行的描述環(huán)境應

與事實表行完全對應。維度表通常比較寬，是扁平型非規(guī)范

表，包含大量的低粒度的文本屬性。

維度表示你要對數(shù)據(jù)進行分析時所用的一個量，比如你要

分析產(chǎn)品銷售情況，你可以選擇按類別來進行分析，或按區(qū)域

來分析。每個類別就構成一個維度。事實表的圖中的用戶表、

商家表、時間表這些都屬于維度表，這些表都有一個唯一的主

鍵，然后在表中存放了詳細的數(shù)據(jù)信息。

總的說來，在數(shù)據(jù)倉庫中不需要嚴格遵守規(guī)范化設計原

則。因為數(shù)據(jù)倉庫的主導功能就是面向分析，以查詢?yōu)橹鳎?/p>

涉及數(shù)據(jù)更新操作。事實表的設計是以能夠正確記錄歷史信息

為準則，維度表的設計是以能夠以合適的角度來聚合主題內(nèi)容

為準則。

3.2維度建模三種模式

3.2.1星型模式

星形模式(StarSchema)是最常用的維度建模方式。星型

模式是以事實表為中心，所有的維度表直接連接在事實表上，

像星星一樣。星形模式的維度建模由一個事實表和一組維表

成，且具有以下特點：a.維表只和事實表關聯(lián)，維表之間沒有

關聯(lián)；b.每個維表主鍵為單列，且該主鍵放置在事實表中，作

為兩邊連接的外鍵；c.以事實表為核心，維表圍繞核心呈星形

分布；

部門博度表電質(zhì)填度表

事門主健地域主健

國*

總公司

缶

分公司方

市

代理處“

產(chǎn)品蟾度表時間爆度衰

產(chǎn)品主豌時間主樓

堆皮信包堆虔信旦

年

月

戶品倍價?

戶品質(zhì)最

3.2.2雪花模式

雪花模式(SnowflakeSchema)是對星形模式的擴展。雪花

模式的維度表可以擁有其他維度表的，雖然這種模型相比星型

更規(guī)范一些，但是由于這種模型不太容易理解，維護成本比較

高，而且性能方面需要關聯(lián)多層維表，性能也比星型模型要

低。所以一般不是很常用

雪花模式

3.2.3星座模式

星座模式是星型模式延伸而來，星型模式是基于一張事實

表的，而星座模式是基于多張事實表的，而且共享維度信息。

前面介紹的兩種維度建模方法都是多維表對應單事實表，但在

很多時候維度空間內(nèi)的事實表不止一個，而一個維表也可能被

多個事實表用到。在業(yè)務發(fā)展后期，絕大部分維度建模都采用

的是星座模式。

3.3維度建模過程

我們知道維度建模的表類型有事實表，維度表；模式有星

形模型，雪花模型，星座模型這些概念了，但是實際業(yè)務中，

給了我們一堆數(shù)據(jù)，我們怎么拿這些數(shù)據(jù)進行數(shù)倉建設呢，數(shù)

倉工具箱作者根據(jù)自身60多年的實際業(yè)務經(jīng)驗，給我們總結了

如下四步，請務必記?。?/p>

數(shù)倉工具箱中的維度建模四步走：

維度建模四步走:

1.選擇業(yè)務過程

2.聲明粒度

3.確認維度

4.確認事實

_____________________：；二五力舒亨力度

維度建模四步走

請牢記以上四步，不管什么業(yè)務，就按照這個步驟來，順

序不要搞亂，因為這四步是環(huán)環(huán)相扣，步步相連。下面詳細拆

解下每個步驟怎么做

3.3.1選擇業(yè)務過程

維度建模是緊貼業(yè)務的，所以必須以業(yè)務為根基進行建

模，那么選擇業(yè)務過程，顧名思義就是在整個業(yè)務流程中選取

我們需要建模的業(yè)務，根據(jù)運營提供的需求及日后的易擴展性

等進行選擇業(yè)務。比如商城，整個商城流程分為商家端，用戶

端，平臺端，運營需求是總訂單量，訂單人數(shù)，及用戶的購買

情況等，我們選擇業(yè)務過程就選擇用戶端的數(shù)據(jù)，商家及平臺

端暫不考慮。業(yè)務選擇非常重要，因為后面所有的步驟都是基

于此業(yè)務數(shù)據(jù)展開的。

3.3.2聲明粒度

先舉個例子：對于用戶來說，一個用戶有一個身份證號，

一個戶籍地址，多個手機號，多張銀行卡，那么與用戶粒度相

同的粒度屬性有身份證粒度，戶籍地址粒度，比用戶粒度更細

的粒度有手機號粒度，銀行卡粒度，存在一對一的關系就是相

同粒度。為什么要提相同粒度呢，因為維度建模中要求我們，

在同一事實表中，必須具有相同的粒度，同一事實表中不要混

用多種不同的粒度，不同的粒度數(shù)據(jù)建立不同的事實表。并且

從給定的業(yè)務過程獲取數(shù)據(jù)時，強烈建議從關注原子粒度開始

設計，也就是從最細粒度開始，因為原子粒度能夠承受無法預

期的用戶查詢。但是上卷匯總粒度對查詢性能的提升很重要

的，所以對于有明確需求的數(shù)據(jù)，我們建立針對需求的上卷匯

總粒度，對需求不明朗的數(shù)據(jù)我們建立原子粒度。

3.3.3確認維度

維度表是作為業(yè)務分析的入口和描述性標識，所以也被稱

為數(shù)據(jù)倉庫的“靈魂”。在一堆的數(shù)據(jù)中怎么確認哪些是維度

屬性呢，如果該列是對具體值的描述，是一個文本或常量，某

一約束和行標識的參與者，此時該屬性往往是維度屬性，數(shù)倉

工具箱中告訴我們牢牢掌握事實表的粒度，就能將所有可能存

在的維度區(qū)分開，并且要確保維度表中不能出現(xiàn)重復數(shù)據(jù)，應

使維度主鍵唯一

3.3.4確認事實

事實表是用來度量的，基本上都以數(shù)量值表示，事實表中

的每行對應一個度量，每行中的數(shù)據(jù)是一個特定級別的細節(jié)數(shù)

據(jù)，稱為粒度。維度建模的核心原則之一是同一事實表中的所

有度量必須具有相同的粒度。這樣能確保不會出現(xiàn)重復計算度

量的問題。有時候往往不能確定該列數(shù)據(jù)是事實屬性還是維度

屬性。記住最實用的事實就是數(shù)值類型和可加類事實。所以可

以通過分析該列是否是一種包含多個值并作為計算的參與者的

度量，這種情況下該列往往是事實。

四、實際業(yè)務中數(shù)倉分層

數(shù)倉分層要結合公司業(yè)務進行，并且需要清晰明確各層職

責，要保證數(shù)據(jù)層的穩(wěn)定又要屏蔽對下游影響，一般采用如下

分層結構：

數(shù)倉分層

ADD數(shù)據(jù)應用層，面向不同部門，不同業(yè)務

需求進行定制化開發(fā)，提供報表數(shù)據(jù)

數(shù)據(jù)輕匯總層，建設通用性維度和指標，主要表數(shù)據(jù)還是

UnM明細數(shù)據(jù)，部分數(shù)據(jù)為匯總數(shù)據(jù)，主要唱強指標員用性

nw數(shù)據(jù)明細層，對數(shù)據(jù)進行主題劃分，分為事

uvv實表和維度表，并對數(shù)據(jù)進行規(guī)范處理

\/

cns數(shù)據(jù)源層，僅導入業(yè)務方數(shù)據(jù)，不做任何處

理，相當于入大數(shù)據(jù)平臺前的爐五分前學大物據(jù)

數(shù)據(jù)分層架構

數(shù)據(jù)層具體實現(xiàn)

使用四張圖說明每層的具體實現(xiàn)

4.1數(shù)據(jù)源層ODS

數(shù)據(jù)源層業(yè)務庫數(shù)據(jù)

建iG甲犒.

與數(shù)據(jù)來Q俁持一致，還

全量同步

原業(yè)務過程，僅作為快照

0

存儲層業(yè)務庫

主要是業(yè)

務方mysql增量同步

中數(shù)據(jù)binlog同步

流量日志三方數(shù)據(jù)

外部公司接

理點數(shù)據(jù)定義日志規(guī)范口蠅數(shù)據(jù)采隼

服務端日志數(shù)據(jù)格式統(tǒng)一（廣告、運數(shù)據(jù)采買

/flume實營等數(shù)章）

通用接匚

、二二五力郛宇火龍V

數(shù)據(jù)源層

數(shù)據(jù)源層主要將各個業(yè)務數(shù)據(jù)導入到大數(shù)據(jù)平臺，作為業(yè)

務數(shù)據(jù)的快照存儲