10年经验回头看：OLAP工具毁了商业智能

笔者从1998年开始研究并从事商业智能（BI）项目，10年来在BI方面积累了一些心得，谨供大家参考。

为什么说OLAP产品毁了BI？

企业为了确定经营战略和市场战略所进行的经营活动，在BI项目的分析决策过程中，需要基于多种报告和报表进行分析。理想的市场活动展开，大多需要各个营业点的销售报表，每种商品按季节销售的业绩图表等，这就需要大量准确的并且易于判断的数据。

然而，对于作为使用者的一般员工或者IT部门员工来说，这是一个很大的工作量负担。因为数据的分析需要先获得必要的数据信息，这就必须预先知道数据采集和数据加工计算的方法。当然，还有必要掌握数据库构成和数据存取语言的一些专门的知识。

因此这些工作以前全都是由IT部门人员用OLAP产品来完成的。信息管理部门要根据用户的要求把报表格式设计好，然后根据用户的目的，开发出应用程序以及建立数据库等来完成这项工作。

OLAP报表工具是指什么？

在报表市场上，有一个奇特的现象：IT部门的技术人员是企业所有部门中最不熟悉使用报表工具的部门人员，但报表的数据来自IT部门。IT部门往往利用OLAP的概念建设数据模型，根据数据模型来制作报表，因此对IT部门而言，报表工具是指OLAP工具中的报表展现部分，比如Crystal Report等等。

而在使用报表操作的业务人员眼里，报表工具是代表报表本身功能（排版、计算、统计、图形等）的产品，它目前只有一个产品来代表了，就是EXCEL。

OLAP报表产品最大的难点在哪里？

目前报表工具最大的难点不在于报表的样式（如斜线等），样式虽较繁琐但并非本质困难。最根本的难点在于业务部门知道报表代表的真正含义，却不知道报表的数据统计模型模型；而IT部门通过理解业务部门的描述，在数据库端进行设置数据统计模型，却对报表本身所代表的价值很难理解。

这样的现状，导致报表工具无法两者兼顾，OLAP报表工具产品一直在数据模型设计层面（OLAP层面）和报表本身功能层面做出平衡。

目前OLAP报表产品制作复杂，报表一般会有什么症状？

首先，由于IT部门创建的数据统计模型不完全适应，导致报表制作经常需要编写代码、准备数据（如几十甚至上百行的SQL或存储过程），而且动辄就要进行繁琐的子表拼接，即使这样仍有许多报表无法完成，需与用户商量改变，运算性能也很差。

其次，由于IT部门根据业务部门进行报表制作时，对报表样式理解不专业，大部分报表采用拖拽式编辑，使报表样式绘制麻烦。

最后，业务部门报表的变化很频繁，导致IT部门模型设计和报表制作的滞后，业务部门工作受限，白费时间。

因此，在目前OLAP产品的设计下，BI项目变成日常统计系统，业务模型来自于咨询专家，企业发展过程中业务模型的变化因为OLAP工具而无法快速实现，使企业丢失对BI的信心。可以毫不夸张地说，OLAP产品正在毁掉BI。

OLAP错了还是用户错了？

这是一个困惑！其实我们可以从E.F.Codd博士定义的OLAP概念中找一找这个困惑的答案。OLAP是关系数据库之父E.F.Codd于1993年提出的一种数据动态分析模型，它允许以一种称为多维数据集的多维结构，访问来自商业数据源经过聚合和组织整理的数据。以此为标准，OLAP作为单独的一类产品同联机事务处理（OLTP）得以明显区分。

说起来有点深奥，其实并不复杂，OLAP最基本的概念只有三个：多维观察、数据钻取、CUBE运算。

关于多维角度：我们在平时工作中，会遇到各种问题，在分析问题的时候，同样的现象，我们会从多个角度去分析考虑，有时我们还会从几个角度综合起来进行分析。这就是OLAP分析最基本的概念——从多个观察角度的灵活组合来观察数据，从而发现数据内在规律。

