漫談數據倉庫之維度建模

• 以Hadoop、Spark、Hive等組建為中心的數據架構體系。
• 各種數據建模方法，如維度建模。
• 調度系統(tǒng)、元數據系統(tǒng)、ETL系統(tǒng)、可視化系統(tǒng)這類輔助系統(tǒng)。

1. 先介紹比較經典和常用的數據倉庫模型，并分析其優(yōu)缺點。
2. 詳細介紹維度建模的基本概念以及相關理論。
3. 為了能更真切地理解什么是維度建模，我將模擬一個大家都十分熟悉的電商場景，運用前面講到的理論進行建模。
4. 理論和現實的工作場景畢竟會有所差距，這一塊，我會分享一下企業(yè)在實際的應用中所做出的取舍。

一、實體關系（ER）模型

1. 需要全面了解企業(yè)業(yè)務和數據；
2. 實施周期非常長；
3. 對建模人員的能力要求也非常高。

二、維度模型

三、DataVault

四、Anchor模型

二、維度建模的基本要素

發(fā)生在現實世界中的操作型事件，其所產生的可度量數值，存儲在事實表中。從最低的粒度級別來看，事實表行對應一個度量事件，反之亦然。

每個維度表都包含單一的主鍵列。維度表的主鍵可以作為與之關聯的任何事實表的外鍵，當然，維度表行的描述環(huán)境應與事實表行完全對應。維度表通常比較寬，是扁平型非規(guī)范表，包含大量的低粒度的文本屬性。

一、業(yè)務場景

1. 電商網站中最典型的場景就是用戶的購買行為。
2. 一次購買行為的發(fā)起需要有這幾個個體的參與：購買者、商家、商品、購買時間、訂單金額。
3. 一個用戶可以發(fā)起很多次購買的動作。

1. 數據冗余小（因為很多具體的信息都存在相應的維度表中了，比如用戶信息就只有一份）；
2. 結構清晰（表結構一目了然）；
3. 便于做OLAP分析（數據分析用起來會很開心）；
4. 增加使用成本，比如查詢時要關聯多張表；
5. 數據不一致，比如用戶發(fā)起購買行為的時候的數據，和我們維度表里面存放的數據不一致。

1. 業(yè)務直觀，在做業(yè)務的時候，這種表特別方便，直接能對到業(yè)務中；
2. 使用方便，寫sql的時候很方便；
3. 數據冗余巨大，真的很大，在幾億的用戶規(guī)模下，他的訂單行為會很恐怖；
4. 粒度僵硬，什么都寫死了，這張表的可復用性太低。

-     使用示例    -

  SELECT
    SUM(order.money)
  FROM
    order,
    product,
    date,
    address,
    user,
  WHERE
    date.year = '2016'
    AND user.sex = 'male'
    AND address.province = '帝都'
    AND product.name = 'LV'


-     總結    -