2010-05-02
1 引 言 联机分析处理(On-Line Analytical Processing,OLAP)技术支持决策者围绕决策主题对数据进行多角度、多层次的分析。OLAP通常建立在数据仓库之上,数据仓库的目的是为了支持经营H管理中的决策过程,存储在其中的数据既有企业内部的,也有企业外部的;既有当前的,更有历史的。 来自不同数据源的数据经过提炼、加工后再加载到数据仓库,不管这些数据在物理上是怎么组织的,从逻辑上看它们是围绕一个个决策主题的多维数据的集合。这种数据结构为OLAP实施多维数据分析提供了理想的环境;而OLAP作为一种多维查询和分析工具,是数据仓库功能的自然扩展,也是数据仓库中大量数据资源得以有效利用的重要保障。 一种OLAP产品的成功与否,也不仅仅限于OLAP技术的本身,更取决于它与各种大型数据仓库系统的集成度,取决于它的开放度即大多数第三方软件厂商对它的接受和利用程度。本文将着重分析OLAP服务器的体系结构(见图2)以及服务器对客户端的支持,最后还讨论客户端的一些常见形式。 图1 开放的OLAP外部体系结构 2 OLAP在数据仓库系统中的地位 OLAP技术的著名站点“OLAP Report”曾经统计过,OLAP的相关产品数量正以每年40%的速度增长,从产品的发展趋势来看,OLAP产品的体系结构必须必须具有足够的开放性:首先OLAP服务器要能够方便的与现有的大型数据仓库很好的集成,并且OLAP服务器在向客户端提供的支持上应该积极寻求与第三方软件特别是决策支持软件的开发商的良好合作关系。 这里实际上对OLAP服务器的体系结构提出了一个“承上启下”的要求,在数据仓库的4层架构中,OLAP层是OLAP服务器的理想位置,下层有数据仓库层的强大支持,上层又可以有灵活的个体层实现,OLAP服务器的各种功能集中在OLAP层实现,这样的OLAP服务器能够灵活的与现有的数据仓库系统结合,并且能够为各决策支持软件开发商提供方便、透明的接口,这也是OLAP的开放性的体现。 3 OLAP服务器的体系结构 在这一节中阐述OLAP服务器的组成结构,每一部分的功能及相互间的关系。 3.1 现有的OLAP技术类型 ·Relational OLAP(ROLAP) 基于关系数据库的OLAP实现——ROLAP以关系数据库为核心,以关系型结构进行多维数据的表示和存储。ROLAP建立在技术已经相当成熟的关系数据库管理系统上,灵活性和处理大规模数据的能力比较突出,但数据库中存放了大量的细节数据和相对较少的综合数据,OLAP的效率较低。 ·Multidimensional OLAP(MOLAP) MOLAP以多维数据库为核心,存储预处理的多维立方体数据!对多维概念表达清楚,占用的存储空间较小,而且数据的综合速度高,但多维数据库管理系统缺乏标准,管理大规模数据库的能力不够强大。 ·Hybrid OLAP(HOLAP) HOLAP集成了ROLAP和MOLAP的优点,使ROLAP和MOLAP在一个集成的环境中相互辅助共同工作。HOLAP、既有处理大规模数据的能力,又可以提供的响应速度,并且还可以配合以多种优化策略,调节ROLAP和MOLAP的比重等一系列参数,实现OLAP应用的最优化。 图2 OLAP服务器的体系结构 3.2 数据的建模 开放的OLAP体系结构一定要有包容性、灵活性以适应迅速建立新的数据集市或重定义原有集市的需要、OLAP的建模是一个持续的、交互的、循环的过程,在建模的开始就知道所有可能需要的分析模式是不可能的,所以必须提供快速调整分析模式以适应多变的商务需要的能力。 OLAP将数据的多维结构划分为两类表:一类是实体表,用来存储数据和维关键字;另一类是维表,即对每个维至少使用一个表来存放维的层次、成员类别等维的描述信息,维中的层次又称作量度。维表和事实表通过主关键字和外关键字联系在一起,形成了“星型模式”。对于层次复杂的维,为避免冗余数据占用过大的存储空间,可以使用多个表来描述,这种星型模式的扩展称为“雪花模式”。 不论是ROLAP和MOLAP的物理模式有多大的差别,它们的逻辑模式都可以用星形图或雪花图来描述,并且现有的雪花图和ER图的相互转换的技术、工具都比较成熟,加上许多多维数据库模型的逻辑模式的设计也都是用雪花图来描述的,所以在OLAP Server的体系结构中采用了基于雪花图的OLAP建模(见图2)。管理员使用OLAP建模模块来定义雪花图模型,生成一系列维表、实体表的定义集。 用户可以通过选择维表和实体表中的所有维和量度的不同组合来实现不同的分析模式。不过在数据建模模块中,并不把雪花图模型转换成ER图(ROLAP)进而生成关系表,或者直接转换生成多维数据库中的数据立方体(MOLAP),而只是停留在逻辑模式。物理模式的生成要等到经过HOLAP优化器(见图2)的优化和智能代理(见图2)的加载之后才根据相应的OLAP模式分别以关系表或多维立方体的形式实现。 3.3 HOLAP策略优化 HOLAP的优越性就在于它能将ROLAP和MOLAP相互取长补短,充分利用ROLAP的灵活性和数据存储能力以及MOLAP的多维性和高效率。不同OLAP应用的优化目标不同,有的应用优先考虑效率和相应时间,那么MOLAP的比重就应该加大,常用汇总数据都应该采用多维数据库来存储;有的应用对存储容量的要求较高,那么应该充分利用关系数据库的存储能力,把大部分统计数据用ROLAP的模式来存储。 这部分功能通过HOLAP策略优化器来实现,主要有两个优化范畴:不同存储方式的比例和预处理数据的比例。 3.3.1 MOLAP/ROLAP的比例 大多数HOLAP产品,如微软的OLAP Server都采用了最简单的也比较合理的一种策略,就是把所有的细节数据包括维表都存储在关系数据库中而把所有统计汇总数据都存到多维数据库中去,这是因为汇总数据的访问频率高而细节数据的存储容量大,这样做可以显著的提高综合性能。 但是并不是所有的细节数据都不常访问,也不是所有的汇总数据都经常访问,要想取得性能的进一步优化,必须提供更灵活的措施。在HOLAP优化器中,管理员可以分别选择用ROLAP或MOLAP实现的维和量度,并且提供策略性能评估,当然,这一切对最终用户都是透明的。 3.3.2 预处理数据的比例 无论是MOLAP还是ROLAP都可以有两个极端,根据维的定义预先计算好所有可能的统计汇总数据,或者完全不预先计算任何统计汇总数据。显然,完全不进行数据预处理虽然节省了大量存储空间,但牺牲了宝贵的效率,但不是预先计算的数据越多效率就越高!预先计算的数据太多,虽然减轻了查询时的CPU负载,但是由于数据库的规模太大,系统I/O的消耗却大大增长,甚至超出节省的负载,导致综合性能的下降,在一定比例范围内有一个最优化预处理区,在这个区域内的预处理比例都可以使系统综合性能接近最优化。 所以HOLAP优化器中还应提供对预处理策略的调整’同时提供性能评估。另外,为不同的存储方式设计不同的索引也在优化范围之内。比如说为查询条件中经常出现的维设计Bitmap索引等等,关于ROLAP的索引策略各大数据库厂商都有自己较为成熟的实现,MOLAP上的索引策略则还在广泛探讨之中,不断有新的模型和算法推出,在这一点上有很大的发展空间。 3.4 数据的加载和存储 根据数据建模和策略优化所生成的元数据,数据加载智能代理可以针对不同的存储模式、优化方法和索引手段提供不同的加载策略。 整个加载过程分为两个阶段,首先是细节数据的获取。在这个阶段中,OLAP服务器需要直接与数据仓库层交互,而数据仓库层所能理解的就是SQL语句,因此在这一步无论是ROLAP还是MOLAP,都需要根据雪花图模型构造细节数据的ER图模型,然后生成SQL语句向数据仓库层提交。数据仓库层返回的行集被根据不同的存储模式和索引要求存储到相应的数据库中去。 第二个阶段更为重要和复杂,就是汇总数据的生成。不同角度的汇总数据集之间有一定的函数依赖关系,从生成的顺序来看有一定的先后关系,最终可以形成一棵生成树,在这个生成树中找到一条代价最小的生成路径是一个复杂的任务。关系数据库有较为成熟的优化技术,而多维数据库在这方面要考虑的问题还很多,首先多维数据库的数据是多维立方体,虽然多维立方体的不同维之间是平等的,但存储时只能以一维结构存在磁盘上,所以多维之间必然要有一个优先序。 若是单纯的按照各维的优先序来存储,那访问的时候必然会造成不同维的访问效率的两极分化’所以多维数据库在存储时必须采用分块存储的形式。在确定了维的优先序之后,就可以根据优先序确定生成树的最小代价路径,从而进行数据的加载和存储,多维数据库中索引的实现也要特殊处理。 4 OLAP服务器对客户端的支持 4.1 数据的导航 数据的导航模块是OLAP服务器为客户端服务的接口,用来响应客户端的一系列请求,如切片、旋转、上钻、下探等OLAP操作。 如图2,导航模块向客户端提供的是一系列API,客户端通过调用这一系列API来完成对OLAP数据的操作,而OLAP服务器通过向客户端返回结果的行集来响应客户端的请求。这里正体现了开放的需要,客户不必了解OLAP服务器具体的存储模式,更不必了解自己所访问的OLAP数据的具体位置,只需要了解OLAP服务器所提供的API及其相应的功能就可以调用它们来完成客户端的分析,这样就算将来OLAP服务器中数据的内容、模式发生了改变也不影响客户端的实现。 这一切都是通过导航模块内部的数据分流来实现的,对于ROLAP,导航器将API映射成相应的分段提交的SQL语句,再向OLAP服务器中的关系数据库提交,获得相应的结果集后向客户端直接返回;对于MOLAP,导航器将API映射成相应的MDD API再向多维数据库提交,获得多维数据立方体之后经过转换,向客户端返回结果数据的行集;对于部分数据以MOLAP、部分数据以ROLAP形式存储的情况,导航器还要将两部分的数据合并后再返回。 多维数据库和关系数据库彼此并不是孤立的,如图2,它们之间可以有数据交互,MDDB可以向RDB转储数据,RDB也可以向MDDB提供细节数据。如果上面提到的客户端请求的数据经常分布在不同的存储形式中,为了提高效率,导航器会自动将RDB中的那部分数据加载到MDDB中去;对于几乎不被访问的MDDB中的数据,导航器也可以将它们转储到RDB中去,这也正体现了HOLAP的灵活性。 4.2 OLAP客户端 有了OLAP服务器提供的强大的功能和开放的接口,客户端的软件可以方便与服务器交互,灵活的进行OLAP分析。客户端常见的是可视化的查询和报表工具以及浏览器,这些工具以维和量度作为操作对象,从OLAP服务器取得结果集并以图形化或表格化的形式显示在屏幕上。 开放的体系结构不仅要满足在线的需要,还要满足离线的需要。OLAP服务器支持客户端下载规模有限的数据到客户端,然后客户在离线的状态下也可以进行OLAP分析,这特别适合移动办公的需要。 4.3 OLAP API OLAP软件要有生命力,不仅自身要效率高、功能强,更要积极寻求与第三方软件开发商的合作。因此,必须提供一套完善、简单而合理的API,除了自己的客户端软件可以从中受益之外,更可以吸引软件开发商和程序员们,从而使自己的产品在激烈的竞争中站稳脚跟。微软在推出OLAP Server的同时也推出了Microsoft OLE DB for OLAP API,就是一个很好的例子。 4.4 与Data Mining工具和DSS工具的集成 数据挖掘与OLAP本身就是互补的技术,数据挖掘在多维结构的数据上可以有更高的效率,而挖掘的结果也可以存储成OLAP的形式,供OLAP工具使用。决策支持技术也应该同OLAP技术集成起来,如数据分析包、地理信息系统、数据可视化工具等等。这些决策支持工具往往提供了多维数据的更有意义更直观的利用方式,而OLAP技术提供了灵活高效获取多维数据的手段,两者相互配合才是理想的解决方案。 一个开放的OLAP体系结构: 5 结 论 随着OLAP技术的广泛应用,高效、灵活、开放的OLAP体系结构会被更多的人所理解和追求。我们提出的这个开放的OLAP体系结构包括了与数据仓库的无缝连接、多种OLAP模式的集成、多策略的优化机制、灵活透明的数据导航、丰富的客户端实现以及完善的接口API,其中部分模块已有原型系统的实现,整个开放的体系结构则是我们的目标。
|
信息化软件应用目录 OA 办公自动化系统
CRM 客户关系管理系统
PM 项目管理系统
SCM 供应链管理系统
CC 协同商务系统
BPM 业务流程管理
BI 商务智能
CMS 内容管理系统
KM/KBS 知识管理系统
电子商务系统
HRM 人力资源管理系统
ERP 企业资源计划
EAM 企业资产管理系统
|