1.1 什么是数据仓库

数据仓库的概念可以追溯到20世纪80年代,当时IBM的研究人员开发出了“商业数据仓库”。本质上,数据仓库试图提供一种从操作型系统到决策支持环境的数据流架构模型。数据仓库概念的提出,是为了解决和这个数据流相关的各种问题,主要是解决多重数据复制带来的高成本问题。在没有数据仓库的时代,需要大量的冗余数据来支撑多个决策支持环境。在大组织里,多个决策支持环境独立运作是典型的情况。尽管每个环境服务于不同的用户,但这些环境经常需要大量相同的数据。处理过程收集、清洗、整合来自多个数据源的数据,并为每个决策支持环境做部分数据复制。数据源通常是早已存在的操作型系统,很多是遗留系统。此外,当一个新的决策支持环境形成时,操作型系统的数据经常被再次复用。用户访问这些处理后的数据。

1.1.1 数据仓库的定义

数据仓库之父Bill Inmon在1991年出版的Building the Data Warehouse 一书中首次提出了被广为认可的数据仓库定义。Inmon将数据仓库描述为一个面向主题的、集成的、随时间变化的、非易失的数据集合,用于支持管理者的决策过程。这个定义有些复杂并且难以理解。下面我们将它分解开来进行说明。

● 面向主题

传统的操作型系统是围绕组织的功能性应用进行组织的,而数据仓库是面向主题的。主题是一个抽象概念,简单地说就是与业务相关的数据的类别,每一个主题基本对应一个宏观的分析领域。数据仓库被设计成辅助人们分析数据。例如,一个公司要分析销售数据,就可以建立一个专注于销售的数据仓库,使用这个数据仓库,就可以回答类似于“去年谁是我们这款产品的最佳用户”这样的问题。这个场景下的销售,就是一个数据主题,而这种通过划分主题定义数据仓库的能力,就使得数据仓库是面向主题的。主题域是对某个主题进行分析后确定的主题的边界,如客户、销售、产品都是主题域的例子。

● 集成

集成的概念与面向主题是密切相关的。还用销售的例子,假设公司有多条产品线和多种产品销售渠道,而每个产品线都有自己独立的销售数据库。此时要想从公司层面整体分析销售数据,必须将多个分散的数据源统一成一致的、无歧义的数据格式后,再放置到数据仓库中。因此数据仓库必须能够解决诸如产品命名冲突、计量单位不一致等问题。当完成了这些数据整合工作后,该数据仓库就可称为是集成的。

● 随时间变化

为了发现业务变化的趋势、存在的问题,或者新的机会,需要分析大量的历史数据。这与联机事务处理(OLTP)系统形成鲜明的对比。联机事务处理反应的是当前时间点的数据情况,要求高性能、高并发和极短的响应时间,出于这样的需求考虑,联机事务处理系统中一般都将数据依照活跃程度分级,把历史数据迁移到归档数据库中。而数据仓库关注的是数据随时间变化的情况,并且能反映在过去某个时间点的数据是怎样的。换句话说,数据仓库中的数据是反映了某一历史时间点的数据快照,这也就是术语“随时间变化”的含义。当然,任何一个存储结构都不可能无限扩展,数据也不可能只入不出地永久驻留在数据仓库中,它在数据仓库中也有自己的生命周期。到了一定时候,数据会从数据仓库中移除。移除的方式可能是将细节数据汇总后删除、将老的数据转储到大容量介质后删除和直接物理删除等。

● 非易失

非易失指的是,一旦进入到数据仓库中,数据就不应该再有改变。操作型环境中的数据一般都会频繁更新,而在数据仓库环境中一般并不进行数据更新。当改变的操作型数据进入数据仓库时会产生新的记录,这样就保留了数据变化的历史轨迹。也就是说,数据仓库中的数据基本是静态的。这是一个不难理解的逻辑概念。数据仓库的目的就是要根据曾经发生的事件进行分析,如果数据是可修改的,将使历史分析变得没有意义。

除了以上四个特性外,数据仓库还有一个非常重要的概念就是粒度。粒度问题遍布于数据仓库体系结构的各个部分。粒度是指数据的细节或汇总程度,细节程度越高,粒度级别越低。例如,单个事务是低粒度级别,而全部一个月事务的汇总就是高粒度级别。

数据粒度一直是数据仓库设计需要重点思考的问题。在早期的操作型系统中,当细节数据被更新时,几乎总是将其存放在最低粒度级别上;而在数据仓库环境中,通常都不这样做。例如,如果数据被装载进数据仓库的频率是每天一次,那么一天之内的数据更新将被忽略。

粒度之所以是数据仓库环境的关键设计问题,是因为它极大地影响数据仓库的数据量和可以进行的查询类型。粒度级别越低,数据量越大,查询的细节程度越高,查询范围越广泛,反之亦然。

大多数情况下,数据会以很低的粒度级别进入数据仓库,如日志类型的数据或单击流数据,此时应该对数据进行编辑、过滤和汇总,使其适应数据仓库环境的粒度级别。如果得到的数据粒度级别比数据仓库的高,那将意味着在数据存入数据仓库前,开发人员必须花费大量设计和资源来对数据进行拆分。

1.1.2 建立数据仓库的原因

现在你应该已经熟悉了数据仓库的概念,那么数据仓库里的数据从哪里来呢?通常数据仓库的数据来自各个业务应用系统。业务系统中的数据形式多种多样,可能是Oracle、MySQL、SQL Server等关系数据库里的结构化数据,可能是文本、CSV等平面文件或Word、Excel文档中的非结构化数据,还可能是HTML、XML等自描述的半结构化数据。这些业务数据经过一系列的数据抽取、转换、清洗,最终以一种统一的格式装载进数据仓库。数据仓库里的数据作为分析用的数据源,提供给后面的即席查询、分析系统、数据集市、报表系统、数据挖掘系统等。

