我們不管是基于 Hadoop 的數據倉庫（如 Hive ），還是基于傳統 MPP 架構的數據倉庫（如 Teradata ），抑或是基于傳統 Oracle 、MySQL 、SQL Server 關系型數據庫的數據倉庫，其實都面臨如下問題：

怎么組織數據倉庫中的數據？

怎么組織才能使得數據的使用最為方便和便捷？

怎么組織才能使得數據倉庫具有良好的可擴展性和可維護性？

Kimball 維度建模理論很好地回答和解決了上述問題。維度建模理論和技術也是目前在數據倉庫領域中使用最為廣泛的、也最得到認可和接納的一項技術。今天我們就來深入探討 Ralph Kimball 維度建模的各項技術，涵蓋其基本理論、一般過程、維度表設計和事實表設計等各個方面，也為我們后面講Hadoop 數據倉庫實戰打下基礎。 度量和環境 維度建模是支持對業務過程的分析，所以它是通過對業務過程度量進行建模來實現的。那么，什么是度量呢？實際上，我們通過和業務方、需求方交談，或者閱讀報表、圖表等，可以很容易地識別度量。考慮如下業務需求：

店鋪上個月的銷售額如何？

店鋪庫存趨勢如何？

店鋪的訪問情況如何（ pv，uv) ?

店鋪訪問的熟客占比多少？

“ 這里的銷售額、庫存、訪問量、熟客量就是度量。”“ 但是，單單談論度量，是沒有意義的。”度量和環境這兩個概念構成了維度建模的基礎。而所有維度建模也正是通過對度量和及其上下文和環境的詳細設計來實現的。事實和維度 在 Kimball 的維度建模理論中，“ 度量稱為事實，上下文和環境則稱為維度。”通常來說，事實常以數值形式出現，而且一般都被大量文本形式的上下文包圍著。這些文本形式的上下文描述了事實的“ 5個W ”（ When 、 Where 、 What 、 Who 、 Why ）信息，通常可被直觀地分割為獨立的邏輯塊，每一個獨立的邏輯塊即為一個維度，比如一個訂單可以非常直觀地分為商品 、買家、賣家等多個維度。在維度建模和設計過程中，可以根據需求描述或者基于現有報表，很容易地將信息和分析需求分類到事實和度量中。比如業務人員需求為“按照一級類目，統計本店鋪上月的銷售額情況”，“按照一級類自”這個描述，很清楚地說明需求方希望對一級類目的銷售額進行統計分析，這里的一級類目即為一個維度 。類似的是，“上月”為另一個維度，而銷售額明顯是事實。 事實表 事實表是維度模型中的基本表，或者說核心表。事實上，業務過程的所有度量在維度建模中都是存儲在事實表中的，除此之外，事實表還存儲了引用的維度。事實表通常和一個 企業的業務過程 緊密相關，由于一個企業的業務過程數據構成了其所有數據的絕大部分，因此事實表也通常占用了數據倉庫存儲的絕大部分。比如對于某個超市來說，其 銷售的明細數據 通常占其擁有數據的絕大部分且每天還在不斷地累計和增長，而商品、門店、員工、設備等其他數據相對來說固定且變化不大。事實表的一行對應一個度量事件事實上，每行對應的度量事件可粗可細，比如對某個超市來說，在設計其維度模型時，表示顧客購買事件的事實表的一行即可以記錄一張顧客的小票，也可以記錄顧客小票的一個子項。那么我們究竟應該到何種級別呢？維度建模認為事實表應該包含 最底層的、最原子性 的細節，因為這樣會帶來最大的靈活性。維度建模中，細節的級別稱為事實表的粒度，比如上文顧客購買行為事實表的粒度就應該是小票子項，而非小票。事實表中最常用的度量一般是數值型和可加類型的比如小票子項的銷售數量、銷售金額等，可加性對于數據分析來說至關重要，因為數據應用一般不僅檢索事實表的單行數據，而往往一次性檢索數百、數千乃至百萬行的事實，并且處理這么多行的最有用的和最常見的事就是將它們加起來，而且是從各個角度和維度加起來。但事實表中的度量并不都是可加的，有些是半可加性質的，另一些則是非可加性質的半加性事實是指僅僅某些維度可加，例如庫存，可以把各個地方倉庫的庫存加起來，或者把一個倉庫不同的商品加起來，但是很明顯不能把一個倉庫同一商品在不同時期的庫存加起來。銀行的賬戶余額也是半可加事實的例子，可以把不同分行的賬戶余額加起來或者不同賬戶人的賬戶余額加起來，但是不能把不同月份的賬戶余額加起來。非可加性事實則根本就不能相加的事實，比如商品的價格以及訂單的狀態等。除了存儲的事實外，事實表都會包含多個相關的外鍵。用于關聯和連接相應的維度表。例如，訂單事實表會包含連接到商品表的商品外鍵、連接到會員表的買家外鍵、或者連接到門店表的門店外鍵等。正是通過這些外鍵，才能進行各個角度的、各個維度的分析。事實表根據粒度的角色劃分不同，可分為事務事實表、周期快照事實表和累積快照事實表。

