訂閱
糾錯(cuò)
加入自媒體

一文了解數(shù)倉(cāng)建模—Inmon范式建模與Kimball維度建模

2021-04-07 09:50
園陌
關(guān)注

在數(shù)據(jù)倉(cāng)庫(kù)領(lǐng)域,有兩位大師,一位是“數(shù)據(jù)倉(cāng)庫(kù)”之父 Bill Inmon,一位是數(shù)據(jù)倉(cāng)庫(kù)權(quán)威專家 Ralph Kimball,兩位大師每人都有一本經(jīng)典著作,Inmon大師著作《數(shù)據(jù)倉(cāng)庫(kù)》及Kimball大師的《數(shù)倉(cāng)工具箱》,兩本書也代表了兩種不同的數(shù)倉(cāng)建設(shè)模式,這兩種架構(gòu)模式支撐了數(shù)據(jù)倉(cāng)庫(kù)以及商業(yè)智能近二十年的發(fā)展。今天我們就來聊下這兩種建模方式——范式建模和維度建模。

本文開始先簡(jiǎn)單理解兩種建模的核心思想,然后根據(jù)一個(gè)具體的例子,分別使用這兩種建模方式進(jìn)行建模,大家便會(huì)一目了然!

一、兩種建模思想

對(duì)于 Inmon 和 Kimball 兩種建模方式可以長(zhǎng)篇大論敘述,但理論是很枯燥的,尤其是晦澀難懂的文字,大家讀完估計(jì)也不會(huì)收獲太多,所以我根據(jù)自己的理解用通俗的語(yǔ)言提煉出最核心的概念。

范式建模

范式建模是數(shù)倉(cāng)之父 Inmon 所倡導(dǎo)的,“數(shù)據(jù)倉(cāng)庫(kù)”這個(gè)詞就是這位大師所定義的,這種建模方式在范式理論上符合3NF,這里的3NF與OLTP中的3NF還是有點(diǎn)區(qū)別的:關(guān)系數(shù)據(jù)庫(kù)中的3NF是針對(duì)具體的業(yè)務(wù)流程的實(shí)體對(duì)象關(guān)系抽象,而數(shù)據(jù)倉(cāng)庫(kù)的3NF是站在企業(yè)角度面向主題的抽象。

Inmon 模型從流程上看是自上而下的,自上而下指的是數(shù)據(jù)的流向,“上”即數(shù)據(jù)的上游,“下”即數(shù)據(jù)的下游,即從分散異構(gòu)的數(shù)據(jù)源 -> 數(shù)據(jù)倉(cāng)庫(kù) -> 數(shù)據(jù)集市。以數(shù)據(jù)源頭為導(dǎo)向,然后一步步探索獲取盡量符合預(yù)期的數(shù)據(jù),因?yàn)閿?shù)據(jù)源往往是異構(gòu)的,所以會(huì)更加強(qiáng)調(diào)數(shù)據(jù)的清洗工作,將數(shù)據(jù)抽取為實(shí)體-關(guān)系模型,并不強(qiáng)調(diào)事實(shí)表和維度表的概念。

維度建模

Kimball 模型從流程上看是自下而上的,即從數(shù)據(jù)集市-> 數(shù)據(jù)倉(cāng)庫(kù) -> 分散異構(gòu)的數(shù)據(jù)源。Kimball 是以最終任務(wù)為導(dǎo)向,將數(shù)據(jù)按照目標(biāo)拆分出不同的表需求,數(shù)據(jù)會(huì)抽取為事實(shí)-維度模型,數(shù)據(jù)源經(jīng)ETL轉(zhuǎn)化為事實(shí)表和維度表導(dǎo)入數(shù)據(jù)集市,以星型模型或雪花模型等方式構(gòu)建維度數(shù)據(jù)倉(cāng)庫(kù),架構(gòu)體系中,數(shù)據(jù)集市與數(shù)據(jù)倉(cāng)庫(kù)是緊密結(jié)合的,數(shù)據(jù)集市是數(shù)據(jù)倉(cāng)庫(kù)中一個(gè)邏輯上的主題域。

兩種建模方式的理論概念就簡(jiǎn)單介紹到這,因?yàn)榧兝碚撝R(shí)說再多,大家也可能有點(diǎn)迷惑,所以下面用一個(gè)具體的例子來實(shí)踐兩種建模方式。

二、兩種建模實(shí)踐

通過上一小節(jié)兩種建模核心思想,相信大家對(duì)這兩種建模方式已經(jīng)有了大概的理解,接下來我們通過具體的例子,讓大家有具體的感受。

