深刻對比數據倉庫模式：Kimball vs Inmon

概述

毛主席曾經說：實踐若不以革命理論爲指南，就會變成盲目的實踐。

Kimball和Inmon是兩種主流的數據倉庫方法論，分別由 Ralph Kimbal大神 和 Bill Inmon大神提出，在實際數據倉庫建設中，業界每每會相互借鑑使用兩種開發模式。本文將詳細介紹 Kimball 和 Inmon 理論在實際數據倉庫建設中的應用與對比,經過數據倉庫理論武裝數據倉庫實踐。

什麼是Kimball

概念

Kimball 模式從流程上看是是自底向上的，即從數據集市到數據倉庫再到數據源(先有數據集市再有數據倉庫)的一種敏捷開發方法。對於Kimball模式，數據源每每是給定的若干個數據庫表，數據較爲穩定可是數據之間的關聯關係比較複雜，須要從這些OLTP中產生的事務型數據結構抽取出分析型數據結構，再放入數據集市中方便下一步的BI與決策支持。

流程

一般，Kimball都是以最終任務爲導向。首先，在獲得數據後須要先作數據的探索，嘗試將數據按照目標先拆分出不一樣的表需求。其次，在明確數據依賴後將各個任務再經過ETL由Stage層轉化到DM層。這裏DM層數據則由若干個事實表和維度表組成。接着，在完成DM層的事實表維度表拆分後，數據集市一方面能夠直接向BI環節輸出數據了，另外一方面能夠先DW層輸出數據，方便後續的多維分析。

Kimball每每意味着快速交付、敏捷迭代，不會對數據倉庫架構作過多複雜的設計，在變換莫測的互聯網行業，這種架構方式逐漸成爲一種主流範式。

什麼是Inmon

概念

Inmon 模式從流程上看是自頂向下的，即從數據源到數據倉庫再到數據集市的（先有數據倉庫再有數據市場）一種瀑布流開發方法。對於Inmon模式，數據源每每是異構的，好比從自行定義的爬蟲數據就是較爲典型的一種，數據源是根據最終目標自行定製的。這裏主要的數據處理工做集中在對異構數據的清洗，包括數據類型檢驗，數據值範圍檢驗以及其餘一些複雜規則。在這種場景下，數據沒法從stage層直接輸出到dm層，必須先經過ETL將數據的格式清洗後放入dw層，再從dw層選擇須要的數據組合輸出到dm層。在Inmon模式中，並不強調事實表和維度表的概念，由於數據源變化的可能性較大，須要更增強調數據的清洗工做，從中抽取實體-關係。

流程

一般，Inmon都是以數據源頭爲導向。首先，須要探索性地去獲取儘可能符合預期的數據，嘗試將數據按照預期劃分爲不一樣的表需求。其次，明確數據的清洗規則後將各個任務經過ETL由Stage層轉化到DW層，這裏DW層一般涉及到較多的UDF開發，將數據抽象爲實體-關係模型。接着，在完成DW的數據治理以後，能夠將數據輸出到數據集市中作基本的數據組合。最後，將數據集市中的數據輸出到BI系統中去輔助具體業務。

特徵對比

特性

特性	Kimball	Inmon
數據攝取	yes	yes
stage	yes	yes
ETL	yes	yes
數據集市	yes	yes
商業需求	yes	yes
數據時間屬性	yes	yes
數據倉庫優先	no	yes
事實維度拆分	yes	no
關係表維護	no	yes
處理導向	yes	no
數據模型泛化	no	yes
精心設計	no	yes
緩慢變化維	yes	no
連續變化維	no	yes

優劣比較

特性	Kimball	Inmon
時間	快速交付	路漫漫其修遠兮
開發難度	小	大
維護難度	大	小
技能要求	入門級	專家級
數據要求	特定業務	企業級

具體例子

相信一通理論以後可能仍是能困惑，如今舉一個具體的例子。

數據

股票交易爲例：

（OLTP）原始數據包含了以下幾張事務表：(真實場景字段設計更爲複雜，此處已經簡化)

• 交易記錄表：記錄用戶下單狀況

交易記錄ID

用戶ID

交易ID

交易單號

標的CODE

出價

現價

方向

手數

建立時間

修改時間

