OLTP OLAP，
数据仓库基本概念作者：王闯舟 NCR公司上海办事处 来源：互联网
摘要 IT人 就数据仓库技术而言,目前仍存在着许多认识上的误区,本文将着重介绍一些数据仓库的基本概念以及建立数据仓库时应该注意的一些情况。随着计算机技术的迅速发展,信息处理技术也得到了长足的发展,从70年代中期的MIS系统发展到现代的数据仓库(Data Warehouse)技术。许多厂商都在开发自已的数据仓库解决方案,并通过各种渠道大力推广。但就数据仓库技术而言,目前仍存在着许多认识上的误区,本文将着重介绍一些数据仓库的基本概念以及建立数据仓库时应该注意的一些情况。
数据仓库不是现成软件或硬件产品
对数据仓库最大的误解可能是把它当作一个现成的可以直接买来使用的产品。事实上,数据仓库和数据库不同,它不是现成的软件或者硬件产品。比较确切地说,数据仓库是一种解决方案,是对原始的操作数据进行各种处理并转换成有用信息的处理过程,用户可以通过分析这些信息从而作出策略性的决策。因此,在很多场合,我们也把数据仓库系统称为决策支持系统。由于这个原因,数据仓库的用户不是类似银行柜员的终端操作人员,而是针对各个业务部门的用户和有关决策人员。因此,数据仓库的用户比传统的OLTP(联机事务处理:On-line Transaction Processing)用户少得多。
OLTP与OLAP
OLTP系统也称为生产系统,它是事件驱动、面向应用的,比如银行的储蓄系统就是一个典型的OLTP系统。
OLTP的基本特点是:
·对响应时间要求非常高;
·用户数量非常庞大,主要是操作人员;
·数据库的各种操作基于索引进行。
OLAP(联机分析处理:On-line Analytical Processing)是基于数据仓库的信息分析处理过程,是数据仓库的用户接口部分。OLAP系统是跨部门、面向主题的,其基本特点是：
·基础数据来源于生产系统中的操作数据(Operational Data);
·响应时间合理;
·用户数量相对较小,其用户主要是业务决策与管理人员;
·数据库的各种操作不能完全基于索引进行。
OLAP工具是整个数据仓库解决方案中不可缺少的一部分,目前市场上有许多这类成熟的产品,如NCR的QueryMan、Andyne软件公司的GQL(Graphic Query Language)、Brio Technology公司的Brio Query等等。这些产品大都运行在Windows环境下,具有友好的用户
界面,通过ODBC驱动程序和TCP/IP协议与数据库系统相连,是一种典型的Client/Server结构。
这些OLAP工具的特点是用户不需要掌握很深的SQL知识就可使用。用户提出问题后,这些工具能自动加以分析,根据系统的数据库模型产生SQL语句,通过ODBC接口向服务器数据库提出交易请求,然后将主机返回的结果以用户指定的方式显示出来。它们一般在本地
维护一个多维数据库,把结果保存在本地库中,因此可以离线工作。
数据仓库系统的查询特点
数据仓库和生产系统不同,它保存的是历史数据,一般不作修改,因此用户针对数据仓库的交易主要是查询。数据仓库的查询和生产系统的查询有很大的区别。
针对生产系统的查询都很简单,一般不会使用表连接操作(Table Join),每次返回的数据量很小,这类问题的特点是"知道自已要找什么",例如根据银行帐号查余额。这类操作都是基于索引进行的,如帐号可以作为储蓄系统的索引。由于这些特点,数据库大小对系统性能影响不大。
针对数据仓库系统的查询大都非常复杂,主要有两种:一种以报表为主,从数据库中产生各种形式的业务报表。这种查询是预先规划好的(Pre-defined Query);另一种则是随机的、动态的查询(Ad-Hoc Query),对查询的结果也是不能预料的。例如世界上最大的连锁超市集团Wal*Mart曾经发现在周未的时候啤酒与一次性尿布的销售量很大,有关人员通过对数据仓库中的信息进行分析,寻找这两种商品的共同点,结果发现很多父亲在购买啤
酒时喜欢顺便捎些尿布,于是他们把这两种商品放在很近的位置,方便父亲们购买,结果这两种商品的销售量都增加了很多。
数据仓库中的查询由于其复杂性,会经常使用多表的联接、累计、分类、排序等操作,这些大都要对整个表进行搜索。每次查询返回的数据量一般很大,对于Ad-Hoc查询而言,经常需要根据上次查询的结果进行进一步的搜索,这个过程常称为数据挖掘。
根据这些特点,数据库大小对数据仓库系统的性能影响很大。当数据仓库投入使用后,各业务部门的要求会越来越多,使得数据仓库中数据量的增长速度很快,因此设计数据仓库时,系统的可扩展能力是必须考虑的重要因素之一。
系统的并行处理能力是另一个要考虑的重要因素。因为查询的复杂性,每个查询将占用很多的系统资源,如果并行处理能力不强,当多个用户同时发出交易请求时,响应时间可能长得不可容忍。
详细数据与小结数据
下图（注：图未能找到，ITHao123.COM深表抱歉，下同）可以清楚地说明详细数据(Detail Data)与小结数据(Summary Data)的作用和区别。左边一列记载了扫描仪在每个连锁店每天的交易细节(数量、交易时间、交易地点、类型、客户、售货员等),中间一列记录了扫描仪每天按连锁店分类的交易汇总情况,右边一列记录了扫描仪每周按连锁店分类的交易汇总情况。由此可见,小结可以是多种层次的。
@@0211800.JPG;图1@@
详细数据中包含了许多有价值的信息,经小结处理后,可能会丢失这些信息。举例来说,市场行销人员规划在某个星期二和星期三进行扫描仪的产品推销活动(如采取一些优惠措施),如果他们只知道每周扫描仪的销售量,怎么能看出这个推销活动的效果?又如何来分析客户的购买行为?
由此可见,为了更准确地分析市场发展规律,提高企业的竟争优势,数据仓库中应该存储尽可能详细的数据,为决策提供更加可靠的信息。如前面提到的Wal*Mart集团,其全世界所有连锁店每天的交易数据都会通过卫星传送到在美国的中央数据仓库,如果顾客买了
两枝同样型号但不同颜色的铅笔,在数据仓库中都是两条记录,因为据此可以分析对不同颜色铅笔的需求规律,从而确定货存量等。
既然详细数据的作用如此大,为什么还要对其进行小结处理呢?主要原因是:
1.数据仓库的引擎(数据库系统)不适合处理大量的数据,前面已经说明,在数据仓库中数据量大小对系统整体性能影响很大,而能在OLTP系统中处理TB级数据并不能代表在数据仓库中也能处理TB级数据。
2.降低存储系统投资。在以前,存储介质是非常昂贵的。
3.降低MIPS投资。尽管计算机性能已经有了很大提高,开放系统的价格一降再降,但直到现在,专用大型主机的MIPS仍然非常昂贵。
由此可见,选择能支持TB级数据仓库的数据库系统和在开放环境下建立数据仓库是非常重要的。
数据仓库与数据集市
数据集市(Data Mart)也是当前非常热门的一个术语,一种比较常见的误解是认为它与数据仓库的差别只是数据量的大小而已。事实上,数据仓库是企业级的,能为整个企业各个部门的运行提供决策支持手段;而数据集市是部门级的,一般只能为某个局部范围内的管理人员服务。有些供应商也称之为部门级数据仓库(Departmental Data Warehouse)。
数据集市有两种,即独立的数据集市(Independent Data Mart)和从属的数据集市(Dependent Data Mart)。从下图可以清楚地看到数据仓库、从属数据集市与独立数据集市之间的关系:
@@0211801.JPG;图2@@
图中左边表示的是企业数据仓库的逻辑结构。我们看到,其中的数据来自于各生产系统,把它们的操作数据按照企业数据仓库物理模型结构的定义转换过来。采用这种中央数据仓库的做法,可以保证现实世界的一致性。
中间表示的是从属数据集市的逻辑结构。所谓从属,是指它的数据直接来自于中央数据仓库。显然,这种结构仍能保持数据的一致性。一般情况下,为那些访问数据仓库十分频繁的关键业务部门建立从属的数据集市,这样可以很好地提高查询的反应速度。另外一个原因是:在设计数据仓库的逻辑模型时,为了保证结构清楚,降低数据冗余度,一般都按第三范式(3NF:Third Normal Form)来设计。但在物理实现时,出于性能方面的考虑,常常要作非正则处理(De-Normalize),使得中央库的复杂性增加,不易维护,数据冗余大。因此,当中央数据仓库十分庞大时,我们一般不对中央库作非正则处理,而是建立一个从属数据
集市,对它作非正则处理,这样既能提高响应速度,又能保证整个系统的易维护性。其代价是增加了对数据集市的投资。
右边描述了独立数据集市的逻辑结构,它的数据直接来源于各生产系统。许多企业在计划实施数据仓库时,往往出于投资方面的考虑,最后建成的就是这种结构的独立数据集市,用来解决个别部门比较迫切的决策问题。从这个意义上讲,它和企业数据仓库除了在数据量大小和服务对象上有所区别外,逻辑结构并无多大区别,也许这是把数据集市称为部门数据仓库的主要原因。关键问题在于:随着需求的增加,数据量也会迅速增加,系统规模将迅速扩大,是把原来的独立数据集市扩展成为上图中左边的企业数据仓库呢?还是为各部门分别建立独立的数据集市形成如下图所示的繁杂系统?
@@0211802.JPG;图3@@
在这种结构中,IT部门必须设计多个数据转换程序,把各生产系统的操作数据转换到每个独立数据集市中,以便保持数据的一致性。显然,这种策略将使整个系统变得非常复杂难于维护,在投资方面更是得不偿失,因为硬件系统的投资成比例增加,软件方面的投资和维护方面的投资则成指数形式增加。
既然这种分布式的独立数据集市结构有诸多问题,为什么还有一些企业仍在这样做呢?回答是"不得已而为之"。因为硬件平台或者数据库在扩展性方面限制太多,并行处理能力不够,无法处理大量的数据,最后只能形成这种尴尬局面。
如何衡量数据仓库引擎
从前面的分析我们可以看到,作为数据仓库引擎的数据库管理系统,其性能的优劣对整个数据仓库解决方案的成功实施起着举足轻重的作用。那么,如何来衡量一个数据库管理系统是否适合作为数据仓库引擎呢?
大家可能都知道,在国际上有一个叫TPC的组织。TPC是事务处理委员会(Transaction Processing Performance Council)的英文缩写,是一个国际性的组织,由45个会员公司组成,IBM、Microsoft、NCR、NEC、DEC、HP、SUN等跨国公司都是其会员。TPC专门负责为各种开放平台在不同类型的应用上制定一个统一、公正的测试标准。在国际上,对于IT行业的供应商来说,进行TPC规定的测试是它们进入各领域的敲门砖。
对于OLTP系统,衡量其数据库性能的主要指标是TPC-C,这里不作分析。对于数据仓库系统,衡量其数据库性能的主要指标则是TPC-D。主要有三方面的数据需要考虑:
QppD:这个数据描述了系统的查询处理能力,它是Query Processing Power D的缩写(D表示这个结果是按照TPC-D标准测得的,下同)。
QthD:是Query Throughput D的缩写,即流量测试结果,描述了系统在多个用户同时进行查询时的处理能力。换言之,它也充分代表了系统的并行处理能力。
QphD:是Query Price-Performance D的缩写,即性能价格比。
显然,前面两个指标的数据越大越好,而最后一个则越小越好。当然,首先要考虑的应该是能否满足业务上的需求。关于TPC的介绍已经很多,这里不再重复。
各家供应商的TPC-D值以及TPC-D的详细描述可以从TPC在Internet的主页上找到,其Web地址为:http://www.tpc.org/。另外,也可以从Microsoft、IDEAS等公司的主页上找到TPC-D的测试结果。
需要作些说明的是流量测试结果。尽管它描述了系统处理并发查询请求的能力,但并非所有厂商的流量测试都是在多用户状态下进行的,因为TPC-D给了供应商们一个选择:直接进行多用户状态下的流量测试;或者先在单用户状态下进行测试,然后利用测得的处理能力指标QppD和流量指标的计算公式来"计算"出QthD。如何区分这两种测试结果呢?TPC-D的测试概要(Executive Summary)中清楚地说明了在作流量测试时的STREAM数目。STREAM数实际上代表了同时递交查询请求的用户个数。如果是单用户状态下进行测试,则只
能发现一个STREAM,即STREAM00。到目前为止,还只有NCR公司的Teradata数据库系统是在多用户状态下进行流量测试的。
TPC-D的测试是在不同的数据库级别上进行的,主要可供参考的是100GB、300GB和1000GB三个级别上的测试结果。下面两个表是从Microsoft公司的Web页面上下载的300GB和1000GB两个级别的TPC-D测试结果。我们看到,在1000GB级别上,目前还只有NCR公司宣布了其TPC-D指标,该结果是在其WorldMark系列服务器和Teradata数据库系统上进行的。
@@0211803.JPG;图4 300GB TPC-D测试结果@@
@@0211804.JPG;图4 1000GB测试结果@@