以電商舉例

大家都網(wǎng)購(gòu)過,知道購(gòu)買物品的流程,因此以電商購(gòu)物為例,更易于大家的理解。

真實(shí)的電商購(gòu)物的流程較復(fù)雜,此處表數(shù)量和表字段做簡(jiǎn)化處理。

1. 源表的結(jié)構(gòu)及數(shù)據(jù)

對(duì)于我們大數(shù)據(jù)平臺(tái)來說,源表指的電商系統(tǒng)中后臺(tái)數(shù)據(jù)庫(kù)中的表,這種表一般都是OLTP類型的表:

① 用戶信息表用戶ID昵稱姓名性別聯(lián)系方式地區(qū)用戶等級(jí)ID創(chuàng)建時(shí)間修改時(shí)間是否注銷1001小憶控張翠花女15034951345031022021-04-03 13:11:012021-04-04 15:16:0001002池木李建國(guó)男17834686673031112021-04-03 14:11:012021-04-04 15:26:0101003君勿笑劉素芬女15687876464031212021-04-03 15:11:012021-04-04 16:16:0001004原野王富貴男15013145210031332021-04-03 15:23:012021-04-04 17:16:001② 城市信息表城市ID省市0310河北邯鄲0311河北石家莊0312河北保定0313河北張家口③ 用戶等級(jí)表用戶等級(jí)ID價(jià)值屬性1重要價(jià)值用戶2一般價(jià)值用戶3一般發(fā)展用戶④ 用戶訂單表訂單ID用戶ID訂單狀態(tài)商品ID商品總額下單時(shí)間支付金額支付類型OR110011001未支付CO31243122.002021-04-04 10:12:050.00
OR110021002已支付CO5435386.502021-04-04 11:12:0586.50支付寶OR110031003已支付CO4325346.002021-04-04 14:16:050.00助力免費(fèi)OR110041002已支付CO34235210.002021-04-04 11:12:05210.00支付寶2. 使用 Inmon 模式建模

使用 Inmon 模式對(duì)以上源表數(shù)據(jù)進(jìn)行建模,需要將數(shù)據(jù)抽取為實(shí)體-關(guān)系模式,根據(jù)源表的數(shù)據(jù),我們將表拆分為:用戶實(shí)體表,訂單實(shí)體表,城市信息實(shí)體表,用戶與城市信息關(guān)系表,用戶與用戶等級(jí)關(guān)系表等多個(gè)子模塊:

① 用戶實(shí)體表

(注:ETL已過濾掉注銷用戶)

用戶ID姓名性別聯(lián)系方式地區(qū)用戶等級(jí)ID創(chuàng)建時(shí)間修改時(shí)間1001張翠花女15034951345031022021-04-03 13:11:012021-04-04 15:16:001002李建國(guó)男17834686673031112021-04-03 14:11:012021-04-04 15:26:011003劉素芬女15687876464031212021-04-03 15:11:012021-04-04 16:16:00② 支付成功訂單實(shí)體表訂單ID用戶ID商品ID商品總額下單時(shí)間支付金額支付類型OR110021002CO5435386.502021-04-04 11:12:0586.50支付寶OR110031003CO4325346.002021-04-04 14:16:050.00助力免費(fèi)OR110041002CO34235210.002021-04-04 11:12:05210.00支付寶③ 城市信息實(shí)體表城市ID省市0310河北邯鄲0311河北石家莊0312河北保定0313河北張家口④ 訂單與用戶關(guān)系表訂單ID用戶IDOR110021002OR110031003OR110041002⑤ 用戶與城市信息關(guān)系表用戶ID城市ID100103101002031110030312⑥ 用戶與用戶等級(jí)關(guān)系表用戶ID用戶等級(jí)ID100121002110031

通過以上我們可以發(fā)現(xiàn),范式建模就是將源表抽取為實(shí)體表,關(guān)系表,所以范式建模即是實(shí)體關(guān)系(ER)模型。數(shù)據(jù)沒有冗余,符合三范式設(shè)計(jì)規(guī)范。

3. 使用 Kimball 模式建模

使用 Kimball 模式,需要將數(shù)據(jù)抽取為事實(shí)表和維度表,根據(jù)源表數(shù)據(jù),我們將表拆分為:訂單事實(shí)表,用戶維度表,城市信息維度表,用戶等級(jí)維度表。

可以看出,在 Kimball 的維度建模中,不需要單獨(dú)維護(hù)數(shù)據(jù)關(guān)系表,因?yàn)殛P(guān)系已經(jīng)冗余在事實(shí)表和維度表中。

