对于许多人来说数据库的概念可谓耳熟能详,但当涉及到数据仓库的时候大多数人可能就不是那么熟悉了。在本节中主要从数据仓库的概念(什么是数据仓库)、数据仓库如何构建、数据仓库提出的意义(数据仓库在实际中的应用)三个方面展开。
1.何为数据仓库(Data Warehouse)
William H. Inmon 曾给数据仓库一个定义:数据仓库是一个面向主题的(subject-oriented)、集成的(integrated)、时变的(time-variant)和非易失的(nonvolatile)数据集合,用于支持管理部门的决策过程。这个定义给我们提供了一个有关数据仓库的概括,同时也点名了数据仓库所具有的四个方面的特性:
- 面向主题:数据仓库关注的是决策管理者的数据建模与分析,所以它是围绕特定主题来组织数据而忽略与该主题不相关的数据信息,提供了一个主题的简明视图;
- 集成的:数据仓库中的数据往往来自于多个异构的数据源,通过采用数据预处理的方式将不同数据源中的数据集成为一个统一、一致的数据库;
- 时变的:数据仓库从历史的角度提供信息,数据仓库中的关键结构都隐式或显式地包含时间信息;
- 非易失:数据仓库总是物理地分别存放数据;这些数据源于操作环境下的应用数据。由于这个分离,数据仓库不需要事务处理、恢复和并发控制机制。通常,它只需要两种访问操作:数据的初始化装入和数据访问。
在继续下面的内容之前,我们需要先明白两个概念,也只有明白了这两个概念我们才能更好地理解数据仓库。这两个概念是OLTP(联机事务处理)、OLAP(联机分析处理)。当今的数据处理大致可以分成两大类:联机事务处理OLTP(on-line transaction processing在线事务处理,联机事务处理)、联机分析处理OLAP(On-Line Analytical Processing在线分析处理,联机分析处理)。
OLTP是传统的关系型数据库的主要应用,主要是基本的、日常的事务处理,例如银行交易。
OLAP是数据仓库系统的主要应用,支持复杂的分析操作,侧重决策支持,并且提供直观易懂的查询结果。
这两类系统在数据库的设计上是如此不同,甚至有些地方的设计是貌似相悖的。比如OLTP系统强调数据库的内在效率,强调内存各种指标的命中率,强调绑定变量,强调并发操作;而OLAP系统则强调数据分析,强调SQL执行时长,强调磁盘I/O,强调分区等。因为这些区别,在数据库设计的阶段,弄清楚数据库类型是至关重要的,只在在这个前提之下,才能够讨论数据库的具体设计,否则设计必须是盲目的,"皮之不存毛将焉附".
OLTP:用户并发数都很多,但他们只对数据库做很小的操作,数据库侧重于对用户操作的快速响应,这是对数据库最重要的性能要求。
对于一个OLTP来讲,数据库内存的设计显得很重要,如果数据库可以在内存中处理,那么数据库的性能无疑会提高很多。内存的设计通常是通过调整Oracle和内存相关的初始化参数来实现的,比较重要的几个是内存相关的参数,包括SGA的大小(Data Buffer,Shared Pool)、PGA大小(排序区,Hash区等),这些参一个OLTP系统里显得至关重要,OLTP系统是一个数据块变化非常频繁、SQL语句提交非常频繁的系统。对于数据块来说,应尽可能让数据块保存在内存当中,对于SQL来说,尽可能使用变量绑定技术来达到SQL的重用,减少物理I/O和重复的SQL解析,能极大地改善数据库性能。
常见的OLTP系统有:门票在线销售系统,银行交易等。
OLAP:相对于OLTP用户并发数较少,内存可以优化的余地较小,甚至觉得增加CPU处理速度和磁盘I/O速度是最直接的提高数据库性能的方式方式,但这将意味着成本的增加。实际上,用户对OLAP系统性能的期望远远没有对OLTP性能的期望那么高。在OLAP系统中,SQL的优化显得非常重要,分区技术在OLAP数据库中很重要。
OLAP是数据仓库系统的主要应用,支持复杂的分析操作,侧重决策支持,并且提供直观易懂的查询结果。
下表列出OLTP和OLAP之间的比较
|
OLTP |
OLAP |
用户 |
操作人员,低层管理人员 |
决策人员,高级管理人员 |
功能 |
日常操作处理 |
分析决策 |
DB设计 |
面向应用 |
面向主题 |
数据 |
当前的,最新的细节的,二维的分立的 |
历史的,聚集的,多维的,集成的,统一的 |
存取 |
读/写数十条记录 |
读上百万条记录 |
工作单位 |
简单的事务 |
复杂的查询 |
DB大小 |
100MB-GB |
100GB-TB |
由此可见传统的数据库提供的大多是日常事务处理记录,而面对复杂的查询所需要的数据往往难以提供。而且,鉴于操作数据库是为了已知任务和负载设计的,如使用主码索引和散列,检索特定的记录等。数据仓库中的查询大多需要特殊的基于多维视图的数据组织、存取方法和实现方法,倘若在操作型数据库的基础上进行复杂的数据查询不仅不能利用数据库中的数据组织结构而且很不方便,为此提出了数据仓库的概念用于针对决策过程中复杂查询与分析问题。
数据仓库以及OLAP操作都是基于多维度数据模型。在这种模型中它将数据看成是数据立方体形式。在关系数据库中实体-联系数据模型被广泛采用,这种数据模型比较适合联机事务处理。然而,数据仓库需要简明的、面向主题的模式,为此引入了多维度数据模型用于联机分析处理。多维模型主要以星形模式、雪花形模式或事实星座模型的形式存在。下图3-4、3-5以及3-6分别是星形模式、雪花形模式或事实星座模型构建的数据。
在星形模型中围绕在中间的是包含大批数据且不含冗余的中心表(事实表),由中心表向四周展开,为每一个维度构建一个附属表。雪花模式是星形的变种,其中某些维度是规范化的,因而将数据进一步分解到附加的表中。而事实星座表允许多个事实表之间共享一些附属表。
2.数据仓库的构建
在上一部分我们讨论了何为数据仓库,在这部分中我们着重讨论的是如何构建满足需求的数据仓库。在数据仓库设计过程中,四种不同的视角必须被考虑:自顶向下视图、数据源视图、数据仓库视图以及商务查询视图。
设计数据仓库的九个步骤
1)选择合适的主题(所要解决问题的领域)
2)明确定义fact表
3)确定和确认维
4)choosing the facts
5)计算并存储fact表中的衍生数据段
6)rounding out the dimension tables
7)choosing the duration of the database
8)the need to track slowly changing dimensions
9)确定查询优先级和查询模式。
技术上
硬件平台:数据仓库的硬盘容量通常要是操作数据库硬盘容量的2-3倍。通常大型机具有更可靠的性能和和稳定性,也容易与历史遗留的系统结合在一起;而PC服务器或UNIX服务器更加灵活,容易操作和提供动态生成查询请求进行查询的能力。选择硬件平台时要考虑的问题:是否提供并行的I/O吞吐?对多CPU的支持能力如何?
数据仓库DBMS:他的存储大数据量的能力、查询的性能、和对并行处理的支持如何。
网络结构:数据仓库的实施在那部分网络段上会产生大量的数据通信,需不需要对网络结构进行改进。
实现上
建立数据仓库的步骤
1)收集和分析业务需求
2)建立数据模型和数据仓库的物理设计
3)定义数据源
4)选择数据仓库技术和平台
5)从操作型数据库中抽取、转化、和装载数据到数据仓库
6)选择访问和报表工具
7)选择数据库连接软件
8)选择数据分析和数据展示软件
9)更新数据仓库
数据抽取、清理、转换、和移植
1)数据转换工具要能从各种不同的数据源中读取数据。
2)支持平面文件、索引文件、和legacyDBMS。
3)能以不同类型数据源为输入整合数据。
4)具有规范的数据访问接口
5)最好具有从数据字典中读取数据的能力
6)工具生成的代码必须是在开发环境中可维护的
7)能只抽取满足指定条件的数据,和源数据的指定部分
8)能在抽取中进行数据类型转换和字符集转换
9)能在抽取的过程中计算生成衍生字段
10)能让数据仓库管理系统自动调用以定期进行数据抽取工作,或能将结果生成平面文件
11)必须对软件供应商的生命力和产品支持能力进行仔细评估
通常来说,数据仓库采用的是三层结构,如图3-12。在系统的最底层是仓库数据服务器,通过实用程序将不同数据源的数据合并为一个一致的数据仓库;中间层是OLAP服务器,它将对多维数据的操作映射为标准的关系操作;顶层是前段客户层,主要包括查询和报表工具、分析工具或数据挖掘工具。
3.数据仓库应用
数据仓库主要有三种应用:信息处理、分析处理以及数据挖掘。
- 信息处理支持查询、基本的统计分析、并使用交叉表、表、图标或图进行报告。数据仓库信息处理的当前趋势是构建地代价的基于Web的访问工具,然后与Web浏览器进行集成;
- 分析处理支持基本的OLAP操作,包括切片与切块、下钻、上卷和转轴。一般,对于汇总和详细历史数据操作。与信息处理相比,联机分析处理的主要优势是它支持数据仓库数据的多维度分析;
- 数据挖掘支持知识返现,包括找出隐藏的模式和关联,构造分析模型,进行分类和预测,并使用可视化的工具提供挖掘结果。