当前开源 OLAP 服务器仅能满足多维分析一方面的需求，而且主要基于 RDB 体系。这对于广泛的 OLAP 业务来说存在诸多限制。

首先是复杂报表不支持，这类报表的数据准备过程十分繁琐，需要大量编码（复杂 SQL/JAVA）才能实现，而报表是 OLAP 业务的大头，当前开源 OLAP 服务器并不满足。即使只考虑多维分析，OLAP 服务器也只能完成无关联单表查询，并不支持关联分析，灵活性受限。

另外，数据库的封闭性导致 OLAP 服务器只能计算库内数据，无法应对多样数据源场景，多数据源需要先“入库”才能计算，效率很低。SQL 很难实现高性能算法，性能也差。

现在好了，使用开源集算器 SPL 实现的 OLAP Server 可以很好解决上面的这些问题。

SPL 是结构化数据计算专用程序语言（Structured Process Language）的简称。SPL 提供丰富的计算类库和敏。、捷的开发语法可以快速完成各类复杂数据处理；SPL 的计算能力不依赖于数据库（数据源），天然支持多样性数据源，可以完成跨数据源混合计算，实现跨异构源的实时查询；SPL 内置了大量高性能算法和存储方案以及并行计算机制保证计算的高性能。

敏捷的过程计算适应复杂报表

在复杂数据处理方面，SPL 提供独立的敏捷语法支持过程计算，相对于 SQL，SPL 的语法更简洁，适合完成复杂报表数据准备。

比如要计算：一只股票最长连续上涨了多少天？

用 SQL 借助窗口函数还要写成四层嵌套的语句：

select max(continuousDays)-1  

from (select count(*) continuousDays  

from (select sum(changeSign) over(order by tradeDate) unRiseDays  

from (select tradeDate,  

case when closePrice>lag(closePrice) over(order by tradeDate)  

then 0 else 1 end changeSign

from stock) )

group by unRiseDays)

而同样的逻辑用 SPL 写要简单得多：

SPL 提倡分步运算，复杂计算可以按照自然思维一步一步实现。再借助 SPL 丰富的计算类库可以大幅简化数据处理难度。

针对 SQL 的调试困难，SPL 还提供了简洁易用的开发环境，单步执行、设置断点，所见即所得的结果预览窗口…

SPL 是解释执行的程序语言，天然支持热切换。报表（数据准备）修改无需重启服务即可生效，以适应不断修改的报表需求。

不仅如此，借助 SPL 敏捷和易切换特性，还可以很好与微服务等开发框架融合。SPL 提供不依赖数据库的计算能力，算法外置完成微服务数据处理，相对 Java 硬编码也更有优势，能有效降低应用各个模块间的耦合性。

体系开放

相对传统 OLAP Server 的封闭性，基于 SPL 实现的 OLAP Sever 体系则更加开放。SPL 的计算不依赖于数据库，也不再有“库”的限制，甚至没有“库“的概念。无论什么数据源都可以直接使用，CSV、Excel、JSON/XML、NoSQL、RestAPI、HDFS、Kafka、Elasticsearch、SAP 均能支持，还可以进行混合计算。数据源可以来自本地应用系统，也可以是外部系统或者远程云应用。这样可以很好实现 T+0 实时数据查询。

高性能

SPL 没有基于关系代数理论，而是创新地发明了离散数据集代数。这样，很多 SQL 很难实现的高性能算法及存储方案用 SPL 却可以轻松实现，而软件提高性能关键就在于算法和存储。

例如，SPL 支持更彻底的集合化，可以把 TopN 理解为聚合运算，这样可以将高复杂度的排序转换成低复杂度的聚合运算，而且很还能扩展应用范围。

用 TPCH 国际标准实测，SPL 能在低性能 ARM 芯片上跑出比高性能 Intel 芯片上 Oracle 快出数倍的成绩，这就是创新算法带来的优势。。

在 SPL 的高性能算法和存储方案的支持下，历史大数据的计算会获得更高的性能，配合实时业务热数据进行混合查询还可以进一步提升 T+0 查询效率。

开源 SPL 的问世，将对 OLAP Server 产生深刻的影响。

基于 SPL 的敏捷性（过程计算、算法外置、解释执行）可以很好适应 OLAP 业务中复杂报表的需要，快速开发、热切换、低耦合可以很好与微服务融合；开放的计算体系以及无约束数据组织形式打破了传统 OLAP 产品的封闭性，可以直接使用各类数据源，轻松实现 T+0 查询；SPL 的高性能算法和存储技术则保证了 OLAP 运算性能，高效完成报表查询、T+0 查询、多维分析等查询分析任务。