① 支付成功訂單事實(shí)表訂單ID用戶ID商品ID商品總額下單時(shí)間支付金額支付類型OR110021002CO5435386.502021-04-04 11:12:0586.50支付寶OR110031003CO4325346.002021-04-04 14:16:050.00助力免費(fèi)OR110041002CO34235210.002021-04-04 11:12:05210.00支付寶② 用戶維度表用戶ID姓名性別聯(lián)系方式地區(qū)用戶等級(jí)ID創(chuàng)建時(shí)間修改時(shí)間1001張翠花女15034951345031022021-04-03 13:11:012021-04-04 15:16:001002李建國(guó)男17834686673031112021-04-03 14:11:012021-04-04 15:26:011003劉素芬女15687876464031212021-04-03 15:11:012021-04-04 16:16:00③ 城市信息維度表城市ID省市0310河北邯鄲0311河北石家莊0312河北保定0313河北張家口④ 用戶等級(jí)維度表用戶等級(jí)ID價(jià)值屬性1重要價(jià)值用戶2一般價(jià)值用戶3一般發(fā)展用戶

我們用圖的方式將以上表之間的關(guān)系簡(jiǎn)單展示出來:

根據(jù)上圖,我們發(fā)現(xiàn)什么,這不就是典型的雪花模式嘛,其特點(diǎn)就是維度表可以擁有其他維度表。

三、兩種建模對(duì)比兩種建模方式特點(diǎn)

范式建模:通過上一小節(jié)的具體例子可以看出范式建模的優(yōu)點(diǎn):能夠結(jié)合業(yè)務(wù)系統(tǒng)的數(shù)據(jù)模型,較方便的實(shí)現(xiàn)數(shù)據(jù)倉(cāng)庫(kù)的模型;同一份數(shù)據(jù)只存放在一個(gè)地方,沒有數(shù)據(jù)冗余,保證了數(shù)據(jù)一致性;數(shù)據(jù)解耦,方便維護(hù)。但同時(shí)也帶來了缺點(diǎn):表的數(shù)量多;查詢時(shí)關(guān)聯(lián)表較多使得查詢性能降低。

維度建模:模型結(jié)構(gòu)簡(jiǎn)單,面向分析,為了提高查詢性能可以增加數(shù)據(jù)冗余,反規(guī)范化的設(shè)計(jì),開發(fā)周期短,能夠快速迭代。缺點(diǎn)就是數(shù)據(jù)會(huì)大量冗余,預(yù)處理階段開銷大,后期維護(hù)麻煩;還有一個(gè)問題就是不能保證數(shù)據(jù)口徑一致性,原因后面有講解。

我們?cè)賮砝斫庀戮S度建模:數(shù)據(jù)會(huì)抽取為事實(shí)-維度模型,維度就是看待問題的角度,從不同的角度看待某個(gè)問題,就會(huì)得出不同的結(jié)論,而要得到這個(gè)結(jié)論,就需要事實(shí)表中的度量,何為度量,就是事實(shí)表中數(shù)值類型的字段。

例:某公司的各個(gè)商品在全國(guó)各地市的銷售情況,維度就是全國(guó)的城市和各個(gè)商品,度量就是商品的單價(jià),從不同的維度計(jì)算銷售額:如查看北京市酸奶的銷售額,上海市純牛奶的銷售額,這就是不同的維度組合方式。在限定的維度條件上,計(jì)算商品單價(jià)的總和,也就是 sum 度量值,即可得到我們想要的結(jié)果。

維度建模,就是依靠維度進(jìn)行建模,但是如果維度設(shè)計(jì)的不合理,會(huì)不會(huì)帶來問題呢?

如果我們把省份當(dāng)做一個(gè)單獨(dú)維度,城市當(dāng)做一個(gè)維度,計(jì)算城市的人口數(shù)量。這時(shí)省份和城市都是單獨(dú)的維度,它們之間沒有了關(guān)系,就會(huì)出現(xiàn)以下情況:

廣東省 杭州市 1500
浙江省 廣州市 1200

這時(shí)會(huì)出現(xiàn)數(shù)據(jù)口徑不一致,最后導(dǎo)致數(shù)據(jù)結(jié)果不準(zhǔn)確。而范式建模就不會(huì)出現(xiàn)這個(gè)問題,因?yàn)樵诜妒浇V袕?qiáng)調(diào)的就是實(shí)體-關(guān)系模型,所以省份和城市之間一定存在歸屬關(guān)系的,不會(huì)出現(xiàn)省份和城市口徑不一致的問題。

