OLAP 这个词从字面上理解是在线分析的意思，也就是由人员面对数据进行各种交互式的分析操作。
但是，现在的OLAP 概念被 BI 软件给严重狭义化了。面向业务分析时说到 OLAP，在技术上经常就只有多维分析的功能，也就是针对一个事先建设好的数据立方体，按指定维度层次进行汇总并呈现成表格或图形，再辅以钻取、聚合、旋转、切片等操作以变换维度层次及汇总范围。这些大家都很熟悉，就不再细说了。
多维分析就是在线分析的全部吗？

我们来考察这样一种数据分析过程。
任何一个行业中有多年工作经验的从业人员一般都会对自己从事的业务产生一些猜测，如：

股票分析师会猜测满足某种条件的股票容易上涨；
公司经理对哪些销售员擅长对付难度大的客户心里会有数；
班主任也大概知道偏科同学的成绩都有什么特征；
…

这些猜测是预测的基础。业务系统运行一段时间后会积累出大量数据，这些猜测就很可能被这些积累的数据验证，证实了则可作为一种规律性的结论，用于指导下一步的动作，证伪了则再重新猜测。
这才是在线分析应该做的事情！基本的动作就是猜测和验证，其目的是从历史数据中找到规律或支撑某些结论的论据。而在线分析软件要做的事情，就是帮助使用人员针对数据去验证猜测。

这里需要注意的是，这些猜测都是由有业务经验的人做出的，而不是软件系统！之所以需要在线，是由于许多猜测都是使用人员看到了某个中间结果后临时想出来的。不可能也不需要事先设计端到端的完整路径，也就是无法建模。
技术上，就是需要让使用人员有能力对数据进行灵活交互式的查询和计算。比如结合上面举的例子，用户要完成的计算可能是这样的：

这个月内连涨3天的股票，第4天还继续上涨的比率有多大？
哪些半年不出单的客户在更换了销售人员后半年就出单了？
语文和数学成绩都在前10名的学生，英语成绩排名是怎样的？
...

显然，上述问题都可以通过对历史数据计算而回答出来，但是，用多维分析技术能实现吗？
恐怕不能！
多维分析在技术上有两个不足：一是立方体要事先准备，使用人员通常没有临时设计和改造立方体的能力，一旦有新的分析需求则必须重建立方体；二是立方体上可实施的分析动作单调，只有钻取、聚合、切片、旋转等少数几种，难以完成多步骤的复杂计算行为。近年来流行的敏捷 BI 产品在操作的流畅性和界面的炫丽度都较早期 OLAP 产品有较大的提升，但本质计算功能并没有增长多少，还是在做多维分析，该不能算的还是不能算。
多维分析确实能够得到一些有益的信息，比如经常举的例子，成本过高时可以精确定位出到底是哪个部门和业务造成的。但是，多维分析却得不到前述例子中我们希望从数据中获得的规律性结论，而毕竟有了规律性结论才能预测并指导工作。从这个意义上讲，把在线分析仅仅理解成多维分析是不完整的。

那么，用于规律发现（更确切地说是规律验证）的 OLAP/BI 软件应当是什么样的呢？
前面说过，从技术上讲，规律验证可以看成是一种针对数据的查询和计算过程，其关键点在于这种过程可以由分析人员自由定义，也就是 OLAP/BI 软件应当具有由业务人员自主实施交互计算的功能。
获取数据后就是计算。这种计算的特点在于要根据上一步的结果临时决定下一步动作，不能事先设计过程，所以必须是交互式的，很象计算器的模式。另外，这里需要计算的数据都是批量的结构化数据，而非简单的数值，区别于普通数值计算器，可以把这个功能形象地称为数据表格计算器。
Excel 在一定程度上就拥有这种能力，结果事实上 Excel 才是成为应用最广泛的桌面分析工具。不过 Excel 对于较复杂的数据运算以及要反复要执行的动作也会力不从心，比如刚才举例中的计算都不是很容易直接用 Excel 中完成。

这时候就要借助编程的力量了，支持步骤的程序语言可以写出非常复杂的运算。但遗憾的是，没有多少合适的程序语言。作为 Excel 中自带的程序语言，VBA 天然可以运行在 Excel 中，但 VBA 不是一种集合化的语法，代码编程复杂度很高，也不擅长处理结构化数据。至于 Python，我们之前也讲过，它只是看上去很美，实际上很难，大部分人根本学不会，而且只能运行在 Excel 的外部，也很不方便。
业内可能只有 esProc SPL 才是适合 Excel 分析师使用的程序语言了，SPL 有强大的结构化数据处理能力，特别地，SPL 还提供了 Excel 插件，允许用户在 Excel 中直接使用 SPL 代码完成 Excel 很难实现的复杂运算。

编程有一定的门槛，还是有些业务分析人员学不会编程，那这些问题可以由技术人员配合解决。这时候 OLAP 软件要做的事就不是让业务人员自己实现过程计算，而是要提高业务人员获取技术资源的效率，以及技术人员实现需求的开发效率。
具体来讲有两个方面：一是建立历史问题库，某些以前曾经做过的问题，可以由业务人员直接调出算法改变参数执行；即使是新需求，也可以找到类似问题以协助技术人员准确理解，技术人员和业务人员的理解不一致是造成事务延期的主要因素之一；二是提供高效且可管理的开发技术，让技术人员能快速编写和修改计算代码，并可将这些代码存入历史算法库中保管和再次执行。
不过，这件事业界也没有多少适合的技术，SQL 可管理性较好，但编写繁琐而难以处理有过程计算；存储过程需要再编译而不方便再次执行；Java 代码也要再编译而基本上不可管理；Python 这类脚本语言的集成性又较差，而且版本一致性不好，也难以入库管理和在较大范围内执行。
对于这个场景，esProc SPL 也是更好的选择。SPL 功能强大，代码开发效率高，还适合大数据，脚本化的代码也很容易入库管理和再次利用。