ITPub博客

首页 > 大数据 > 数据挖掘 > 数据仓库分层之辩(ZT)

数据仓库分层之辩(ZT)

数据挖掘 作者:BI_Engineer 时间:2014-02-10 10:18:13 0 删除 编辑

数据仓库分层之辩

刘庆 2006-6-22

[@more@]

数据仓库的分层可以算是数据仓库架构的子话题。在前段时间参与的一次讨论中,笔者发现其中争论的焦点集中在每一层的作用、特点、是否有必要存在等问题。其中,大家虽然一致提到某些相关概念,但各方的理解却并非完全一致。例如对于ODS是什么、维度建模是什么等问题的解读,都是如此。

不妨想想看:数据从分散而异构的数据源中长途跋涉,到最终的报表、仪表盘、OLAP应用等等,让用户看到一致的结果,这是一个过程。记得以前有个矿泉水广告,说要经过N层的过滤才得到了那种水。而数据仓库也一样,从原来乱七八糟的数据到交付到用户手中的“纯净”数据,也需要这样一个过滤过程,需要各种不同的过滤装置。

这个过滤过程,我们可以称之为ETL;而那些过滤装置,就可以看作数据仓库的分层。从目前来看,还没有非常统一的分层方法,其中,Inmon和Kimball是最具代表性的两种分层方法。

Inmon与Kimball

在Inmon提出的CIF(Corporate Information Factory,企业信息工厂)中,他将ODS(Operational Data Store,操作型存储)、EDW(Enterprise Data Warehouse,企业数据仓库)、DM(DataMart,数据集市)区别开来,共分三层。相对于此,Kimball的总线架构强调多个数据集市合成了数据仓库,只是他们基于统一的维度而已。因此,总线架构的分层中,从数据源接口就直接到了DM了。

根据这两种思路,又可以衍生一些不同的方法。例如IBM就提出一种CDW的概念,叫做企业数据仓库层,这一层介于EDW和DM之间,起过渡作用(因为EDW和DM两层的建模理念是不同的)。

除了这些分层,大家都还认同一个Staging Area(集结地)的地方。这是用于ETL过程中数据的临时存储,可究竟这个区域是位于接口到ODS之间,还是ODS到DW之间,或是CDW到DM之间,并没有达成一致的意见。在笔者看来,既然它是用于ETL中间数据缓存的,那么,在以上每一层都会需要,它是一个每层共用的存储区域。

ODS层与DW层
对于ODS层,一般大家都能够认同它是一种操作型比较强的、未保留历史或者保留近期历史的数据。所谓操作型,是相对分析型而言的。后者多是汇总的、便于分析统计的结构。操作型的另一个特点就是经常会被更新,而分析型数据很少如此。然而,对于ODS的认识,也有不同。

常见的争议包括: ODS是否应该被最终用户访问?ODS存在的目的是仅仅供DW层获取经过清洗的数据,还是能够让用户从中得到统计报表?关于前一个问题,在笔者以前做经营分析的时候,就曾遇到这样的争议;关于后一个问题,如果让它仅仅具备前一项功能,倒是结构清晰、易于管理,是一种好的设计风格,但恐怕不能满足用户灵活的需求。而如果可以让用户查询统计,可能造成它统计的数据和DW统计的数据不一致。

对于DW层,一般大家都会认同,这是保留历史数据的地方。但它是按照第三范式还是维度建模呢?当然,最大的不同就是:是需要一个中心DW,还是一个由若干数据集市组成的“虚拟”的DW。至于DM层,对此基本有一致的认同,这是面向最终用户分析统计的,采用维度建模再好不过。

可因为对DW层建模方法的不同观点,因此也就出来了所谓CDW的提法。想想,如果DW是按照第三范式建模,而DM是按照维度建模的话,那么它们之间该如何过渡?看上去,CDW确实也有存在的必要,在这个区域,需要形成满足总线架构所需的一致性维度(Confirmed Dimension)和一致性事实(Confirmed Fact)。

但问题是,第三范式和维度建模难道就真得水火不相容?笔者更相信一个道理—架构中没有绝对的设计原则。所谓第三范式,只是指出一种理想的ER(实体-关系模型)设计模式,但实际做设计时,设计师大多会去做一些平衡,他们也许会说,“为了性能、应用方便,会考虑适当的冗余。”可这适当冗余不也就破坏了第三范式吗?而且这个“适当”谁也说不准是多少。因此,可以理解EDW并不是绝对的第三范式,而所谓维度建模又能够和第三范式有多少冲突呢?在其本身概念里面,星型模式是一种不太符合第三范式的ER结构,但只是不“太”,如果改成雪花模式,是不是也就是第三范式了呢?

名词与真义
具体要采用哪种分层方法还得视项目大小而言。对于大项目,或是大的集成商来实施,恐怕多会采用复杂的分层方法。其实分层越细,每层的功能也就越单一,它们之间的耦合程度也就越单一。当然这也是需要衡量的,因为分层多了,ETL过程自然也就复杂,那对于数据质量的控制也就变得麻烦——在多个层里面可能都存在同样意义的数据,需要保证它们是一致的。

像IBM、NCR这样的厂商,他们大多走的Inmon路线。经过多年的经验总结,都已有自己的企业概念模型,这也非常适合走分层明确、具有中心数据仓库的路线。在Inmon的体系中,EDW是按照第三范式建模的。之所以要强调这种思想,是因为第三范式能够让数据模型变得简洁、高度一致性。对数据仓库的一个目的——统一口径(Single Version of Truth),是非常有帮助的。

另一方面,Kimball的维度建模理论,即按照事实表、维表来构建数据仓库、数据集市,也已经在很多实践中被证明是非常有效的方法。可这种建模方法和第三范式多少有点冲突。例如在维表中,不同粒度的数据放在一种表里面,即存在大量的数据冗余。但这种方法对数据仓库四大特点之一的“面向主题”,又是有利的。

如此看来,大家提到的方法似乎都是从不同角度去看,没有绝对的对错,只是在为维护自己的观点而争论。具体采用何种分层,还得看项目投资大小、数据量多少以及业务逻辑复杂程度而定吧。

说句题外话,或许当概念太多的时候,我们最应该做的就是要抛开那些容易混淆视听的名词,去探察其真正的意义所在。

数据仓库分层比较表
分层方法具体分层 优点缺点
Inmon数据源接口—ODS—EDW—DM按照第三范式建模,可得到统一口径衍生出更多分层,意见不统一
Kimba数据源接口—DM实践证明非常有效,体现了数据仓库“面向主题” 的特点按照事实表、维表来构建数据仓库、数据集市,和第三范式有冲突

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/29478447/viewspace-1078692/,如需转载,请注明出处,否则将追究法律责任。

上一篇: 没有了~
请登录后发表评论 登录
全部评论

注册时间:2014-02-10

  • 博文量
    3
  • 访问量
    6311