上一篇文章我已經簡單介紹了資料分析中為啥要建立資料倉庫，從本週開始我們開始一起學習資料倉庫。學習資料倉庫，你一定會了解到兩個人：資料倉庫之父比爾·恩門（Bill Inmon）和資料倉庫權威專家Ralph Kimball。Inmon和Kimball兩種DW架構支撐了資料倉庫以及商業智慧近二十年的發展，其中Inmon主張自上而下的架構，不同的OLTP資料集中到面向主題、整合的、不易失的和時間變化的結構中，用於以後的分析;且資料可以通過下鑽到最細層，或者上捲到彙總層;資料集市應該是資料倉庫的子集;每個資料集市是針對獨立部門特殊設計的。而Kimball正好與Inmon相反，Kimball架構是一種自下而上的架構，它認為資料倉庫是一系列資料集市的集合。企業可以通過一系列維數相同的資料集市遞增地構建資料倉庫，通過使用一致的維度，能夠共同看到不同資料集市中的資訊，這表示它們擁有公共定義的元素。

       這裡我主要介紹維度建模方法。這一方法是Kimball最先提出的，其最簡單的描述就是按照事實表、維度表來構建資料倉庫、資料集市。在維度建模方法體系中，維度是描述事實的角度，如日期、客戶、供應商等，事實是要度量的指標，如客戶數、銷售額等。按照一般書籍的介紹，維度建模還會分為星型模型、雪花模型等，各有優缺點，但很少直接回答一個問題，也就是資料倉庫為什麼要採用維度建模？

星型模型  

雪花模型

       資料倉庫包含的內容很多，它可以包括架構、建模和方法論。對應到具體工作中的話，它可以包含下面的這些內容：

1、資料架構體系：以Hadoop、Spark等組建為中心的資料架構體系。

2、各種資料建模方法：如維度建模、正規化建模法、實體建模法。

3、輔助系統：排程系統、元資料系統、ETL系統、視覺化系統這類輔助系統。

       我們暫且不管資料倉庫的範圍到底有多大，在資料倉庫體系中，資料模型的核心地位是不可替代的。因此，下面的將詳細地闡述資料建模中的典型代表：維度建模，對它的的相關理論以及實際使用做深入的分析。

      為了能更真切地理解什麼是維度建模，我將在後續的文章中模擬一個大家都十分熟悉的電商場景，運用講到的理論進行建模。理論和現實的工作場景畢竟會有所差距，這一塊，我會分享一下企業在實際的應用中所做出的取捨。接下來具體來了解維度建模

       一、什麼是維度建模

       維度模型是資料倉庫領域大師Ralph Kimball 所倡導，他的《資料倉庫工具箱》，是資料倉庫工程領域最流行的數倉建模經典。維度建模以分析決策的需求出發構建模型，構建的資料模型為分析需求服務，因此它重點解決使用者如何更快速完成分析需求，同時還有較好的大規模複雜查詢的響應效能。

       我們換一種方式來解釋什麼是維度建模。學過資料庫的童鞋應該都知道星型模型，星型模型就是我們一種典型的維度模型。我們在進行維度建模的時候會建一張事實表，這個事實表就是星型模型的中心，然後會有一堆維度表，這些維度表就是向外發散的星星。那麼什麼是事實表、什麼又是維度表，下面會專門來解釋。

星型模型

       二、維度建模的基本要素

      維度建模中有一些比較重要的概念，理解了這些概念，基本也就理解了什麼是維度建模。

      1. 事實表

        發生在現實世界中的操作型事件，其所產生的可度量數值，儲存在事實表中。從最低的粒度級別來看，事實錶行對應一個度量事件，反之亦然。不太理解舉個例子。比如一次購買行為我們就可以理解為是一個事實，大家看一下星星模型示例。

       圖中的訂單表（ICstockbill）就是一個事實表，你可以理解他就是在現實中發生的一次操作型事件，我們每完成一個訂單，就會在訂單中增加一條記錄。我們可以回過頭再看一下事實表的特徵，在事實表裡沒有存放實際的內容，他是一堆主鍵的集合，這些ID分別能對應到維度表中的一條記錄。

       2. 維度表

每個維度表都包含單一的主鍵列。維度表的主鍵可以作為與之關聯的任何事實表的外來鍵，當然，維度錶行的描述環境應與事實錶行完全對應。 維度表通常比較寬，是扁平型非規範表，包含大量的低粒度的文字屬性。圖中的customer（客戶表）、goods(商品表)、d_time(時間表)這些都屬於維度表，這些表都有一個唯一的主鍵，然後在表中存放了詳細的資料資訊。

    最後說一下維度模型的優缺點：

1、資料冗餘小（因為很多具體的資訊都存在相應的維度表中了，比如客戶資訊就只有一份）

2、結構清晰（表結構一目瞭然）

3、便於做OLAP分析（資料分析用起來會很方便）

4、增加使用成本，比如查詢時要關聯多張表

5、資料不一致，比如使用者發起購買行為的時候的資料，和我們維度表裡面存放的資料不一致

再說沒有資料倉庫的寬事實表的優缺點：

1、業務直觀，在做業務的時候，這種表特別方便，直接能對到業務中。

2、使用方便，寫sql的時候很方便。

3、資料冗餘巨大，真的很大，在幾億的使用者規模下，他的訂單行為會很恐怖、粒度僵硬，什麼都寫死了，這張表的可複用性太低。

      資料倉庫的建模方法有很多種，我目前主要學習瞭解的維度建模方法。開始嘗試寫資料倉庫系列文章，文中如有錯誤或誤導的地方歡迎大家指出糾正。 希望這篇文章能夠給大家帶來幫助，最後感謝大家的閱讀。歡迎大家一起加入高效資料處理ETL交流群，一起討論資料分析前ETL過程的問題，一起學習一起成長。 

 掃碼加群：

&n