ROLAP、MOLAP和HOLAP联机分析处理区别

     第一篇：

 

   OLAP(on-Line Analysis Processing)是使分析人员、管理人员或执行人员能够从多角度对信息进行快速、一致、交互地存取,从而获得对数据的更深入了解的一类软件技术。OLAP的目标是满足决策支持或者满足在多维环境下特定的查询和报表需求,它的技术核心是"维"这个概念。

   “维”(dimension)是人们观察客观世界的角度,是一种高层次的类型划分。“维”一般包含着层次关系,这种层次关系有时会相当复杂。通过把一个实体的多项重要的属性定义为多个维(dimension)，使用户能对不同维上的数据进行比较。因此OLAP也可以说是多维数据分析工具的集合。

OLAP的基本多维分析操作有钻取（roll up和drill down）、切片（slice）和切块（dice）、以及旋转（pivot）、drill across、drill through等。

·钻取是改变维的层次，变换分析的粒度。它包括向上钻取（roll up）和向下钻取（drill down）。roll up是在某一维上将低层次的细节数据概括到高层次的汇总数据，或者减少维数；而drill down则相反，它从汇总数据深入到细节数据进行观察或增加新维。

·切片和切块是在一部分维上选定值后，关心度量数据在剩余维上的分布。如果剩余的维只有两个，则是切片；如果有三个，则是切块。

·旋转是变换维的方向，即在表格中重新安排维的放置（例如行列互换）。

OLAP有多种实现方法，根据存储数据的方式不同可以分为ROLAP、MOLAP、HOLAP。

ROLAP表示基于关系数据库的OLAP实现（Relational OLAP）。以关系数据库为核心,以关系型结构进行多维数据的表示和存储。ROLAP将多维数据库的多维结构划分为两类表:一类是事实表,用来存储数据和维关键字;另一类是维表,即对每个维至少使用一个表来存放维的层次、成员类别等维的描述信息。维表和事实表通过主关键字和外关键字联系在一起,形成了"星型模式"。对于层次复杂的维,为避免冗余数据占用过大的存储空间,可以使用多个表来描述,这种星型模式的扩展称为"雪花模式"。特点是将细节数据保留在关系型数据库的事实表中，聚合后的数据也保存在关系型的数据库中。这种方式查询效率最低，不推荐使用。

MOLAP表示基于多维数据组织的OLAP实现（Multidimensional OLAP）。以多维数据组织方式为核心,也就是说,MOLAP使用多维数组存储数据。多维数据在存储中将形成"立方块（Cube）"的结构,在MOLAP中对"立方块"的"旋转"、"切块"、"切片"是产生多维数据报表的主要技术。特点是将细节数据和聚合后的数据均保存在cube中，所以以空间换效率，查询时效率高，但生成cube时需要大量的时间和空间。

HOLAP表示基于混合数据组织的OLAP实现（Hybrid OLAP）。如低层是关系型的，高层是多维矩阵型的。这种方式具有更好的灵活性。特点是将细节数据保留在关系型数据库的事实表中，但是聚合后的数据保存在cube中,聚合时需要比ROLAP更多的时间,查询效率比ROLAP高，但低于MOLAP。

还有其他的一些实现OLAP的方法，如提供一个专用的SQL Server，对某些存储模式（如星型、雪片型）提供对SQL查询的特殊支持。

OLAP工具是针对特定问题的联机数据访问与分析。它通过多维的方式对数据进行分析、查询和报表。维是人们观察数据的特定角度。例如，一个企业在考虑产品的销售情况时，通常从时间、地区和产品的不同角度来深入观察产品的销售情况。这里的时间、地区和产品就是维。而这些维的不同组合和所考察的度量指标构成的多维数组则是OLAP分析的基础，可形式化表示为（维1，维2，……，维n，度量指标），如（地区、时间、产品、销售额）。多维分析是指对以多维形式组织起来的数据采取切片（Slice）、切块（Dice）、钻取（Drill-down和Roll-up）、旋转（Pivot）等各种分析动作，以求剖析数据，使用户能从多个角度、
多侧面地观察数据库中的数据，从而深入理解包含在数据中的信息。

根据综合性数据的组织方式的不同，目前常见的OLAP主要有基于多维数据库的MOLAP及基于关系数据库的ROLAP两种。MOLAP是以多维的方式组织和存储数据，ROLAP则利用现有的关系数据库技术来模拟多维数据。在数据仓库应用中，OLAP应用一般是数据仓库应用的前端工具，同时OLAP工具还可以同数据挖掘工具、统计分析工具配合使用，增强决策分析功能。

       

        第二篇：

 

   ROLAP表示基于关系数据库的OLAP实现（Relational OLAP）。以关系数据库为核心，以关系型结构进行多维数据的表示和存储。ROLAP将多维数据库的多维结构划分为两类表：一类是事实表，用来存储数据和维关键字；另一类是维表，即对每个维至少使用一个表来存放维的层次、成员类别等维的描述信息。维表和事实表通过主关键字和外关键字联系在一起,形成了“星型模式”。对于层次复杂的维，为避免冗余数据占用过大的存储空间，可以使用多个表来描述，这种星型模式的扩展称为“雪花模式”。

   MOLAP表示基于多维数据组织的OLAP实现（Multidimensional OLAP）。以多维数据组织方式为核心，也就是说，MOLAP使用多维数组存储数据。多维数据在存储中将形成“立方块（Cube）”的结构，在MOLAP中对“立方块”的“旋转”、“切块”、“切片”是产生多维数据报表的主要技术。

