多维分析OLAP引擎Mondrian学习

1 背景

1.1 实时业务监控背景

随着信息技术的飞速发展，在电力、电信、金融、大型制造等各个行业ERP、CRM、SCM、OA等越来越多的IT系统得以成功实施，这些分散建设的IT系统为各部门的运营效率提升发挥了很大的作用。同时，为了满足业务管理和决策的报表系统（包括传统报表、数据仓库、OLAP等）也被创建出来，企业主管通过报表了解企业的总体运行状态。

但是，随着企业间竞争的加剧和市场节奏的进一步加快，企业的日常管理需要对关键业务指标的更加实时的监控和反馈。比如：制造业需要更及时的仓库调度、金融业需要更实时的风险防范、电信业需要更及时的服务指标监控。于是，越来越多的企业提出实时企业的要求，传统的ERP等信息系统和报表系统无法满足这些需求。实时业务监控解决方案旨在更好支撑客户此类需求。

总体实现架构：

2 该领域的知识的概括综述

2.1 解决的主要问题

联机分析处理 (OLAP) 的概念最早是由关系数据库之父E.F.Codd于1993年提出的，他同时提出了关于OLAP的12条准则。OLAP的提出引起了很大的反响，OLAP作为一类产品同联机事务处理 (OLTP) 明显区分开来。

当今的数据处理大致可以分成两大类：联机事务处理OLTP（on-line transaction processing）、联机分析处理OLAP（On-Line Analytical Processing）。OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。

2.2 现有主要产品

•  商业OLAP产品：

IBM Cognos：IBM Cognos 8 商业智能系列产品在服务导向架构（SOA）的基础上，提供可定制的全方位的商业智能服务。用户可以利用 IBM Cognos 8 商业智能系列软件对您的商业进行监控，分析和预测，而且用户可以轻松的在集中控制的平台上部署相应的服务来满足特定的需求。这种模块化部署的架构能使用户方便的扩展或者修改系统功能来满足不同的商业智能需求。详细：http://www.ibm.com/developerworks/cn/data/library/techarticles/dm-0903gaoxf/

Oracle OLAP：是Oracle企业版的一个可选件，由于将OLAP引擎完全集成进了Oracle数据库，所以，所有数据和元数据都是从Oracle数据库内部进行存储和管理的，以提供高度可伸缩性、强健的管理环境及工业级可用性和安全性。Oracle OLAP主要包括以下组件：

 OLAP Analytic Engine：Oracle的OLAP分析引擎是一个基于多维模型的MOLAP引擎，运行在Oracle内核中，因此拥有良好的性能。
 Analytic Workspace：分析工作区中实际存储多维模型的数据。一个Analytic Workspace存储为一个关系表，分析工作区中的不同对象存储为表中的一行(LOB格式)。分析工作区甚至可以存储在分区表中，以提供更好的并发性能。
 OLAP DML：OLAP DML是Analytic Workspace的原始操作语言，包括关于Analytic Workspace的数据定义语言(DDL)和数据操作语言(DML)。对于Analytic Workspace的所有操作方式，比如GUI工具，java和SQL等方式，最终都要转化为Oracle DML语言。
 SQL Interface to OLAP：提供使用SQL操作Analytic Workspace的接口，该接口使用PL/SQL实现。
 Analytic Workspace Java API：提供使用Java操作Analytic Workspace的接口。在GUI工具Analytic Workspace Manager中使用的就是该接口。
 OLAP API：Oracle OLAP的一个Java编程接口，支持OracleBI Bean。除了服务器组件，Oracle OLAP还提供了两个客户端工具：
 Analytic Workspace Manager：这是Oracle提供的一个操作Analytic Workspace的一个图形工具。使用该工具可以快速的完成诸如定义数据的逻辑多维模型、创建多维数据到关系数据的映射、装载和聚合数据等任务。
 OLAP Worksheet：OLAP Worksheet提供了操作Analytic Workspace的一个交互式环境。有点类似于Oracle数据库的SQLPLUS工具。

