一、前言
上一篇分享博文《數據倉庫專題（3）--分布式數據倉庫事實表設計思考》后，陸續有各位兄弟參加大討論，提出了各種問題，關於分布式環境下，維表和事實表設計，進行了比較深入的探討，在此匯集整理，分享給大家。希望能有更多人參與盡力啊，共同探索分布式數據倉庫數據模型的設計。
二、紀要
【活躍】北京-RTB-胖哥(1106110976) 10:21:36
分布式模式下事實表設計思考：
做大做強事實表，做小做弱維表；
【冒泡】杭州-電子病歷<ruanjizhou@qq.com> 10:23:31
能舉例子說明嗎？ 您這句話，我似懂非懂，但是確實在臨床上又有非常多的問題存在。
【潛水】廈門-BI-鍋蓋(584249213) 10:25:58
胖哥，我看了你博客，這點確實不太理解。你是指只有唯一值的維度直接合並到事實表嗎？
| 【潛水】bomb(4684895) 10:26:45 但是這樣做會有個問題，導致事實表變的更大 |
| 【潛水】bomb(4684895) 10:27:20 我覺得比較好的方式是使用列存儲數據庫，列存儲數據庫對於聚合計算是有很大優勢的 |
| 【冒泡】杭州-電子病歷<ruanjizhou@qq.com> 10:31:37 @廈門-BI-鍋蓋 胖哥的博客，您在哪里看的？方便發博客地址我嗎？ |
| 【潛水】廈門-BI-鍋蓋(584249213) 10:32:43
現在列存儲的廠家就SAP HANA,Oracle Exadata，不多而且比較貴 |
| 【潛水】廈門-BI-鍋蓋(584249213) 10:33:06
|
| 【潛水】廈門-BI-鍋蓋(584249213) 10:33:26
分布式模式-維度建模新原則 |
| 【冒泡】南京-電商-凌雲<hds1999@qq.com> 10:38:34
列存儲數據庫 只是在平台層面考慮的問題，但是對於海量數據的時候，在模型上面還是要有一定的考量的 |
| 【冒泡】南京-電商-凌雲<hds1999@qq.com> 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
主要是分布式列式數據庫，維表不能大，大了的話，內存消費不起呢。 |
| 【冒泡】南京-電商-凌雲<hds1999@qq.com> 10:46:26 維表不能太，是不是意味着維表就要做分表策略呢？ |
| 【冒泡】南京-電商-凌雲<hds1999@qq.com> 10:47:36 那就是維度設計考慮的問題，維度的層次是不是要多一些 |
| 【冒泡】南京-電商-凌雲<hds1999@qq.com> 10:48:03
|
| 【冒泡】南京-電商-凌雲<hds1999@qq.com> 10:48:35 在這里考慮的主鍵的作用是什么？ |
| 【冒泡】南京-電商-凌雲<hds1999@qq.com> 10:54:10 @北京-RTB-胖哥 是數據架構 |
| 【活躍】北京-RTB-胖哥(1106110976) 10:55:59 首先IP不重復，可以承擔維表中的主鍵，其次，IP作為事實表重的維度FK，如果只是針對IP地址的數值統計，可以不引入IP維表 |
| 【活躍】北京-RTB-胖哥(1106110976) 10:56:07 FK值就是IP地址。 |
| 【冒泡】南京-電商-凌雲<hds1999@qq.com> 10:58:27 但是如果是IP作為一個維表的話，那么主鍵是不是IP地址 沒有關系啊，因為你在事實表中還是要引用IP維表的主鍵作為FK，同樣可以基於IP維表的主鍵做數量統計的 |
| 【潛水】bomb(4684895) 11:00:19 這樣的情況，事實表也就是IP的維度表，自然不再需要IP的維度表 |
| 【冒泡】南京-電商-凌雲<hds1999@qq.com> 11:00:31 不對 |
| 【冒泡】南京-電商-凌雲<hds1999@qq.com> 11:01:13 事實表中不僅包括IP，還有其他的維度信息啊 |
| 【潛水】bomb(4684895) 11:01:52
恩，我明白胖哥的意思 |
| 【冒泡】南京-電商-凌雲<hds1999@qq.com> 11:02:12 對於IP維度來講的話，他的也是有層次的，比如國內IP，國外IP，不同電信運營商線路的IP |
| 【潛水】bomb(4684895) 11:02:53
這樣的情況我認為一般不會出現，就像一個銷售記錄中有訂單號，我們通常不會用訂單號做維度 |
| 【冒泡】南京-電商-凌雲<hds1999@qq.com> 11:03:00 是不是可以把IP地址理解成一種偽度量去考量的 |
| 【潛水】bomb(4684895) 11:06:42 我認為這個時候IP（或訂單號）其實就是事實表的主鍵了，通常這種情況下也不會對IP（或者訂單號）做分析，做分析時我們會關系一類IP或者某個地域的一類IP是什么樣的情況，而不會關心單個IP是什么樣的情況，如果關心單個IP的情況，就是明細查詢了，明細查詢可以考慮用其他的方式，比如搜索引擎 |
| 【潛水】bomb(4684895) 11:08:14 個人的一點愚見，歡迎拍磚 |
| 【冒泡】南京-電商-凌雲<hds1999@qq.com> 11:09:05 IP是事實表的主鍵？能舉例嗎 |
| 【活躍】北京-RTB-胖哥(1106110976) 11:09:27 先掐着，掐明白了，就明白了。 |
| 【潛水】bomb(4684895) 11:09:40
我覺得胖哥的意思，就像我們常見到的銷售訂單表 |
| 【潛水】bomb(4684895) 11:09:49 我同意，胖哥 |
| 【潛水】bomb(4684895) 11:10:48
在銷售訂單表中，每個訂單號是唯一的，就可以作為主鍵，這種情況下，我們通常不會再做一張訂單號的維度表 |
| 【冒泡】南京-電商-凌雲<hds1999@qq.com> 11:11:18 我們在銷售單中一般的考量是ID+單號 |
| 【潛水】bomb(4684895) 11:11:25 其實我們原來一個項目中干過這樣的實情，結果就呵呵了…… |
| 【潛水】bomb(4684895) 11:12:02 cube處理要很長時間，后來發現用戶根本不會用訂單號這個維度做分析，所以把這個維度去了，就快多了 |
| 【冒泡】南京-電商-凌雲<hds1999@qq.com> 11:12:42 這個是你的事實表數據粒度的考慮 |
| 【潛水】bomb(4684895) 11:12:47 一般我在事實表中沒有主鍵（sql server） |
| 【冒泡】南京-電商-凌雲<hds1999@qq.com> 11:12:57 如果客戶要用訂單號做分析呢 |
| 【潛水】bomb(4684895) 11:13:07
那就悲催了…… |
| 【冒泡】南京-電商-凌雲<hds1999@qq.com> 11:14:59 模型設計的時候不應該完全按照現有的數據分析需求考量 |
| 【潛水】bomb(4684895) 11:15:25
這個我同意 |
| 【冒泡】南京-電商-凌雲<hds1999@qq.com> 11:16:50 帶IP或者是訂單號的數據一般是粒度比較低的事實數據或者明細數據 |
| 【潛水】bomb(4684895) 11:16:53 但是對訂單信息按照每個訂單做分析，我認為是沒有意義的，數據分析是反映批量數據的狀態或趨勢，對單條訂單的查詢是明細查詢 |
| 【冒泡】南京-電商-凌雲<hds1999@qq.com> 11:17:49 對啊，所以說事實表的數據是按照維度的粒度做計算，分層的 |
| 【活躍】北京-RTB-胖哥(1106110976) 11:22:36 最細粒度的數據，有時候需要刻意的反規范設計 |
| 【活躍】北京-RTB-胖哥(1106110976) 11:22:42 也是沒辦法的事情。 |
| 【冒泡】南京-電商-凌雲<hds1999@qq.com> 11:27:29 對 |
| 【冒泡】南京-電商-凌雲<hds1999@qq.com> 11:27:57 反規范做冗余是經常的事情 |
三、未完待續
分布式數據倉庫數據存儲模型設計進行中，后續會持續更新，請關注QQ群：分布式數據倉庫建模 398419457。