事務事實表用于承載事務數據，通常粒度比較低，例如產品交易事務事實、 ATM交易事務事實。

周期快照事實表用于記錄有規律的、固定時間間隔的業務累計數據，通常粒度比較大，例如賬戶月平均余額事實表。

累積快照事實表用于記錄具有時間跨度的業務處理過程的整個信息，通常這類事實表相對比較少見。

這里需要值得注意的是，在進行事實表的設計時，一定要注意 一個事實表只能有一個粒度，不能將不同粒度的事實建立在同一張事實表中。 維度表 維度表是維度建模的靈魂，通常來說，維度表設計得好壞直接決定了維度建模的好壞。維度表包含了 實表所記錄的業務過程度量的上下文和環境，它們除了記錄“5 個 W”等信息外，通常還包含了很多的描述字段和標簽字段等。維度表通常有多列或者說多個屬性。實際應用中，包含幾十甚至上百屬性的維度表并不少見。維度表應該盡可能多地包括 些有意義的文字性描述，以方便下游用戶使用。維度屬性是查詢約柬條件（ SQL where 條件）、分組（ SQL ?group 語句）與報表標簽生成的基本來源在查詢與報表需求中， 屬性用 by （按）這個單詞進行標識。維度屬性在數據倉庫中承擔著一個重要的角色。由于它們實際上是所有令人感興趣的約束條件與報表標簽的來源，因此是數據倉庫易學易用的關鍵。在許多方面，數據倉庫不過是維度屬性的體現而已。數據倉庫的能力直接與維度屬性的質量和深度成正比 。

在提供詳細的業務用語屬性方面所花的時間越多，數據倉庫就越好；

在屬性列值的給定方面所花的時間越多，數據倉庫就越好；

在保證屬性列值的質量方面所花的時間越多，數據倉庫就越好。