MS Analytic Services：微软的 SQL Server OLAP 服务是一个新的中间层服务器用于在线的分析处理(OLAP)。 

OLAP 服务系统包括一个能构建用于分析的多维立体数据以及提供客户端对这些立体数据快速访问的强大的服务器。 PivotTable(中枢表)服务，所含的 OLE DB 适应提供器，用于微软的 Excel 和其他软件销售商的应用程序从服务器查询多维数据并呈递给用户。OLAP 服务是从数据仓库组织数据到多维立体数据库，这些数据信息已预先由 OLAP 计算或汇总好，以对复杂的分析查询提供快速的响应。关键特性如下：

1. 通过用户界面和精灵，易于使用。

2. 提供了用于立体数据定义和存储的灵活、强劲的数据模型。

3. 对“what if”情节分析的使写(Write-enabled)立体数据支持。

4. 可伸缩的体系结构提供了多种多样的存储细节和对困饶传统 OLAP 技术的“数据爆炸综合症”的自动解决方案。

5. 集成了管理工具、安全、数据源以及客户／服务器缓存技术。

6. 广泛支持的 APIs 以及开放的体系结构，用以支持各种客户应用。

•  开源OLAP产品：

Mondrian:我们预研选型的OLAP引擎产品，http://mondrian.pentaho.org Mondrian是开源世界中最为有名的OLAP Server特点是功能强大,易学易用，被评价为“穷人最适合的OLAP产品”

JPivot : http://jpivot.sourceforge.net/ 一个OLAP的客户端，使用XML+XSL来展现OLAP的数据，虽然我们总是说Mondrian + JPivot ，但是其实Mondrian官方都说他们是小心翼翼的分开Mondrian + JPivot的，所以你可以任意选择OLAP Server 和 OLAP Client 的组合的，JPivot 也支持MSSQL Server的 OLAP 数据源的.

Palo : http://www.imppalo.com/   一个MOLAP实现，已经有商业化公司运行了，产品相对成熟，如果你看过RoadMap 那一篇的话，你就应该已经知道spagoBI的roadmap里面已经开始要支持Palo了.

JPalo : http://www.jpalo.com/  一个基于Palo的Java客户端，基于eclipse的RCP 技术，并提供API访问Palo的Server 。SpagoBI 在RoadMap中也计划支持这对组合，Mondrian + JPivot 的竞争对手.

Cubulus OLAP : http://cubulus.sourceforge.net/  一个OLAP Server + Client ， Python写的，目前支持mySQL,PostgreSQL , SQLite .看来还很不成熟。

3 OLAP引擎技术特点和常用实现方式

3.1 技术特点

OLAP技术非常多的特性，概括起来主要有如下几点特性：OLAP技术是面向分析人员、管理人员的；OLAP技术对数据访问通常是只读的，并且一次访问大量数据；OLAP技术是面向主题的多维数据分析技术。

•  OLAP技术是面向分析人员、管理人员的
•  区别于OLTP面向操作人员，OLAP技术主要面向分析人员、管理人员，他是提供分析人员、管理人员快速又直观的访问数据的一种途径。使分析人员、管理人员能直观的从海量数据中获得有用信息以提供决策依据。
•  OLAP技术对数据访问通常是只读的，并且一次访问大量数据。
•  OLAP技术主要是针对海量数据的查询，通常不对数据做修改。这种数据访问有别于OLTP中不断的对数据进行增删改操作。同时这种查询不是简单的记录属性的检索，而是为了从海量数据中获取有用信息的针对大量数据的查询，通常一次需要查询会涉及到上百万条以上数据。
•  OLAP技术是面向主题的多维数据分析技术。

主题涉及业务流程的方方面面，是分析人员、管理人员进行决策分析所关心的角度。分析人员、管理人员使用OLAP技术，正是为了从多个角度观察数据，从不同的主题分析数据，最终直观的得到有效的信息。