特性分析

    从技术角度来说，ROLAP（MSTR实现）和MOLAP(Cognos等实现)各有千秋。前者基于关系型数据库，它的OLAP引擎就是将用户的OLAP操作，如上钻下钻过滤合并等，转换成SQL语句提交到数据库中执行，并且提供聚集导航功能，根据用户操作的维度和度量将SQL查询定位到最粗粒度的事实表上去。相比较而言，MOLAP事先将汇总数据计算好，存放在自己特定的多维数据库中，用户的OLAP操作可以直接映射到多维数据库的访问，不通过SQL访问。可以说ROLAP提供了更大的灵活度，MOLAP提供了更加快速的相应速度，确实相比Metacube和Cognos，前者的操作复杂些，不过这应该不成问题，是可以改善的。

    针对OLAP多维分析的应用，虽然多维数据库效率较高，但是带来的问题是，数据装载的效率非常低，因为其实就是将多维的数据预先填好，这样出报表的效率高了，装载就复杂许多了，而且仓库重新构造后，全部数据都要重新装载，并且随着数据量增量过大维护成本较高，容易引起“数据爆炸”，这是molap的大体特性。rolap就是关系性数据库，但是针对多维报表，可以通过事实表连维表的方式来构造，对于数据库性能要求比较高，各个rolap厂家针对数据仓库应用，建立索引等优化措施以减少生成报表的开销，仓库调整后，除非特别大的调整，同常都不需要重新装载全部数据。

 第三篇：

 

     ROLAP(relational OLAP)，细节数据、聚合后的数据都保存在关系型的数据库中。这种方式查询效率最低，但是如果数据量比较小的话，用这种方法未尝不可。
HOLAP(hybrid OLAP)，细节数据保留在关系型数据库的事实表中，但是聚合后的数据保存在cube中。
MOLAP(multidimensional OLAP)，将细节数据和聚合后的数据均保存在cube中，在查询性能上就有很大提高，问题就是会占用很大的空间，说白了，就是用空间换时间。

以上三种方式，具体情况具体利用.

记得2000年的时候，在QiDSS中使用的是ROLAP技术。到2003年，全国上下的BI系统几乎都采用MOLAP技术，这是一个很值得思考的现象。表面上看，由于工具厂商市场份额的变化，对产品推广力度不够。在QiDSS中，使用Metacube作为OLAP Server，但是就在那个时候，它已经宣称不再升级甚至不再提供支持了，当时业界提供纯ROLAP产品的厂商已经不多，现在Microstrategy公司依然存在，而且据说在国内有几个客户，很早了解他们就是因为它是ROLAP产品提供商，不过对它们现在的产品线已经不清楚了。

更深一层看，为什么ROLAP产品生存空间不大，必定和用户的需求有关系。用户需要的不是产品，而是在线分析的功能，其中重要的一点就是分析响应速度。
这一点还是MOLAP占了上风。从技术角度来说，ROLAP和MOLAP各有千秋。前者基于关系型数据库，它的OLAP引擎就是将用户的OLAP操作，如上钻下钻过滤等，转换成SQL语句提交到数据库中执行，并且提供聚集导航功能，根据用户操作的维度和度量将SQL查询定位到最粗粒度的事实表上去。相比较而言，MOLAP事先将汇总数据计算好，存放在自己特定的多维数据库中，用户的OLAP操作可以直接映射到多维数据库的访问，无需通过SQL访问。可以说ROLAP提供了更大的灵活度，但可能正是这种灵活度，造成对用户使用的不友好印象，确实相比Metacube和Cognos，前者的操作复杂多了，不过这应该不成问题，是可以改善的。

性能的问题却不是非常容易解决的，关键还不在是聚集表快还是多维数据库快。从体系架构上说，采用MOLAP使得OLAP应用和数据仓库分离开，降低了耦合度，这种架构是比较理想的，可以让不同部件专门干自己的事，付出的代价主要是ETL的复杂度。而ROLAP技术直接依赖数据仓库，与之紧密结合，OLAP的性能很大程度上依赖数据仓库模式设计，这一点不是总是被保证的。

不过对于ROLAP，我对之有些信心。别看现在大家都在用Cognos、Essbase什么的，那都是轧堆，十年河东，十年河西。如果在ROLAP上有成熟的方法论用以规范化数据仓库设计的话，以后必定又能大放异彩。

 

评论

1 楼 liqi___123 2012-05-17  

理解得很透彻，谢谢！！