OLAP将数据分为两种特征，一种为表现特征，比如一个销售分析模型中的销售额、毛利等；还有一种为角度特征，比如销售分析中的时间周期、产品类型、销售模式、销售区域等。前者是被观察的对象，OLAP术语称之为“度量数据”，后者为观察视角，OLAP术语称之为“维数据”。

如果建立这样一个模型，我们就可以根据业务需求，从产品类型角度，去观察各个销售地区的销售额数据（以产品类型和销售地区为维、以销售额为度量）；或者我们还可以从销售模式的角度，去观察各个销售地区的销售额数据（以销售模式和销售地区为维、以销售额为度量）。

关于数据钻取：在分析过程中，我们可能需要在现有数据基础上，将数据进一步细化，以获得更为精确的认识。这就是OLAP中数据钻取的概念。

比如，在销售分析中，当我们以产品类型和销售地区为维、以销售额为度量进行分析的时候，可能希望进一步观察某类产品的不同销售模式在各个销售地区的表现，这时我们就可以在产品大类这个数据维下面，再加上一个销售模式维，从而获得相应的信息。

关于CUBE运算：OLAP分析所需的原始数据量是非常庞大的。一个分析模型，往往会涉及数百万、数千万条数据，甚至更多；而分析模型中包含多个维数据，这些维又可以由浏览者作任意的提取组合。这样的结果就是大量的实时运算导致时间的延滞。

我们可以设想，一个1000万条记录的分析模型，如果一次提取4个维度进行组合分析，那么实际的运算次数将达到4的1000次方的数量。这样的运算量将导致数十分钟乃至更长的等待时间。如果用户对维组合次序进行调整，或增加、或减少某些维度的话，又将是一个重新的计算过程。

从上面的分析中，我们可以得出结论，如果不能解决OLAP运算效率问题的话，OLAP将是一个毫无实用价值的概念。那么，一个成熟产品是如何解决这个问题的呢？这涉及到OLAP中一个非常重要的技术——数据CUBE预运算。

一个OLAP模型中，度量数据和维数据我们应该事先确定，一旦两者确定下来，我们可以对数据进行预先的处理。在正式发布之前，将数据根据维进行最大限度的聚类运算，运算中会考虑到各种维组合情况，运算结果将生成一个数据CUBE，并保存在服务器上。

这样，当最终用户在调阅这个分析模型的时候，就可以直接使用这个CUBE，在此基础上根据用户的维选择和维组合进行复运算，从而达到实时响应的效果。

从以上OLAP三点基本概念出发，我们可以在实践中发现问题的所在，OLAP概念没有错，用户也没有错，错在目前业内的OLAP产品的设计思路上！

从OLAP产品来看，由于“多维角度”的变化来自于用户部门，而IT部门采用的OLAP产品使“多维角度”转化成数据库设计，但为了实现“CUBE运算”，“度量数据”和“维数据”需要提前固化，这样限制了业务部门对“多维角度”快速变化的要求，使BI项目变成了日常统计报表项目，使OLAP分析变得无法实现。

OLAP产品需要新一代工具

新一代OLAP工具设计的思想，不应该关注报表工具本身功能：IT部门不要制作报表，仅关注OLAP的功能，不需要做OLAP的报表展现，报表完全由业务部门来实现。主要基于以下两点：

一．从桌面报表的使用能力和使用量来描述，业务部门的人员已经远远超过IT部门的人员，因此，IT部门目前不太可能提供出一个报表工具，来取代业务部门使用的桌面报表工具。

二．报表本身的含义需要业务部门用精湛的业务知识来诠释，如果报表由IT部门来制作的话，会出现知识传递过程中的误差，这是OLAP实施中最大的问题。

基于以上两点，新一代OLAP工具设计思想就是：如何使OLAP工具和Excel报表工具能够无缝交流，应该有一个“分析角度”的技术，来实现业务部门和IT部门对“多维角度”的各自表述。让业务部门自己来做“分析角度”，自己来做报表，让IT部门利用OLAP概念来设计基础数据。