数据仓库分层

数据仓库的分层可以算是数据仓库架构的子话题。在前段时间参与的一次讨论中,笔者发现其中争论的焦点集中在每一层的作用、特点、是否有必要存在等问题。其中,大家虽然一致提到某些相关概念,但各方的理解却并非完全一致。例如对于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的维度建模理论,即按照事实表、维表来构建数据仓库、数据集市,也已经在很多实践中被证明是非常有效的方法。可这种建模方法和第三范式多少有点冲突。例如在维表中,不同粒度的数据放在一种表里面,即存在大量的数据冗余。但这种方法对数据仓库四大特点之一的“面向主题”,又是有利的。
如此看来,大家提到的方法似乎都是从不同角度去看,没有绝对的对错,只是在为维护自己的观点而争论。具体采用何种分层,还得看项目投资大小、数据量多少以及业务逻辑复杂程度而定吧。
说句题外话,或许当概念太多的时候,我们最应该做的就是要抛开那些容易混淆视听的名词,去探察其真正的意义所在。
  • 1
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值