OLAP工具毁了商业智能

本文主要是介绍OLAP工具毁了商业智能，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

转自: http://www.itpub.net 作者: interstage

OLAP工具毁了商业智能

以下文章，是我从98年开始研究并从事BI项目以来10年的心得，仅供参考！！！

为什么说目前的OLAP产品毁了BI项目

企业为了确定经营战略和市场战略所进行的经营活动，在分析决策过程（BI项目）中，需要基于多种报告和报表进行分析。理想的市场活动展开，大多需要各个营业点的销售报表，每种商品按季节销售的业绩图表等，这就势必需要大量准确的并且易于判断的数据。这些数据所形成数据表和图表就是我们所说的报表，在业中更是需要有效利用这样的报表进行分析决策活动。
然而，对于作为使用者的一般员工或者IT部门员工来说，是一个很大的工作量负担。因为数据的分析需要先获得必要的数据信息，这就必须预先知道数据采集和数据加工计算的方法。当然，还有必要掌握数据库构成和数据存取语言的一些专门的知识。因此这些工作以前全都是经由IT部门人员用OLAP产品来完成的。信息管理部门要根据用户的要求把报表格式设计好，然后根据用户的目的开发出应用程序以及建立数据库等来完成这项工作。

OLAP报表工具是指什么？
　在报表市场上，有一个奇特的现象：IT部门的技术人员是企业所有部门中最不熟悉使用报表工具的部门人员，但报表的数据来源来自IT部门，IT部门往往利用OLAP的概念建设数据模型，根据数据模型来制作报表，因此对IT部门而言，报表工具是指OLAP工具中的报表展现部分，比如Crystal Report等等。
而在使用报表操作的业务人员眼里，报表工具是代表报表本身功能（（排版，计算，统计，图形等）的产品，这种产品目前只有一个产品来代表了，就是EXCEL！！

目前OLAP报表产品最大的难点在哪里？
　其实一张报表的制作，首先需要获得必要的数据信息，这就必须预先知道数据采集和数据加工计算的方法，就是数据模型。当然，还有必要掌握数据库构成和数据存取语言的一些专门的知识。而这些工作以前全都是经由IT部门的技术人员来完成的。IT部门要根据业务部门的要求把报表格式设计好，然后根据业务部门的目的来制作报表以及建立数据模型等来完成这项工作。
因此，目前报表工具最大的难点不在于报表的样式（如斜线等），样式虽较繁琐但并非本质困难。最根本的难点在于业务部门知道报表代表的真正含义，却不知道报表的数据统计模型模型；而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工具

新一代OLAP工具设计的思想，不应该关注报表工具本身功能（排版、统计、图形、计算等等），应该是IT部门不要来制作报表，仅关注OLAP的功能，不需要做OLAP的报表展现，报表完全由业务部门来实现！！！主要基于以下2点：
1，从桌面报表的使用能力和使用量来描述，业务部门的人员已经远远超过IT部门的人员，因此，IT部门目前不太可能提供出一个报表工具来取代业务部门使用的桌面报表工具。
2，报表本身的含义需要业务部门的精湛的业务知识来诠释，而如果报表由IT部门来制作的话，会出现知识传递过程中的误差，因此，这是目前OLAP实施中最大的问题。

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