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

发布时间:2019-07-30 18:02:55 来源:FinanceR 关键词:kimball
kimball
原文标题:深入对比数据仓库模式:Kimball vs Inmon
原文发布时间:2016-08-21 17:27:32
原文作者:FinanceR。
如果您喜欢本文,请关注头条号【FinanceR】阅读更多相关文章。
如果您是本文作者,不希望我们转载此文,请联系我们删除。
kimball

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

概述

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

Kimball和Inmon是两种主流的数据仓库方法论,分别由 Ralph Kimbal大神 和 Bill Inmon大神提出,在实际数据仓库建设中,业界往往会相互借鉴使用两种开发模式。本文将详细介绍 Kimball 和 Inmon 理论在实际数据仓库建设中的应用与对比,通过数据仓库理论武装数据仓库实践。

什么是Kimball

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

概念

Kimball 模式从流程上看是是自底向上的,即从数据集市到数据仓库再到数据源(先有数据集市再有数据仓库)的一种敏捷开发方法。对于Kimball模式,数据源往往是给定的若干个数据库表,数据较为稳定但是数据之间的关联关系比较复杂,需要从这些OLTP中产生的事务型数据结构抽取出分析型数据结构,再放入数据集市中方便下一步的BI与决策支持。

流程

通常,Kimball都是以最终任务为导向。首先,在得到数据后需要先做数据的探索,尝试将数据按照目标先拆分出不同的表需求。其次,在明确数据依赖后将各个任务再通过ETL由Stage层转化到DM层。这里DM层数据则由若干个事实表和维度表组成。接着,在完成DM层的事实表维度表拆分后,数据集市一方面可以直接向BI环节输出数据了,另一方面可以先DW层输出数据,方便后续的多维分析。

Kimball往往意味着快速交付、敏捷迭代,不会对数据仓库架构做过多复杂的设计,在变换莫测的互联网行业,这种架构方式逐渐成为一种主流范式。

什么是Inmon

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

概念

Inmon 模式从流程上看是自顶向下的,即从数据源到数据仓库再到数据集市的(先有数据仓库再有数据市场)一种瀑布流开发方法。对于Inmon模式,数据源往往是异构的,比如从自行定义的爬虫数据就是较为典型的一种,数据源是根据最终目标自行定制的。这里主要的数据处理工作集中在对异构数据的清洗,包括数据类型检验,数据值范围检验以及其他一些复杂规则。在这种场景下,数据无法从stage层直接输出到dm层,必须先通过ETL将数据的格式清洗后放入dw层,再从dw层选择需要的数据组合输出到dm层。在Inmon模式中,并不强调事实表和维度表的概念,因为数据源变化的可能性较大,需要更加强调数据的清洗工作,从中抽取实体-关系。

流程

通常,Inmon都是以数据源头为导向。首先,需要探索性地去获取尽量符合预期的数据,尝试将数据按照预期划分为不同的表需求。其次,明确数据的清洗规则后将各个任务通过ETL由Stage层转化到DW层,这里DW层通常涉及到较多的UDF开发,将数据抽象为实体-关系模型。接着,在完成DW的数据治理之后,可以将数据输出到数据集市中做基本的数据组合。最后,将数据集市中的数据输出到BI系统中去辅助具体业务。

特征对比

特性

特性KimballInmon
数据摄取yesyes
stageyesyes
ETLyesyes
数据集市yesyes
商业需求yesyes
数据时间属性yesyes
数据仓库优先noyes
事实维度拆分yesno
关系表维护noyes
处理导向yesno
数据模型泛化noyes
精心设计noyes
缓慢变化维yesno
连续变化维noyes

优劣比较

特性KimballInmon
时间快速交付路漫漫其修远兮
开发难度
维护难度
技能要求入门级专家级
数据要求特定业务企业级

具体例子

相信一通理论之后可能还是能困惑,现在举一个具体的例子。

数据

股票交易为例:

(OLTP)原始数据包含了如下几张事务表:(真实场景字段设计更为复杂,此处已经简化)

  • 交易记录表:记录用户下单情况

交易记录ID用户ID交易ID交易单号标的CODE出价现价方向手数创建时间修改时间状态备注类型
111MR123456A1234569.09.51002016-10-10 10:58:002016-10-10 10:58:00未成交NULL创业板
211MR123456A1234569.08.92002016-10-10 11:00:002016-10-10 11:00:10已成交NULL创业板
312MR123457A12345610.110.22002016-10-10 14:00:002016-10-10 14:00:30已成交NULL创业板
  • 成交日志表:记录用户下单且成交的情况

成交日志ID用户ID外部单号交易记录ID标的CODE方向手数成交价格创建时间修改时间状态备注类型
11MR1234562A1234562008.92016-10-10 11:00:102016-10-10 11:00:10正常NULL创业板
21MR1234563A12345620010.12016-10-10 14:00:302016-10-10 14:00:30正常NULL创业板
  • 用户信息表

用户ID别名姓名联系方式性别身份号码资产账户ID是否开通创业板风险评级资产余额创建时间修改时间用户类型资产类型
1FinanceR张三123456789012345567890XSA12321312321312.002015-10-10 14:00:002016-10-10 14:00:00A现金账户

对比

如果是 Inmon 模式,我们需要将数据库拆分成 用户实体表、成交日志实体表、用户与成交日志关系表等多个子模块。

如果是 Kimball 模式,我们则需要将数据库拆分成 用户维度表、用户资产事实表、成交事实表。在Kimball模式中,我们不需要单独维护关系表,因为关系已经冗余在维度表和事实表中。

Inmon 模式:

用户实体表

用户ID别名姓名联系方式性别身份号码是否开通创业板风险评级资产余额创建时间修改时间用户类型资产类型
1FinanceR张三123456789012345567890X12321312.002015-10-10 14:00:002016-10-10 14:00:00A现金账户

成交关系表

成交ID用户ID
11
21

用户资产关系表

资产ID用户ID
SA1232131

Kimball 模式

用户维度表

用户ID别名姓名联系方式性别身份号码是否创业板风险评级ID创建时间修改时间用户类型ID资产ID
1FinanceR张三1234567890SA123213112015-10-10 14:00:002016-10-10 14:00:001SA123213

可以看到这里的用户维度表不包含业务交易信息,变化相对缓慢(静态)

而风险评级、用户类型也需要由风险评级维度表、用户类型维度表来维护

用户资产事实表

资产ID用户ID账户余额资产类型创建时间修改时间
SA123213112321312.00现金账户2016-10-10 14:00:002016-10-10 14:00:00

这里的用户资产事实表通常数据是由用户资产交易日志产生的,因为日志存在只插入,不更新的特点(快速增加、最细粒度)

总结

  • 对于大多数互联网公司由于需求的快速变化,处心积虑设计(Inmon)实体-关系的设计哲学似乎并不能满足快速迭代的业务需要。所以,更多场景下趋向于使用(Kimball)维度-事实的设计哲学反而可以更快地完成任务。

  • 数据仓库建设通常以日为粒度,将OLTP数据变化的不情况增量同步到数据仓库中。

  • 在数据仓库的实际工作中,80%的时间会花费在任务调度、数据清洗和业务梳理上,只有20%的时间会投入到数据挖掘上。


正文完,原文标题:深入对比数据仓库模式:Kimball vs Inmon
原文发布时间:2016-08-21 17:27:32
原文作者:FinanceR。

kimball kimball




本文关键词:kimball
猜你喜欢
相关推荐: