資料倉庫專題（4）-分布式資料倉庫事實表設計思考---讨論精華

一、前言

　　陸續有各位兄弟參加大讨論，提出了各種問題，關于分布式環境下，維表和事實表設計，進行了比較深入的探讨，在此彙集整理，分享給大家。希望能有更多人參與盡力啊，共同探索分布式資料倉庫資料模型的設計。

二、紀要

【活躍】北京-rtb-胖哥(1106110976) 10:21:36 

分布式模式下事實表設計思考：

做大做強事實表，做小做弱維表；

【冒泡】杭州-電子病曆<[email protected]> 10:23:31 

能舉例子說明嗎？ 您這句話，我似懂非懂，但是确實在臨床上又有非常多的問題存在。

【潛水】廈門-bi-鍋蓋(584249213) 10:25:58 

胖哥，我看了你部落格，這點确實不太了解。你是指隻有唯一值的次元直接合并到事實表嗎？

【潛水】bomb(4684895) 10:26:45

 但是這樣做會有個問題，導緻事實表變的更大

【潛水】bomb(4684895) 10:27:20

 我覺得比較好的方式是使用列存儲資料庫，列存儲資料庫對于聚合計算是有很大優勢的

【冒泡】杭州-電子病曆<[email protected]> 10:31:37

 @廈門-bi-鍋蓋 胖哥的部落格，您在哪裡看的？友善發部落格位址我嗎？

【潛水】廈門-bi-鍋蓋(584249213) 10:32:43

現在列存儲的廠家就sap hana,oracle exadata，不多而且比較貴

【潛水】廈門-bi-鍋蓋(584249213) 10:33:06

<a>http://www.cnblogs.com/hadoopdev/p/4425715.html</a>

【潛水】廈門-bi-鍋蓋(584249213) 10:33:26

分布式模式-次元模組化新原則

（1）以值代鍵：針對鍵值唯一的維表，除非必要，否則不引入維表，如ip位址維表，采用ip作為維表的主鍵，事實表中存儲ip值；

      （2）合理分表：傳統關系型資料倉庫存在多表整合的沖動，如上圖event事實表，各種acount ind，finance ind等，用來擴充表的通用性，試圖把所有的資料都存儲到一張表 中。分布式資料倉庫的設計，恰恰相反，因為單表資料規模的問題，如果要滿足分析和處理的性能，合理的按照業務進行資料的分表存儲。如财務相關事件、賬戶相關事件，單獨成表。更有利于資料的計算和分析。　

【冒泡】南京-電商-淩雲&lt;[email protected]&gt; 10:38:34

列存儲資料庫 隻是在平台層面考慮的問題，但是對于海量資料的時候，在模型上面還是要有一定的考量的

【冒泡】南京-電商-淩雲&lt;[email protected]&gt; 10:41:29

@北京-rtb-胖哥  分布式資料倉庫 在架構層面是如何設計的？

【活躍】北京-rtb-胖哥(1106110976) 10:43:13

架構，具體知識技術腳骨

【活躍】北京-rtb-胖哥(1106110976) 10:43:20

 架構還是資料架構

【活躍】北京-rtb-胖哥(1106110976) 10:43:24

 是兩個不同的問題。

【潛水】bomb(4684895) 10:43:50

sql

【潛水】bomb(4684895) 10:44:00

sql server 也有列存儲了

【活躍】北京-rtb-胖哥(1106110976) 10:44:03

 事實表不變，也大。因為海量資料情況下，單表的容積都是百億級别的。

【活躍】北京-rtb-胖哥(1106110976) 10:44:38

hive的分表，前提是你分表周期内的資料，都已經達到百億級别的情況。

【活躍】北京-rtb-胖哥(1106110976) 10:45:13

主要是分布式列式資料庫，維表不能大，大了的話，記憶體消費不起呢。

【冒泡】南京-電商-淩雲&lt;[email protected]&gt; 10:46:26

 維表不能太，是不是意味着維表就要做分表政策呢？

【冒泡】南京-電商-淩雲&lt;[email protected]&gt; 10:47:36

那就是次元設計考慮的問題，次元的層次是不是要多一些

【冒泡】南京-電商-淩雲&lt;[email protected]&gt; 10:48:03

【冒泡】南京-電商-淩雲&lt;[email protected]&gt; 10:48:35

  在這裡考慮的主鍵的作用是什麼？

【冒泡】南京-電商-淩雲&lt;[email protected]&gt; 10:54:10

 @北京-rtb-胖哥  是資料架構

【活躍】北京-rtb-胖哥(1106110976) 10:55:59

 首先ip不重複，可以承擔維表中的主鍵，其次，ip作為事實表重的次元fk，如果隻是針對ip位址的數值統計，可以不引入ip維表

【活躍】北京-rtb-胖哥(1106110976) 10:56:07

 fk值就是ip位址。

