一文了解數倉建模—Inmon范式建模與Kimball維度建模
在數據倉庫領域,有兩位大師,一位是“數據倉庫”之父 Bill Inmon,一位是數據倉庫權威專家 Ralph Kimball,兩位大師每人都有一本經典著作,Inmon大師著作《數據倉庫》及Kimball大師的《數倉工具箱》,兩本書也代表了兩種不同的數倉建設模式,這兩種架構模式支撐了數據倉庫以及商業智能近二十年的發展。今天我們就來聊下這兩種建模方式——范式建模和維度建模。
本文開始先簡單理解兩種建模的核心思想,然后根據一個具體的例子,分別使用這兩種建模方式進行建模,大家便會一目了然!
一、兩種建模思想
對于 Inmon 和 Kimball 兩種建模方式可以長篇大論敘述,但理論是很枯燥的,尤其是晦澀難懂的文字,大家讀完估計也不會收獲太多,所以我根據自己的理解用通俗的語言提煉出最核心的概念。
范式建模
范式建模是數倉之父 Inmon 所倡導的,“數據倉庫”這個詞就是這位大師所定義的,這種建模方式在范式理論上符合3NF,這里的3NF與OLTP中的3NF還是有點區別的:關系數據庫中的3NF是針對具體的業務流程的實體對象關系抽象,而數據倉庫的3NF是站在企業角度面向主題的抽象。
Inmon 模型從流程上看是自上而下的,自上而下指的是數據的流向,“上”即數據的上游,“下”即數據的下游,即從分散異構的數據源 -> 數據倉庫 -> 數據集市。以數據源頭為導向,然后一步步探索獲取盡量符合預期的數據,因為數據源往往是異構的,所以會更加強調數據的清洗工作,將數據抽取為實體-關系模型,并不強調事實表和維度表的概念。
維度建模
Kimball 模型從流程上看是自下而上的,即從數據集市-> 數據倉庫 -> 分散異構的數據源。Kimball 是以最終任務為導向,將數據按照目標拆分出不同的表需求,數據會抽取為事實-維度模型,數據源經ETL轉化為事實表和維度表導入數據集市,以星型模型或雪花模型等方式構建維度數據倉庫,架構體系中,數據集市與數據倉庫是緊密結合的,數據集市是數據倉庫中一個邏輯上的主題域。
兩種建模方式的理論概念就簡單介紹到這,因為純理論知識說再多,大家也可能有點迷惑,所以下面用一個具體的例子來實踐兩種建模方式。
二、兩種建模實踐
通過上一小節兩種建模核心思想,相信大家對這兩種建模方式已經有了大概的理解,接下來我們通過具體的例子,讓大家有具體的感受。
以電商舉例
大家都網購過,知道購買物品的流程,因此以電商購物為例,更易于大家的理解。
真實的電商購物的流程較復雜,此處表數量和表字段做簡化處理。
1． 源表的結構及數據
對于我們大數據平臺來說,源表指的電商系統中后臺數據庫中的表,這種表一般都是OLTP類型的表:
① 用戶信息表用戶ID昵稱姓名性別聯系方式地區用戶等級ID創建時間修改時間是否注銷1001小憶控張翠花女15034951345031022021-04-03 13:11:012021-04-04 15:16:0001002池木李建國男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河北張家口③ 用戶等級表用戶等級ID價值屬性1重要價值用戶2一般價值用戶3一般發展用戶④ 用戶訂單表訂單ID用戶ID訂單狀態商品ID商品總額下單時間支付金額支付類型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助力免費OR110041002已支付CO34235210．002021-04-04 11:12:05210．00支付寶2． 使用 Inmon 模式建模
使用 Inmon 模式對以上源表數據進行建模,需要將數據抽取為實體-關系模式,根據源表的數據,我們將表拆分為:用戶實體表,訂單實體表,城市信息實體表,用戶與城市信息關系表,用戶與用戶等級關系表等多個子模塊:
① 用戶實體表
(注:ETL已過濾掉注銷用戶)
用戶ID姓名性別聯系方式地區用戶等級ID創建時間修改時間1001張翠花女15034951345031022021-04-03 13:11:012021-04-04 15:16:001002李建國男17834686673031112021-04-03 14:11:012021-04-04 15:26:011003劉素芬女15687876464031212021-04-03 15:11:012021-04-04 16:16:00② 支付成功訂單實體表訂單ID用戶ID商品ID商品總額下單時間支付金額支付類型OR110021002CO5435386．502021-04-04 11:12:0586．50支付寶OR110031003CO4325346．002021-04-04 14:16:050．00助力免費OR110041002CO34235210．002021-04-04 11:12:05210．00支付寶③ 城市信息實體表城市ID省市0310河北邯鄲0311河北石家莊0312河北保定0313河北張家口④ 訂單與用戶關系表訂單ID用戶IDOR110021002OR110031003OR110041002⑤ 用戶與城市信息關系表用戶ID城市ID100103101002031110030312⑥ 用戶與用戶等級關系表用戶ID用戶等級ID100121002110031
通過以上我們可以發現,范式建模就是將源表抽取為實體表,關系表,所以范式建模即是實體關系(ER)模型。數據沒有冗余,符合三范式設計規范。
3． 使用 Kimball 模式建模
使用 Kimball 模式,需要將數據抽取為事實表和維度表,根據源表數據,我們將表拆分為:訂單事實表,用戶維度表,城市信息維度表,用戶等級維度表。
可以看出,在 Kimball 的維度建模中,不需要單獨維護數據關系表,因為關系已經冗余在事實表和維度表中。
① 支付成功訂單事實表訂單ID用戶ID商品ID商品總額下單時間支付金額支付類型OR110021002CO5435386．502021-04-04 11:12:0586．50支付寶OR110031003CO4325346．002021-04-04 14:16:050．00助力免費OR110041002CO34235210．002021-04-04 11:12:05210．00支付寶② 用戶維度表用戶ID姓名性別聯系方式地區用戶等級ID創建時間修改時間1001張翠花女15034951345031022021-04-03 13:11:012021-04-04 15:16:001002李建國男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河北張家口④ 用戶等級維度表用戶等級ID價值屬性1重要價值用戶2一般價值用戶3一般發展用戶
我們用圖的方式將以上表之間的關系簡單展示出來:
根據上圖,我們發現什么,這不就是典型的雪花模式嘛,其特點就是維度表可以擁有其他維度表。
三、兩種建模對比兩種建模方式特點
范式建模:通過上一小節的具體例子可以看出范式建模的優點:能夠結合業務系統的數據模型,較方便的實現數據倉庫的模型;同一份數據只存放在一個地方,沒有數據冗余,保證了數據一致性;數據解耦,方便維護。但同時也帶來了缺點:表的數量多;查詢時關聯表較多使得查詢性能降低。
維度建模:模型結構簡單,面向分析,為了提高查詢性能可以增加數據冗余,反規范化的設計,開發周期短,能夠快速迭代。缺點就是數據會大量冗余,預處理階段開銷大,后期維護麻煩;還有一個問題就是不能保證數據口徑一致性,原因后面有講解。
我們再來理解下維度建模:數據會抽取為事實-維度模型,維度就是看待問題的角度,從不同的角度看待某個問題,就會得出不同的結論,而要得到這個結論,就需要事實表中的度量,何為度量,就是事實表中數值類型的字段。
例:某公司的各個商品在全國各地市的銷售情況,維度就是全國的城市和各個商品,度量就是商品的單價,從不同的維度計算銷售額:如查看北京市酸奶的銷售額,上海市純牛奶的銷售額,這就是不同的維度組合方式。在限定的維度條件上,計算商品單價的總和,也就是 sum 度量值,即可得到我們想要的結果。
維度建模,就是依靠維度進行建模,但是如果維度設計的不合理,會不會帶來問題呢?
如果我們把省份當做一個單獨維度,城市當做一個維度,計算城市的人口數量。這時省份和城市都是單獨的維度,它們之間沒有了關系,就會出現以下情況:
廣東省 杭州市 1500
浙江省 廣州市 1200
這時會出現數據口徑不一致,最后導致數據結果不準確。而范式建模就不會出現這個問題,因為在范式建模中強調的就是實體-關系模型,所以省份和城市之間一定存在歸屬關系的,不會出現省份和城市口徑不一致的問題。
所以,范式建模能保證口徑的一致性,而維度建模不能!
建模方式對比
通過上一節的具體的例子以及兩種建模的特點,我們對比下兩種建模方式的不同:
特性KimballInmon開發周期短長開發難度小大維護難度大小數據要求針對具體業務站在企業角度精心設計否是緩慢變化維是否需要的人員少量專業團隊數據模型維度建模,星型模型、雪花模型實體-關系模型,準三范式設計
我們知道,互聯網公司的業務一般是周期比較短需求變化快,并且迭代頻繁,如果精心設計 Inmon 實體-關系的模式似乎并不能滿足快速迭代的業務需要。所以,互聯網公司更多場景下趨向于使用 Kimball 維度-事實的設計反而可以更快地完成任務。
四、兩種建模混合場景
通過以上幾個小節我們已經理解了范式建模與維度建模的思想以及它們之間的異同,優缺點。那么我們能不能將兩種建模方式混合使用呢,讓它們發揮各自最大的優勢。接下來我們一起來看下。
范式建模必須符合準三范式設計規范,如果使用混合建模,則源表也需要符合范式建模的限制,即源數據須為操作型或事務型系統的數據。通過ETL抽取轉換和加載到數據倉庫的ODS層,ODS層數據與源數據是保持一致的,所以ODS層數據也是符合范式設計規范的,通過ODS的數據,利用范式建模方法,建設原子數據的數據倉庫EDW,然后基于EDW,利用維度建模方法建設數據集市。
結合兩種建模方式的各自規范,混合建模按照“松耦合、層次化”的基本架構原則進行實施。混合數據倉庫架構方法主要包含以下關鍵步驟:業務需求分步構建、分層次保存數據、整合原子級的數據標準、維護一致性維度等。
最后
建模方式沒有好與壞之分,只有合適與不合適之分,在實際數倉建設中,需要靈活多變,不能全依賴建模理論,也不能不依賴。適時變通,才能建設一個好的數據倉庫。
分享
請輸入評論內容...
請輸入評論/評論長度6~500個字