3.2 主要技术实现方式

OLAP系统按照其存储器的数据存储格式可以分为关系OLAP（RelationalOLAP，简称ROLAP）、多维OLAP（MultidimensionalOLAP，简称MOLAP）和混合型OLAP（HybridOLAP，简称HOLAP）三种类型。

•  ROLAP：ROLAP将分析用的多维数据存储在关系数据库中并根据应用的需要有选择的定义一批实视图作为表也存储在关系数据库中。不必要将每一个SQL查询都作为实视图保存，只定义那些应用频率比较高、计算工作量比较大的查询作为实视图。对每个针对OLAP服务器的查询，优先利用已经计算好的实视图来生成查询结果以提高查询效率。同时用作ROLAP存储器的RDBMS也针对OLAP作相应的优化，比如并行存储、并行查询、并行数据管理、基于成本的查询优化、位图索引、SQL的OLAP扩展(cube,rollup)等等。

•  MOLAP：MOLAP将OLAP分析所用到的多维数据物理上存储为多维数组的形式，形成“立方体”的结构。维的属性值被映射成多维数组的下标值或下标的范围，而总结数据作为多维数组的值存储在数组的单元中。由于MOLAP采用了新的存储结构，从物理层实现起，因此又称为物理OLAP（PhysicalOLAP）；而ROLAP主要通过一些软件工具或中间软件实现，物理层仍采用关系数据库的存储结构，因此称为虚拟OLAP（VirtualOLAP）。

•  HOLAP：由于MOLAP和ROLAP有着各自的优点和缺点（如下表所示）,且它们的结构迥然不同，给分析人员设计OLAP结构提出了难题。为此一个新的OLAP结构——混合型OLAP（HOLAP）被提出，它能把MOLAP和ROLAP两种结构的优点结合起来。迄今为止，对HOLAP还没有一个正式的定义。但很明显，HOLAP结构不应该是MOLAP与ROLAP结构的简单组合，而是这两种结构技术优点的有机结合，能满足用户各种复杂的分析请求。、

4 对Mondrian产品的预研和分析

4.1 产品简介

Mondrian 是一个开源项目，是开源项目Pentaho的一部分，是一个用Java写成的OLAP引擎。它实现了MDX语言、XML解析、JOLAP规范。它从SQL和其它数据源读取数据并把数据聚集在内存缓存中，然后经过Java API用多维的方式对结果进行展示，同时可以不写SQL就能分析存储于SQL 数据库的庞大数据集，可以封装JDBC数据源并把数据以多维的方式展现出来。

开源协议：EPL协议（商用友好的协议）

4.2 产品功能模块综述

Mondrian项目逻辑模块分层结构图：

上图为整体的项目架构，图中所示Mondrian分成了四个大部分Schema manager、Session Manager、Dimension Manager、Aggregate Manager，而实际上各个部分有着更为紧密的联系。对于Dimensional Layer、Star Layer和SQL Layer的划分，更多是处于总体逻辑分层的考虑，具体在源码中，逻辑分层的概念比较模糊。

下面是四个Manager的简介：

•  Session Manager：最为重要的一个部分。接受MDX查询、解析MDX，返回结果。
•  Schema Manager：与初始化紧密相关。主要是一些重要的数据结构如缓存池的构建以及多维模型的生成。
•  Aggregate Manager：实现了对聚集表的管理。主要是对OLAP缓存的管理，属于性能优化的部分。
•  Dimension Manager：维度的管理。实现多维模型中维度和关系数据库表中列的映射，在Schema Manager也有部分功能处理这些映射。

4.3 产品特性列表

•  OLAP缓存：Mondrian主要特点是对立方体进行了缓存，众所周知，缓存庞大的立方体对性能有很大的影响，但是Mondrian利用java语言的特点对这一点进行了很好的控制。其次由于Mondrian基于java语言，所以它能运行在不同的平台之上，这也是其流行的主要原因之一，例如花旗银行就在其数据仓库项目中用Mondrian作为它的OLAP引擎。

如上图所示，这是由三个维度构成的一个OLAP立方体，立方体中包含了满足条件的cell(子立方块)值，这些cell里面包含了要分析的数据，称之为度量值。显而易见，一组三维坐标唯一确定了一个子立方。

多位模型的基本概念介绍：

•  立方体：由维度构建出来的多维空间，包含了所有要分析的基础数据，所有的聚合数据操作都在立方体上进行。
•  维度：就是观察数据的一种角度。在这个例子中，路线，源，时间都是维度，
•  这三个维度构成了一个立方体空间。维度可以理解为立方体的一个轴。要注意的是有一个特殊的维度，即度量值维度。
•  维度成员：构成维度的基本单位。对于时间维，它的成员分别是：第一季度、第二季度、第三季度、第四季度。
•  层次：维度的层次结构，要注意的是存在两种层次：自然层次和用户自定义层次。对于时间维而言，(年、月、日)是它的一个层次，(年、季度、月)是它的另一个层次，一个维可以有多个层次，层次可以理解为单位数据聚合的一种路径。
•  级别：级别组成层次。对于时间维的一个层次(年、月、日)而言，年是一个级别，月是一个级别，日是一个级别，显然这些级别是有父子关系的。
•  度量值：要分析展示的数据，即指标。如图1中一个cell中包含了两个度量值：装箱数和截至时间，可以对其进行多维分析。
•  事实表：存放度量值的表，同时存放了维表的外键。所有的分析用的数据最终都是来自与事实表。
•  维表：一个维度对应一个或者多个维表。一个维度对应一个维表时数据的组织方式就是采用的星型模式，对应多个维表时就是采用雪花模式。雪花模式是对星型模式的规范化。简言之，维表是对维度的描述。
•  MDX查询：多维模型的查询语言MDX(MDX是微软发布的多维查询语言标准),它的语法与SQL有很多相似之处：select {[Measures].[Salary]} on columns, {[Employee].[employeeId].members} on rows from CubeTest对于这条语句，COLUMNS 和 ROWS都代表查询轴，其中COLUMNS代表列轴，ROWS代表行轴。COLUMNS又可以写成0，ROWS又可以写成1，当只有两个查询轴时，可以理解为结果的展现格式是一个平坦二维表。这条语句的含义就是查询名字为CubeTest的立方体，列显示Measures维度的salary，行显示 Employee维度employeeId级别的所有成员，那么得出的结果就是employeeId所有成员的salary，也就是所有员工的薪酬。具体语法规范和帮助文档可以参考微软的用户文档。

4.4 评价和分析

•  开源协议：EPL协议，是基于Eclipse的商用友好的协议，我们可以使用。协议详细定义请参见：http://www.eclipse.org/legal/epl-v10.html
•  数据加载操作方式：Mondrian 并不像其他OLAP Server一样会将聚合、汇总的数据存储在磁盘中，它是直接在用户配置好的关系数据库中的数据上进行数据分析计算处理, 一旦读取一块数据,就将其存储在缓存中，这使得Mondrian的安装、使用起来非常容易, 但这也影响了Mondrian处理海量数据时的性能。
•  性能和优化：虽然Mondrian自己不做汇总数据存储的功能，但面对海量数据时也提供了性能优化的支持方式，如可以支持用户为常用查询维度基于事实表扩展数据聚合表，在执行查询请求是Mondrian可以通过查询聚合表进行查询性能优化。下面是不同的数据量情况下Mondrian OLAP Server的性能表现和优化方案的介绍。

百万级事实数据：按照Mondrian文档中所描述的内容可以看出，只基于操作系统环境和数据库环境的优化，Mondrian Server在百万行级别数据量的事实表（关系数据库）仍能够运行良好。当然这需要我们自己来评测和证实。

千万级事实数据：当事实表数据立方体的数据量达到千万行以上时，Mondrian建议采用“汇总表”或者是由数据库支持的类似Oracle数据库的“物化视图”功能来优化OLAP查询的性能。

Mondrian缓存设置：由于Mondrian会将查询过的数据缓存起来，所以Mondrian建议缓存的大小根据具体项目的实际情况判断，当然是缓存越大越好。

•  Mondrian生成SQL分析

MDX语句： 2011年所有员工的薪资统计

select {[Measures].[Salary]} on 0,{[Emp].[EmpID].Members} on 1 from Cube where {[Time].[2011]}

查询生成的SQL语句:

1. select `tb_time`.`the_year` as `c0` from `tb_time` as `tb_time` where `tb_time`.`the_year` = 2011 group by `tb_time`.`the_year` order by ISNULL(`tb_time`.`the_year`), `tb_time`.`the_year` ASC

2. select `tb_employee`.`employee_id` as `c0` from `tb_employee` as `tb_employee` group by `tb_employee`.`employee_id` order by ISNULL(`tb_employee`.`employee_id`), `tb_employee`.`employee_id` ASC

3. select count(distinct `tb_employee`.`employee_id`) as `c0` from `tb_employee` as `tb_employee`

4. select `tb_time`.`the_year` as `c0`, `tb_employee`.`employee_id` as `c1`, sum(`tb_salary`.`salary`) as `m0` from `tb_time` as `tb_time`, `tb_salary` as `tb_salary`, `tb_employee` as `tb_employee` where `tb_salary`.`time_id` = `tb_time`.`time_id` and `tb_time`.`the_year` = 2011 and `tb_salary`.`employee_id` = `tb_employee`.`employee_id` group by `tb_time`.`the_year`, `tb_employee`.`employee_id`

SQL分析：Mondrian收到MDX查询请求后，如果缓存中没有对应的内容，则会生产上面的SQL从数据库加载数据，然后再加入缓存中，这样的场景也是我们做实时监控是最常遇到的场景。如上面的简单例子，Mondrian所生成的SQL语句同我们期望的基本一致。就Mondrian生成的SQL语句本身不会有性能瓶颈，这样也使我们可以着力于其他方面的设计和优化。

•  Mondrian缓存控制

为了提高海量数据下的查询响应速度，Mondrian自动将首次查询的结果缓存到内存中，之后的查询如果命中缓存内容，则不再访问数据库。这种实现方式有点自不必说，但是在实现实时OLAP时会存在问题，实时OLAP中数据变化频繁导致缓存中的数据不是最新的。

缓存控制接口：为了做到不重启OLAP Server也能更新缓存，Mondrian提供了一系列的刷新缓存的接口，支持指定清除指定schema的元数据缓存、查询结果缓存；清除动作可以是全部清除 也可以是 部分清除（可以指定清除某个维度下某级别成员的相关内容）。

数据变化监听： Mondrian提供了缓存控制接口（被动响应），但对于实现我们的目标“实时OLAP”来说我们就需要自己实现一个数据变更监听的模块，来监听数据变化，一旦数据有变化就发起变更事件，更新Mondrian引擎的缓存。

目前初步考虑实现方案为ETL工具在数据处理结束后通知OLAP引擎。引擎收到数据变更通知后做清理缓存的动作。

5 相关开源产品集成说明

5.1 依赖的JAR包

•  Mondrian示例测试需要的最少JAR列表:

commons-dbcp-1.2.1.jar

commons-logging-1.0.4.jar

commons-pool-1.2.jar

dom4j.jar

log4j-1.2.8.jar

mondrian.jar

olap4j.jar

commons-math-1.0.jar

commons-collections-3.1.jar

commons-beanutils-1.6.jar

commons-vfs-1.0.jar

eigenbase-xom.jar

eigenbase-properties.jar

eigenbase-resgen.jar

javacup.jar

•  扩展功能引入JAR:

mysql-connector-java-3.1.12-bin.jar

xstream-1.2.2.jar

转自:http://p.primeton.com/articles/53c64698e138232acb000086