【冒泡】南京-電商-淩雲&lt;[email protected]&gt; 10:58:27

但是如果是ip作為一個維表的話，那麼主鍵是不是ip位址 沒有關系啊，因為你在事實表中還是要引用ip維表的主鍵作為fk，同樣可以基于ip維表的主鍵做數量統計的

【潛水】bomb(4684895) 11:00:19

 這樣的情況，事實表也就是ip的次元表，自然不再需要ip的次元表

【冒泡】南京-電商-淩雲&lt;[email protected]&gt; 11:00:31

 不對

【冒泡】南京-電商-淩雲&lt;[email protected]&gt; 11:01:13

 事實表中不僅包括ip，還有其他的次元資訊啊

【潛水】bomb(4684895) 11:01:52

恩，我明白胖哥的意思

【冒泡】南京-電商-淩雲&lt;[email protected]&gt; 11:02:12

對于ip次元來講的話，他的也是有層次的，比如國内ip，國外ip，不同電信營運商線路的ip

【潛水】bomb(4684895) 11:02:53

這樣的情況我認為一般不會出現，就像一個銷售記錄中有訂單号，我們通常不會用訂單号做次元

【冒泡】南京-電商-淩雲&lt;[email protected]&gt; 11:03:00

 是不是可以把ip位址了解成一種僞度量去考量的

【潛水】bomb(4684895) 11:06:42

 我認為這個時候ip（或訂單号）其實就是事實表的主鍵了，通常這種情況下也不會對ip（或者訂單号）做分析，做分析時我們會關系一類ip或者某個地域的一類ip是什麼樣的情況，而不會關心單個ip是什麼樣的情況，如果關心單個ip的情況，就是明細查詢了，明細查詢可以考慮用其他的方式，比如搜尋引擎

【潛水】bomb(4684895) 11:08:14

個人的一點愚見，歡迎拍磚

【冒泡】南京-電商-淩雲&lt;[email protected]&gt; 11:09:05

 ip是事實表的主鍵？能舉例嗎

【活躍】北京-rtb-胖哥(1106110976) 11:09:27

 先掐着，掐明白了，就明白了。

【潛水】bomb(4684895) 11:09:40

我覺得胖哥的意思，就像我們常見到的銷售訂單表

【潛水】bomb(4684895) 11:09:49

 我同意，胖哥

【潛水】bomb(4684895) 11:10:48

在銷售訂單表中，每個訂單号是唯一的，就可以作為主鍵，這種情況下，我們通常不會再做一張訂單号的次元表

【冒泡】南京-電商-淩雲&lt;[email protected]&gt; 11:11:18

 我們在銷售單中一般的考量是id+單号

【潛水】bomb(4684895) 11:11:25

 其實我們原來一個項目中幹過這樣的實情，結果就呵呵了……

【潛水】bomb(4684895) 11:12:02

 cube處理要很長時間，後來發現使用者根本不會用訂單号這個次元做分析，是以把這個次元去了，就快多了

【冒泡】南京-電商-淩雲&lt;[email protected]&gt; 11:12:42

 這個是你的事實表資料粒度的考慮

【潛水】bomb(4684895) 11:12:47

 一般我在事實表中沒有主鍵（sql server）

【冒泡】南京-電商-淩雲&lt;[email protected]&gt; 11:12:57

 如果客戶要用訂單号做分析呢

【潛水】bomb(4684895) 11:13:07

那就悲催了……

【冒泡】南京-電商-淩雲&lt;[email protected]&gt; 11:14:59

模型設計的時候不應該完全按照現有的資料分析需求考量

【潛水】bomb(4684895) 11:15:25

這個我同意

【冒泡】南京-電商-淩雲&lt;[email protected]&gt; 11:16:50

 帶ip或者是訂單号的資料一般是粒度比較低的事實資料或者明細資料

【潛水】bomb(4684895) 11:16:53

 但是對訂單資訊按照每個訂單做分析，我認為是沒有意義的，資料分析是反映批量資料的狀态或趨勢，對單條訂單的查詢是明細查詢

【冒泡】南京-電商-淩雲&lt;[email protected]&gt; 11:17:49

對啊，是以說事實表的資料是按照次元的粒度做計算，分層的

【活躍】北京-rtb-胖哥(1106110976) 11:22:36

 最細粒度的資料，有時候需要刻意的反規範設計

【活躍】北京-rtb-胖哥(1106110976) 11:22:42

 也是沒辦法的事情。

【冒泡】南京-電商-淩雲&lt;[email protected]&gt; 11:27:29

 對

【冒泡】南京-電商-淩雲&lt;[email protected]&gt; 11:27:57

 反規範做備援是經常的事情

三、未完待續

      分布式資料倉庫資料存儲模型設計進行中，後續會持續更新，請關注qq群：分布式資料倉庫模組化 398419457。