被狭义化的 OLAP

OLAP 这个词从字面上理解是在线分析的意思，也就是由人员面对数据进行各种交互式的分析操作。

但是，现在的 OLAP 概念被严重狭义化了。说到 OLAP，经常是仅指多维分析，也就是针对一个事先建设好的数据立方体，按指定维度层次进行汇总并呈现成表格或图形，再辅以钻取、聚合、旋转、切片等操作以变换维度层次及汇总范围。这些大家都很熟悉，就不再细说了。

多维分析就是在线分析的全部吗？

更广义的 OLAP 过程

我们来考察这样一种数据分析过程。

任何一个行业中有多年工作经验的从业人员一般都会对自己从事的业务产生一些猜测，如：

股票分析师会猜测满足某种条件的股票容易上涨；

公司经理对哪些销售员擅长对付难度大的客户心里会有数；

班主任也大概知道偏科同学的成绩都有什么特征；

…

这些猜测是预测的基础。业务系统运行一段时间后会积累出大量数据，这些猜测就很可能被这些积累的数据验证，证实了则可作为一种规律性的结论，用于指导下一步的动作，证伪了则再重新猜测。

这才是在线分析应该做的事情！基本的动作就是猜测和验证，其目的是从历史数据中找到规律或支撑某些结论的论据。而在线分析软件要做的事情，就是帮助使用人员针对数据去验证猜测。

这里需要注意的是，这些猜测都是由有业务经验的人做出的，而不是软件系统！之所以需要在线，是由于许多猜测都是使用人员看到了某个中间结果后临时想出来的。不可能也不需要事先设计端到端的完整路径，也就是无法建模。

技术上，就是需要让使用人员有能力对数据进行灵活交互式的查询和计算。比如结合上面举的例子，用户要完成的计算可能是这样的：

这个月内连涨 3 天的股票，第 4 天还继续上涨的比率有多大？

哪些半年不出单的客户在更换了销售人员后半年就出单了？

语文和数学成绩都在前 10 名的学生，英语成绩排名是怎样的？

…

多维分析的局限

显然，上述信息都可以由历史数据计算出来，但是，用多维分析技术能实现吗？

恐怕不能！

多维分析在技术上有两个不足：一是立方体要事先准备，使用人员通常没有临时设计和改造立方体的能力，一旦有新的分析需求则必须重建立方体；二是立方体上可实施的分析动作单调，只有钻取、聚合、切片、旋转等少数几种，难以完成多步骤的复杂计算行为。近年来流行的敏捷 BI 产品都有多维分析功能，在操作的流畅性和界面的炫丽度都较早期 OLAP 产品有较大的提升，但本质功能并没有变，该不能算的还是不能算。

多维分析确实能够得到一些有益的信息，比如经常举的例子，成本过高时可以精确定位出到底是哪个部门和业务造成的。但是，多维分析却得不到前述例子中我们希望从数据中获得的规律性结论，而毕竟有了规律性结论才能预测并指导工作。从这个意义上讲，把在线分析仅仅理解成多维分析是不完整的。

我们需要怎样的 OLAP？

用于规律发现（更确切地说是规律验证）的 OLAP 软件应当是什么样的呢？

前面说过，从技术上讲，规律验证可以看成是一种针对数据的查询和计算过程，其关键点在于这种过程可以由分析人员自由定义。结合当前的应用环境，我们认为这种 OLAP 体系应当具体这样两种功能：

1. 关联查询

分析的第一步是获取数据。许多企业都有建设好的数据仓库，可由分析人员自行查询。这里强调关联的意义在于，绝大多数软件都不能很好地让分析人员在界面上实现带有关联的查询需求，必须事先由技术部门建模消除关联（类似多维分析的立方体建设），而分析人员的需求常常超过事先建模的范围，又必须求助于技术部门，这样就使在线分析的基础不存在了。

2. 交互计算

获取数据后就是计算。这种计算的特点在于要根据上一步的结果临时决定下一步动作，不能事先设计过程，所以必须是交互式的，很象计算器的模式。另外，这里需要计算的数据都是批量的结构化数据，而非简单的数值，区别于普通数值计算器，可以把这个功能形象地称为数据计算器。Excel 在一定程度上就拥有这种能力，使得它事实上成为应用最广泛的桌面分析工具。不过 Excel 对于较复杂的数据运算以及反复要执行的运算支持还不够好，比如刚才举例中的计算都不容易完成。虽然可以借助 VBA 编程解决，但 VBA 不是一种集合化的程序语言，代码编写复杂度太高。至于 Python，只是看上去很美，实际上很难，大部分人根本学不会。

那么，该如何妥善地提供这两个功能呢？关注这里就会有答案