數據倉庫系列之維度建模

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

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

星型模型  

雪花模型

       數據倉庫包含的內容不少，它能夠包括架構、建模和方法論。對應到具體工做中的話，它能夠包含下面的這些內容：

一、數據架構體系：以Hadoop、Spark等組建爲中心的數據架構體系。

二、各類數據建模方法：如維度建模、範式建模法、實體建模法。

三、輔助系統：調度系統、元數據系統、ETL系統、可視化系統這類輔助系統。

       咱們暫且無論數據倉庫的範圍到底有多大，在數據倉庫體系中，數據模型的核心地位是不可替代的。所以，下面的將詳細地闡述數據建模中的典型表明：維度建模，對它的的相關理論以及實際使用作深刻的分析。

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

       1、什麼是維度建模

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

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

 

星型模型

       2、維度建模的基本要素

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

      1. 事實表

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

 

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

       2. 維度表

每一個維度表都包含單一的主鍵列。維度表的主鍵能夠做爲與之關聯的任何事實表的外鍵，固然，維度錶行的描述環境應與事實錶行徹底對應。 維度表一般比較寬，是扁平型非規範表，包含大量的低粒度的文本屬性。圖中的customer（客戶表）、goods(商品表)、d_time(時間表)這些都屬於維度表，這些表都有一個惟一的主鍵，而後在表中存放了詳細的數據信息。

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

  

一、數據冗餘小（由於不少具體的信息都存在相應的維度表中了，好比客戶信息就只有一份）

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

三、便於作OLAP分析（數據分析用起來會很方便）

四、增長使用成本，好比查詢時要關聯多張表

五、數據不一致，好比用戶發起購買行爲的時候的數據，和咱們維度表裏面存放的數據不一致

再說沒有數據倉庫的寬事實表的優缺點：

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

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

三、數據冗餘巨大，真的很大，在幾億的用戶規模下，他的訂單行爲會很恐怖、粒度僵硬，什麼都寫死了，這張表的可複用性過低。

      數據倉庫的建模方法有不少種，我目前主要學習瞭解的維度建模方法。開始嘗試寫數據倉庫系列文章，文中若有錯誤或誤導的地方歡迎你們指出糾正。 但願這篇文章可以給你們帶來幫助，最後感謝你們的閱讀。歡迎你們一塊兒加入高效數據處理ETL交流羣，一塊兒討論數據分析前ETL過程的問題，一塊兒學習一塊兒成長。 

 掃碼加羣：