从以上描述可以看到,从存储的角度看,数据仓库里的数据实际上已经存在于业务应用系统中,那么为什么不能直接操作业务系统中的数据用于分析,而要使用数据仓库呢?实际上在数据仓库技术出现前,有很多数据分析的先驱者已经发现,简单的“直接访问”方式很难良好工作,这样做的失败案例数不胜数。下面列举一些直接访问业务系统无法工作的原因:

● 某些业务数据由于安全或其他因素不能直接访问。

● 业务系统的版本变更很频繁,每次变更都需要重写分析系统并重新测试。

● 很难建立和维护汇总数据来源于多个业务系统版本的报表。

● 业务系统的列名通常是硬编码,有时仅仅是无意义的字符串,这让编写分析系统更加困难。

● 业务系统的数据格式,如日期、数字的格式不统一。

● 业务系统的表结构为事务处理性能而优化,有时并不适合查询与分析。

● 没有适当的方式将有价值的数据合并进特定应用的数据库。

● 没有适当的位置存储元数据。

● 用户需要看到的显示数据字段,有时在数据库中并不存在。

● 通常事务处理的优先级比分析系统高,所以如果分析系统和事务处理运行在同一硬件之上,分析系统往往性能很差。

● 有误用业务数据的风险。

● 极有可能影响业务系统的性能。

尽管需要增加软硬件的投入,但建立独立数据仓库与直接访问业务数据相比,无论是成本还是带来的好处,这样做都是值得的。随着处理器和存储成本的逐年降低,数据仓库方案的优势更加明显,在经济上也更具可行性。

无论是建立数据仓库还要实施别的项目,都要从时间、成本、功能等几个角度权衡比较,认真研究一下是否真正需要一个数据仓库,这是一个很好的问题。当你的组织很小,人数很少,业务单一,数据量也不大,可能你真的不需要建立数据仓库。毕竟要想成功建立一个数据仓库并使其发挥应有的作用还是很有难度的,需要大量的人、财、物力,并且即便花费很大的代价完成了数据仓库的建设,在较短一段时间内也不易显现出价值。在没有专家介入而仅凭组织自身力量建立数据仓库时,还要冒相当大的失败风险。但是,当你所在的组织有超过1000名雇员,有几十个部门的时候,它所面临的挑战将是完全不同的。在这个充满竞争的时代,做出正确的决策对一个组织至关重要。而要做出最恰当的决策,仅依据对孤立维度的分析是不可能实现的。这时必须要考虑所有相关数据的可用性,而这个数据最好的来源就是一个设计良好的数据仓库。

假设一个超市连锁企业,在没有实现数据仓库的情况下,最终该企业会发现,要分析商品销售情况是非常困难的,比如哪些商品被售出,哪些没有被售出,什么时间销量上升,哪个年龄组的客户倾向于购买哪些特定商品等这些问题都无从回答。而给出这些问题的正确答案正是一个具有吸引力的挑战。这只是第一步,必须要搞清楚一个特定商品到底适不适合18~25岁的人群,以决定该商品的销售策略。一旦从数据分析得出的结论是销售该商品的价值在降低,那么必须实施后面的步骤分析在哪里出了问题,并采取相应的措施加以改进。

在辅助战略决策层面,数据仓库的重要性更加凸显。作为一个企业的经营者或管理者,他必须对某些问题给出答案,以获得超越竞争对手的额外优势。回答这些问题对于基本的业务运营可能不是必需的,但对于企业的生存发展却必不可少。下面是一些常见问题的例子:

● 如何把公司的市场份额提升5%?

● 哪些产品的市场表现不令人满意?

● 哪些代理商需要销售政策的帮助?

● 提供给客户的服务质量如何?哪些需要改进?

回答这些战略性问题的关键一环就是数据仓库。就拿“提供给客户的服务质量如何?”这一问题来说,这是管理者最为关心的问题之一。我们可以把这一问题分解成许多具体的小问题,比如第一个问题是,在过去半年中,收到过多少用户反馈?可以在数据仓库上发出对应的查询,并对查询结果进行分析。之所以能够这样做,是因为数据仓库中含有每一条用户反馈信息。

你可能已经想到了,第二个问题自然就是,在这些用户反馈当中,给出“非常满意”“一般”“不满意”的人数分别有多少?下面的问题就是客户所强调的需要改进的地方和广受批评的地方是哪些?这在数据仓库的用户反馈信息中也有一列来表示,它也能从一个侧面反映出客户关心的问题是哪些。以上这三个问题的答案联合在一起,就可以得出客户服务满意度的结论,并且准确定位哪些地方急需改进。

下面简单总结一下使用数据仓库的好处:

● 将多个数据源集成到单一数据存储,因此可以使用单一数据查询引擎展示数据。

● 缓解在事务处理数据库上因执行大查询而产生的资源竞争问题。

● 维护历史数据。

● 通过对多个源系统的数据整合,使得在整个企业的角度存在统一的中心视图。

● 通过提供一致的编码和描述,减少或修正坏数据问题,提高数据质量。

● 一致性地表示组织信息。

● 提供所有数据的单一通用数据模型,而不用关心数据源。

● 重构数据,使数据对业务用户更有意义。

● 向复杂分析查询交付优秀的查询性能,同时不影响操作型系统。

● 开发决策型查询更简单。