維度建模+寬表的模式

包含多個(gè)事實(shí)表，并且維度表是公共的，可以共享。這么做的是為了避免數(shù)據(jù)冗余和數(shù)據(jù)復(fù)用，套用現(xiàn)成的模式，是比較合理的選擇。

維度模型的優(yōu)缺點(diǎn)

• 數(shù)據(jù)冗余小（因?yàn)楹芏嗑唧w的信息都存在相應(yīng)的維度表中了，比如用戶(hù)信息就只有一份） 結(jié)構(gòu)清晰（表結(jié)構(gòu)一目了然）
• 便于做OLAP分析（數(shù)據(jù)分析用起來(lái)會(huì)很開(kāi)心） 增加使用成本，比如查詢(xún)時(shí)要關(guān)聯(lián)多張表
• 數(shù)據(jù)不一致，比如用戶(hù)發(fā)起購(gòu)買(mǎi)行為的時(shí)候的數(shù)據(jù)，和我們維度表里面存放的數(shù)據(jù)不一致

大寬表的優(yōu)缺點(diǎn)

• 業(yè)務(wù)直觀，在做業(yè)務(wù)的時(shí)候，這種表特別方便，直接能對(duì)到業(yè)務(wù)中。 使用方便，寫(xiě)sql的時(shí)候很方便。
• 數(shù)據(jù)冗余巨大，真的很大，在幾億的用戶(hù)規(guī)模下，他的訂單行為會(huì)很恐怖
• 粒度僵硬，什么都寫(xiě)死了，這張表的可復(fù)用性太低，一旦發(fā)生變化，整個(gè)都需要重現(xiàn)刷新歷史數(shù)據(jù)。

在目前的情況下，選擇兩種都存的方式。這是一種trade-off.

Trade-off

數(shù)據(jù)倉(cāng)庫(kù)設(shè)計(jì)不是僅僅提供了數(shù)據(jù)存儲(chǔ)就可以，而是提供數(shù)據(jù)服務(wù)，讓使用方都通過(guò)服務(wù)的方式訪問(wèn)數(shù)據(jù)，這樣不管是安全性和易用性都容易得到滿(mǎn)足。

另外，數(shù)據(jù)倉(cāng)庫(kù)的設(shè)計(jì)，往往不能是以計(jì)算出幾張表就結(jié)束了，我們更應(yīng)該提供的是數(shù)據(jù)服務(wù)，讓使用方都通過(guò)服務(wù)的方式來(lái)訪問(wèn)我們的數(shù)據(jù)，而不是簡(jiǎn)單地將表暴露出去。當(dāng)我們以數(shù)據(jù)服務(wù)的方式提供數(shù)據(jù)的時(shí)候，不管是易用性還是安全性都更容易得到滿(mǎn)足。

兩種都存，雖然，這樣看起來(lái)會(huì)占用更多的存儲(chǔ)空間，但不失為一種合適的解決方案，因?yàn)閷挶硎峭ㄟ^(guò)別的表拼接而成的，因此寬表的存儲(chǔ)周期是可以短一些。
只存多個(gè)維度表，通過(guò)視圖來(lái)創(chuàng)建寬表。這種方式適合于寬表的查詢(xún)次數(shù)較少的情況。比如在Hive中，寬表其實(shí)只是為了計(jì)算出來(lái)之后導(dǎo)入Es等系統(tǒng)中供其它系統(tǒng)查詢(xún)，那么久沒(méi)必要存儲(chǔ)一份寬表，直接通過(guò)視圖來(lái)封裝就可以。

維度建模是一種十分優(yōu)秀的建模方式，他有很多的優(yōu)點(diǎn)，但是我們?cè)趯?shí)際工作中也很難完全按照它的方式來(lái)實(shí)現(xiàn)，都會(huì)有所取舍，比如說(shuō)為了業(yè)務(wù)我們還是會(huì)需要一些寬表，有時(shí)候還會(huì)有很多的數(shù)據(jù)冗余。這樣互為補(bǔ)充。

總結(jié)

以上是生活随笔為你收集整理的关于维度建模的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。