狀態

備註

類型

1

1

1

MR123456

A123456

9.0

9.5

買

100

2016-10-10 10:58:00

2016-10-10 10:58:00

未成交

NULL

創業板

2

1

1

MR123456

A123456

9.0

8.9

買

200

2016-10-10 11:00:00

2016-10-10 11:00:10

已成交

NULL

創業板

3

1

2

MR123457

A123456

10.1

10.2

賣

200

2016-10-10 14:00:00

2016-10-10 14:00:30

已成交

NULL

創業板

• 成交日誌表：記錄用戶下單且成交的狀況

成交日誌ID	用戶ID	外部單號	交易記錄ID	標的CODE	方向	手數	成交價格	建立時間	修改時間	狀態	備註	類型
1	1	MR123456	2	A123456	買	200	8.9	2016-10-10 11:00:10	2016-10-10 11:00:10	正常	NULL	創業板
2	1	MR123456	3	A123456	賣	200	10.1	2016-10-10 14:00:30	2016-10-10 14:00:30	正常	NULL	創業板

• 用戶信息表

用戶ID	別名	姓名	聯繫方式	性別	身份號碼	資產帳戶ID	是否開通創業板	風險評級	資產餘額	建立時間	修改時間	用戶類型	資產類型
1	FinanceR	張三	1234567890	女	12345567890X	SA123213	是	高	12321312.00	2015-10-10 14:00:00	2016-10-10 14:00:00	A	現金帳戶

對比

若是是 Inmon 模式，咱們須要將數據庫拆分紅 用戶實體表、成交日誌實體表、用戶與成交日誌關係表等多個子模塊。
若是是 Kimball 模式，咱們則須要將數據庫拆分紅 用戶維度表、用戶資產事實表、成交事實表。在Kimball模式中，咱們不須要單獨維護關係表，由於關係已經冗餘在維度表和事實表中。

Inmon 模式：

用戶實體表

用戶ID	別名	姓名	聯繫方式	性別	身份號碼	是否開通創業板	風險評級	資產餘額	建立時間	修改時間	用戶類型	資產類型
1	FinanceR	張三	1234567890	女	12345567890X	是	高	12321312.00	2015-10-10 14:00:00	2016-10-10 14:00:00	A	現金帳戶

成交關係表

成交ID	用戶ID
1	1
2	1

用戶資產關係表

資產ID	用戶ID
SA123213	1

Kimball 模式

用戶維度表

用戶ID	別名	姓名	聯繫方式	性別	身份號碼	是否創業板	風險評級ID	建立時間	修改時間	用戶類型ID	資產ID
1	FinanceR	張三	1234567890	女	SA123213	1	1	2015-10-10 14:00:00	2016-10-10 14:00:00	1	SA123213

能夠看到這裏的用戶維度表不包含業務交易信息，變化相對緩慢（靜態）
而風險評級、用戶類型也須要由風險評級維度表、用戶類型維度表來維護

用戶資產事實表

資產ID	用戶ID	帳戶餘額	資產類型	建立時間	修改時間
SA123213	1	12321312.00	現金帳戶	2016-10-10 14:00:00	2016-10-10 14:00:00

這裏的用戶資產事實表一般數據是由用戶資產交易日誌產生的，由於日誌存在只插入，不更新的特色（快速增長、最細粒度）

總結

• 對於大多數互聯網公司因爲需求的快速變化，處心積慮設計（Inmon）實體-關係的設計哲學彷佛並不能知足快速迭代的業務須要。因此，更多場景下趨向於使用（Kimball）維度-事實的設計哲學反而能夠更快地完成任務。

• 數據倉庫建設一般以日爲粒度，將OLTP數據變化的不狀況增量同步到數據倉庫中。

• 在數據倉庫的實際工做中，80%的時間會花費在任務調度、數據清洗和業務梳理上，只有20%的時間會投入到數據挖掘上。

參考資料

• Inmon vs. Kimball: Which approach is suitable for your data warehouse?

• Inmon vs. Kimball: Which approach is suitable for your data warehouse?

• Wikipedia: Datawarehouse

• Bill Inmon: Kimball methodology ignores the value of textual data

• OLAP和OLTP的區別

• The Data Warehouse Toolkit