一、前言
上一篇分享博文《資料倉儲專題（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。