数据仓库分层之辩

Posted 2021-04-24 songzi2016

前言，这篇文章最早见过是在2009年的某一个论坛上并保存了下来， 今天发出来读了一遍，不禁思考本质上这些年我们到底进步了什么？

数据仓库的分层可以算是数据仓库架构的子话题。在前段时间参与的一次讨论中，发现其中争论的焦点集中在每一层的作用、特点、是否有必要存在等问题。其中，大家虽然一致提到某些相关概念，但各方的理解却并非完全一致。例如对于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	实践证明非常有效，体现了数据仓库“面向主题” 的特点	按照事实表、维表来构建数据仓库、数据集市，和第三范式有冲突

写在结尾，当概念太多的时候，我们最应该做的就是要抛开那些容易混淆视听的名词，去探察其真正的意义所在。

Tag: