商业智能之联机分析处理

商业智能之联机分析处理(OLAP)

Inetsoft最早是一个报表工具厂商，2004年Style Report/Style Intelligence 发布基于OLAP ROLAP的数据分析技术，初次涉足商业智能应用。自此，我们沿着商业智能（BI）之路一路前行，直到今天，长江后浪推前浪，我们的BI产品渐渐超过了传统的报表工具

产品，Style Intelligence系列成为主打产品。可以说，OLAP把英网带入了商业智能领域。

随着企业信息化的推进，传统关系型数据库的发展，很多企业的数据资源已经相当丰富了，但是面临着“数据海量、信息全无”的尴尬局面。也许我们会说，关系型数据库不是也提

供了查询手段吗比如SQL。确实，我们可以通过SQL查询到一些结果，但是这其中面临几

大问题，这里只列举其中两个最要命的问题：

1.当数据库结构相对简单，数据量相对小，查询也不是很频繁的时候，关系型数据库

都能运转良好。但是，想象一下，一个查询需要连接几张表，并且有些表的数据早

已过了千万行的级别，从这几千万行中找出你需要的数据，再假设这个查询还挺频

繁的，我想，这个时候只能选择崩溃了。

2.获取信息是为了帮助我们分析问题，而分析问题这种自然行为一般都是从相关因素

开始考虑的，专业术语叫“维度”，这些维度的产生依赖于分组，度量值来自于分

组后的统计。SQL天然的不适合这种应用，只能动态的生成形形色色的SQL查询语

句来获取不同的信息，这个计算量让关系型数据库力不从心。虽然我们可以想很多

种办法来维持运转，比如建立视图、索引、缓存等，总归是治标不治本的权宜之计。

由此可见，SQL对大数据库的简单查询已不能满足用户分析的需求。用户的决策分析需要

对关系数据库进行大量计算才能得到结果，而查询的结果并不能满足决策者提出的需求。

如此一来，OLAP应运而生。在OLAP可以运行之前，一般需要建立相应的数据来源，其中

一个选项便是数据仓库。根据人的思维习惯和分析习惯，预先定义好分析事物的几个维度，维度又可以细分为不同层次。比如我们分析销售行为，时间是一个常用的维度，而时间又

经常被划分为年、季度、月份等，这就是层次。划分好维度和层次之后呢，又把这些维度

中各层次对应的数据汇总起来，变成了度量值在这些维度层次上的反映。这就跟关系数据

库的理念背道而驰。关系数据库是痛恨冗余的，比如实时销售表中是不会有顾客姓名或地

址的，大不了有个顾客ID，这些信息都会存在顾客信息表中，否则实时销售表中有太多重复的顾客姓名或地址，显得很冗余。而OLAP反其道而行之，引入了冗余，针对各种可能

性预先归类和计算，而这些归类和计算从信息存储的角度来看，完全是多余的，因为你年

份的统计完全可以通过月份的统计推算出来，最详细的层次也可以通过原始数据计算出来。这就是冗余和计算性能之间的一种平衡。所以，世间万物，并无绝对的对与错，一切都是

因时因地而异，一切又都在动态的平衡当中，而且有很多事有需要我们来平衡，恰如我们

的工作和生活一样。

下面的例子也许更有助于我们理解OLAP的工作原理。

例如分析销售数据，可能会综合时间周期、产品类别、分销渠道、地理分布、客户群类等

多种因素来考量。这些分析角度虽然可以通过报表来反映，但每一个分析的角度可以生成

一张报表，各个分析角度的不同组合又可以生成不同的报表，使得IT人员的工作量相当大，而且往往难以跟上管理决策人员思考的步伐。

联机分析处理的主要特点，是直接仿照用户的多角度思考模式，预先为用户组建多维的数

据模型，在这里，维指的是用户的分析角度。例如对销售数据的分析，时间周期是一个维度，产品类别、分销渠道、地理分布、客户群类也分别是一个维度。一旦多维数据模型建

立完成，用户可以快速地从各个分析角度获取数据，也能动态的在各个角度之间切换或者

进行多角度综合分析，具有极大的分析灵活性。这也是联机分析处理在近年来被广泛关注

的根本原因，它从设计理念和真正实现上都与旧有的管理信息系统有着本质的区别。

不妨看一下图示：

事实表中包含了丰富的信息，但是每次都从它那里查询也考验着我们的智商和体力，于是，我们预先把他处理成各种不同的维度，映射到相应的数据，这个数据就是根据相应需要的

汇总。从Outline File我们看到了相应的维度，以及他们的成员，比如Region维度（这

里假设就这一个层次），它的成员包括GZ、BJ、SH等。Index Filed保存了映射关系，各个维度成员组合映射到相应的数据块。Data File是度量值（Measure）的容身之地，他把各个维度成员组合对应的度量值都放在一个二维数组。照理来说这里应该是一个多维数组，为了距离方便，只在Index File里面列出了Customer和Channel维度，忽略了其他维度，比如Region，所以两个维度对应的就是二维数组。N个维度就会对应n维数组。

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

ROLAP将分析用的多维数据存储在关系数据库中并根据应用的需要有选择的定义一批实视

图作为表也存储在关系数据库中。不必要将每一个SQL查询都作为实视图保存，只定义那

些应用频率比较高、计算工作量比较大的查询作为实视图。对每个针对OLAP服务器的查询，优先利用已经计算好的实视图来生成查询结果以提高查询效率。同时用作ROLAP存储

器的RDBMS也针对OLAP作相应的优化，比如并行存储、并行查询、并行数据管理、基于

成本的查询优化、位图索引、SQL的OLAP扩展(cube,rollup)等等。

我们在Logical Model上提供了一个Hierarchy，就是ROLAP。我们的工作原理就是接收

到相应的多维请求，然后解析成相应的Logical Model能理解的数据请求，这里往往是SQL，最终呈现给用户数据。也就是，我们利用我们的聪明才智，隐藏了各种生成SQL的

头疼的事情，直接响应最终用户的各种多维请求，并且利用我们的各种计算优势和缓存策略，来突破ROLAP的一些劣势，比如性能问题。

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

我们还是可以用同一个图例来解释这个问题。

把数据从原始数据表里面抽取出来，先归纳存储各个维度（Outline File），再根据维度成员的多少来产生相应的度量值（Data File），这些度量值也是原始数据的一个汇总，

这个过程也就是关系数据库里面的分组和汇总。最后，产生维度成员与度量值之间的映射关系（Index File），所以，Data File应该是一个n维数组，n个维度对应n维数组。

而这些物理存储的多维数组访问效率很高，所以MOLAP的性能优势就显而易见了。

说到这里，我们不得不提到MDX。MDX，多维表达式（multi-dimensional expressions）的英文缩写词，是一种编程语言语法，支持多维对象与数据的定义和操作。MDX 在很多方面与结构化查询语言 (SQL) 语法相似，但它不是 SQL 语言的扩展。OLAP产品多支持MDX 查询。

很多厂商的OLAP产品都是这种类型。我们的产品Style Intelligence就是通过XMLA包

装的MDX，来访问诸个第三方OLAP产品的多维数据的。我们目前通过测试的有Hyperion Essbase、Mirosoft SQLServer Analysis、Sap NetWeaver、Mondrian和我们自己的ROLAP。XMLA是一种Web Service，支持这种标准的OLAP厂商，他们的产品接收到我们的请求，相应的服务会解析请求、分析MDX、返回标准的XML格式的数据，然后我们解析这些数据形成我们自己的数据格式。

那OLAP和传统的查询和报表工具到底有什么区别呢

OLAP是决策支持领域的一部分。传统的查询和报表工具是告诉你数据库中都有什么（what happened），OLAP则更进一步告诉你下一步会怎么样（What next）、和如果我采取这样的措施又会怎么样（What if）。用户首先建立一个假设，然后用OLAP检索数据库来验证这个假设是否正确。比如，一个分析师想找到什么原因导致了贷款拖欠，他可能先做一个初始的假定，认为低收入的人信用度也低，然后用OLAP来验证他这个假设。如果这个假

设没有被证实，他可能去察看那些高负债的账户，如果还不行，他也许要把收入和负债一起考虑，一直进行下去，直到找到他想要的结果或放弃。也就是说，OLAP分析师是建立一系列的假设，然后通过OLAP来证实或推翻这些假设来最终得到自己的结论。OLAP

分析过程在本质上是一个演绎推理的过程。

大多数的统计分析技术都基于完善的数学理论和高超的技巧，预测的准确度令人满意，但对使用者的要求很高。而随着计算机计算能力的不断增强，我们有可能利用计算机强大的计算能力只通过相对简单和固定的方法完成同样的功能。OLAP把这些高深复杂的技术封装

起来，使人们不用自己掌握这些技术也能完成同样的功能，并且更专注于自己所要解决的问题。