所以,范式建模能保證口徑的一致性,而維度建模不能!

建模方式對(duì)比

通過上一節(jié)的具體的例子以及兩種建模的特點(diǎn),我們對(duì)比下兩種建模方式的不同:

特性KimballInmon開發(fā)周期短長(zhǎng)開發(fā)難度小大維護(hù)難度大小數(shù)據(jù)要求針對(duì)具體業(yè)務(wù)站在企業(yè)角度精心設(shè)計(jì)否是緩慢變化維是否需要的人員少量專業(yè)團(tuán)隊(duì)數(shù)據(jù)模型維度建模,星型模型、雪花模型實(shí)體-關(guān)系模型,準(zhǔn)三范式設(shè)計(jì)

我們知道,互聯(lián)網(wǎng)公司的業(yè)務(wù)一般是周期比較短需求變化快,并且迭代頻繁,如果精心設(shè)計(jì) Inmon 實(shí)體-關(guān)系的模式似乎并不能滿足快速迭代的業(yè)務(wù)需要。所以,互聯(lián)網(wǎng)公司更多場(chǎng)景下趨向于使用 Kimball 維度-事實(shí)的設(shè)計(jì)反而可以更快地完成任務(wù)。

四、兩種建;旌蠄(chǎng)景

通過以上幾個(gè)小節(jié)我們已經(jīng)理解了范式建模與維度建模的思想以及它們之間的異同,優(yōu)缺點(diǎn)。那么我們能不能將兩種建模方式混合使用呢,讓它們發(fā)揮各自最大的優(yōu)勢(shì)。接下來我們一起來看下。

范式建模必須符合準(zhǔn)三范式設(shè)計(jì)規(guī)范,如果使用混合建模,則源表也需要符合范式建模的限制,即源數(shù)據(jù)須為操作型或事務(wù)型系統(tǒng)的數(shù)據(jù)。通過ETL抽取轉(zhuǎn)換和加載到數(shù)據(jù)倉(cāng)庫(kù)的ODS層,ODS層數(shù)據(jù)與源數(shù)據(jù)是保持一致的,所以O(shè)DS層數(shù)據(jù)也是符合范式設(shè)計(jì)規(guī)范的,通過ODS的數(shù)據(jù),利用范式建模方法,建設(shè)原子數(shù)據(jù)的數(shù)據(jù)倉(cāng)庫(kù)EDW,然后基于EDW,利用維度建模方法建設(shè)數(shù)據(jù)集市。

結(jié)合兩種建模方式的各自規(guī)范,混合建模按照“松耦合、層次化”的基本架構(gòu)原則進(jìn)行實(shí)施;旌蠑(shù)據(jù)倉(cāng)庫(kù)架構(gòu)方法主要包含以下關(guān)鍵步驟:業(yè)務(wù)需求分步構(gòu)建、分層次保存數(shù)據(jù)、整合原子級(jí)的數(shù)據(jù)標(biāo)準(zhǔn)、維護(hù)一致性維度等。

最后

建模方式?jīng)]有好與壞之分,只有合適與不合適之分,在實(shí)際數(shù)倉(cāng)建設(shè)中,需要靈活多變,不能全依賴建模理論,也不能不依賴。適時(shí)變通,才能建設(shè)一個(gè)好的數(shù)據(jù)倉(cāng)庫(kù)。

聲明: 本文由入駐維科號(hào)的作者撰寫,觀點(diǎn)僅代表作者本人,不代表OFweek立場(chǎng)。如有侵權(quán)或其他問題,請(qǐng)聯(lián)系舉報(bào)。

發(fā)表評(píng)論

0條評(píng)論,0人參與

請(qǐng)輸入評(píng)論內(nèi)容...

請(qǐng)輸入評(píng)論/評(píng)論長(zhǎng)度6~500個(gè)字

您提交的評(píng)論過于頻繁,請(qǐng)輸入驗(yàn)證碼繼續(xù)

  • 看不清,點(diǎn)擊換一張  刷新

暫無評(píng)論

暫無評(píng)論

人工智能 獵頭職位 更多
掃碼關(guān)注公眾號(hào)
OFweek人工智能網(wǎng)
獲取更多精彩內(nèi)容
文章糾錯(cuò)
x
*文字標(biāo)題:
*糾錯(cuò)內(nèi)容:
聯(lián)系郵箱:
*驗(yàn) 證 碼:

粵公網(wǎng)安備 44030502002758號(hào)