維度表是進入事實表的入口。豐富的維度屬性給出了豐富的分析切割能力。維度給用戶提供了使用數據倉庫的接口， 最好的屬性是文本的和離散的， 屬性應該是真正的文字而不應是一些編碼簡寫符號。我們應該通過更詳細的文本屬性取代編碼，力求最大限度地減少編碼在維度表中的使用。有時候在設計數據庫時，并不能很確定從數據源析取出的一個數字型數據字段到底應該作為事實還是維度屬性看待 ，通常可以這樣來做出決定，即看字段是一個含有許多取值并參與運算的度量值（當事實看待），還是一個變化不多并作為約束條件的離散取值的描述（當維度屬性看待）。 星形架構和雪花架構 在理解了事實表和維度表之后，接下來的問題就是如何組合它 在維度建模中，存在兩種組合維度表和事實表的基本架構：星形架構和雪花架構。當所有維度表直接連接到事實表時，整個組合的形狀類似于星星，所以被稱為星形架構。星形架構是一種非規范化的結構，其數據存儲存在冗余，比如考慮商品的維度表，其品牌信息在商品的每一行中都存在，包括其品牌 ID 、名稱、品牌擁有者等。通常很多商品的品牌都是一樣的，所以在商品維度表中品牌的信息被重復存儲了很多次，也就是存在冗余。當有一個或者多個維度表沒有直接連接到事實表，而是通過其他維度表連接到事實表上時，整個組合的形狀就像雪花一樣，這種架構被稱為雪花架構。雪花架構是對星形架構維度表的規范化，比如上述的商品表例子，在雪花架構中，其每一行僅存儲品牌 ID ，而品牌的所有其他信息（包括品牌名稱、擁有者、注冊地等所有描述信息）都存儲在單獨的品牌維度表內。通過品牌 ID 這個外鍵，商品表可以間接獲取到所有品牌描述信息。雪花架構去除了數據冗余，節省了部分存儲，但是也給下游用戶的使用帶來了不便如下游用戶需要分析品牌的銷售額，必須自己先用訂單表關聯商品表，然后用商品表再關聯品牌表。正是由于這一點，在維度建模的實際中， 雪花架構很少得到使用。有時候簡單的方案是最美的、最有力的，也是最有效的基于星形架構的維度建模就是這種情況 。星形架構犧牲了部分存儲的冗余，但是帶來了使用上的極度便捷，也使下游用戶的使用和學習成本變得非常低。即使是沒有任何技術背景或者維度建模背景知識的業務人員，也很容易理解，更何況目前的存儲成本極低，多出的這份存儲開銷相比后續每次的關聯計算、用戶使用和學習成本來說，是非常劃算的。星形架構中，每個維度都是均等的，所有維度表都是進入事實表的對等入口，用戶可以從任一維度、任一維度屬性或者任意多個維度組合、任意多個維度屬性組合，方便地對數據進行過濾和聚合（匯總、均值、最大、最小等）操作，而且非常符合業務分析直覺。業務是多變的，模型的設計必須能夠經受住業務多變的需求。在實際設計中，可以通過添加新維度或者向維度表中加入維度屬性來滿足業務新視角的分析需求。大多數情況下，數據倉庫模型設計中都會采用星形架構，但是在某些特殊情況下 ，比如必須使用橋接表的情況下等，必須使用雪花架構。 維度建模一般過程 維度建模一般采用具有順序的 個步驟來進行設計，即選擇業務過程、定義粒度、確定維度和確定事實。維度建模的這 個步驟貫穿了維度建模的整個過程和環節，下面逐一介紹。?

1. 選取業務過程 業務過程即企業和組織的業務活動，它們一般都有相應的源頭業務系統支持。對于一個超市來說，其最基本的業務活動就是用戶收銀臺付款；對于一個保險公司來說，最基本的業務活動是理賠和保單等 。當然在實際操作中，業務活動有可能并不是那么簡單直接 ，此時昕取用戶的意見通常是這一環節最為高效的方式。但需要注意的是，這里談到的業務過程并不是指業務部門或者職能。模型設計中，應將注意力集中放在業務過程而不是業務部門，如果建立的維度模型是同部門捆綁在一起的，就無法避免出現數據不一致的情況（如業務編碼、含義等）。因此，確保數據一致性的最佳辦法是從企業和公司全局與整體角度，對于某一個業務過程建立單一的、一致的維度模型。

2. 定義粒度 定義粒度意味著對事實表行實際代表的內容和含義給出明確的說明，粒度傳遞了事實表度量值相聯系的細節所達到的程度的信息。其實質就是如何描述事實表的單個行。典型的粒度定義包括：

超市顧客小票的每一個子項；

醫院收費單的明細子項；

個人銀行賬戶的每一次存款或者取款行為；

個人銀行賬戶每個月的余額快照；

對于維度設計來說，在事實表粒度上達成一致非常重要，如果沒有明確的粒度定義，則不能進入后面的環節。在定義粒度過程中，應該最大限度地選擇業務過程中最為原子性的粒度，這樣可以帶來后續的最大靈活度，也可以滿足業務用戶的任何粒度的分析需求。

?3. 確定維度 定義了粒度之后，相關業務過程的細節也就確定了，對應的維度就很容易確定。正如前文所述。維度是對度量的上下文和環境的描述通過維度，業務過程度量與事實就會變得豐富和豐滿起來。對于訂單來說，常見的維度會包含商品、日期、買家、賣家、門店等。而每一個維度還可以包含大量的描述信息，比如商品維度表會包含商品名稱、標簽價、商品品牌、商品類目、商品上線時間等。?

4. 確定事實 確定事實通過業務過程分析可能要分析什么來確定。定義粒度之后，事實和度量一般也很容易確定，比如超市的訂單活動，相關的度量顯然是銷售數量和銷售金額。在實際維度事實設計中，可能還會碰到度量拆分的問題，比如超市開展單個小票滿 100減 10 元的活動，如果小票金額超過 10 元，這 10 元的優惠額如何分配到每一個小票子項實際設計中，可以和業務方具體討論并制訂具體的拆分分配算法。……以上