深入对比数据仓库模式:Kimball vs Inmon

15

clipboard.png

概述

毛主席曾经说:实践若不以革命理论为指南,就会变成盲目的实践。

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%的时间会投入到数据挖掘上。

参考资料


如果觉得我的文章对你有用,请随意赞赏

你可能感兴趣的

14 条评论
比比比卡丘 · 2017年01月19日

为啥这么好的文章没人评呢,作者辛苦~

+2 回复

Exoulster · 2017年02月12日

同意,人工点赞!

+1 回复

wangpugood · 1月14日

另外对于中小型BI项目中的数仓以及乙方实施,因为业务需求和目的明确,就是为了BI或者报表提供数据,所以普遍采取kimball的设计方式,敏捷开发,周期短,易于维护和使用,但是可能会将stging层进行扩展,做一层ODS层。inmon的方法更适用于甲方自己技术部门来实施的企业级数仓项目。其实现在这两种方法也再趋同,kimball也会去做ods层,inmon方式会去做多维的集市。目的都是为了满足业务需求,不比纠结于具体的方法,能够满足业务需要同时也易于管理易于使用才是最好的方法

+1 回复

wangpugood · 1月14日

正如作者引用的文章,https://www.computerweekly.co...,kimball架构更适合于理解业务,理解需求,从需求出发来建设,最终交付用户会满意度较高。inmon架构更适合技术主导,但是最终难点在于接地气,如何交付需求方,培训需求方会用。。。BI项目如果乙方交付一个inmon架构的数仓,估计甲方会疯掉。

+1 回复

wangpugood · 1月14日

另外从这两个人上也可以看出来,bill inmon是数据仓库设计理论的先驱,更偏重技术方法。而kimball可以说是数仓bi实践的专家,更偏重于便于bi应用。现在的BI系统都是使用kimball的多维模型用于分析。所以殊途同归,最终的方案正如我上面所说更多是两者的结合,ODS->DW(3NF)->DM(多维)->olap宽表的形式。

+1 回复

晨磊 · 2017年04月25日

赞一个

回复

戴兵 · 2017年07月02日

赞一个

回复

Navy · 2017年08月10日

请问上面那个对比图是从哪里获取的,google吗? 谢谢。

回复

wffger · 2018年04月11日

按照这对比,甲骨文产品BIEE的rpd设计更适合哪种思路?

回复

0

不好意思,对Oracle 家产品不太了解。

HarryZhu 作者 · 2018年04月12日
zhaoxingming · 2018年05月21日

Kimball 模式从流程上看是是自底向上的,即从数据集市到数据仓库再到数据源
为什么数据源在最上层?不应该是从数据源到数据集市再到数据仓库吗?另外我看图也是这个过程。

回复

0

自上而下,自下而上指的是上下游。数据上游是数据源业务系统,数据下游是OLAP分析应用比如BI和报表

wangpugood · 1月14日
wangpugood · 1月14日

kimball的图画的有些问题吧?kimball的理论是,先建设数据集市,数据集市采取多维模型的方式来建设,然后通过主数据作为总线,来将各个集市串联起来成为逻辑上的数据仓库。但是你图中数据集市写的是3NF,并且没有体现出总线式的设计思路。下面的对比里,kimball的技术需求是入门级,感觉这个定义也不准确,多维数仓的设计更加多变,难度并不亚于inmon方式。

回复

wangpugood · 1月14日

现在的普遍设计方法,互联网公司由技术主导的企业数仓,按照inmon的方式进行设计和开发,主题域建模,从源业务系统作为起点构建大而全的企业数仓。但是在集市层采取kimball的设计方法,面向分析主题进行集市开发及olap cube开发,做多维结构的数据集市。这样的好处是,作为业务分析人员,多维模型更容易理解也更易于使用(关联少、逻辑简单)。对于技术部门,按照inmon方式设计企业数仓,也不需要做过多的需求调研便可以开展,更适合技术人员的思路。

回复

载入中...