开源 SPL 重新定义 OLAP Server
OLAP（Online Analytical Processing）是指在线联机分析，基于数据查询计算并实时获得返回结果。日常业务中的报表、数据查询、多维分析等一切需要即时返回结果的数据查询任务都属于 OLAP 的范畴。对应的，行业内也有相应产品来满足这类需求，那就是 OLAP Server。
OLAP Server 现状
当前主流 OLAP Server 几乎都是基于 RDB 或封装成 RDB 的大数据平台，有点类似早期的 ROLAP（这个词已经很少被提及了），其中一个关键的特征是使用 SQL 作为查询语言。
RDB 和 SQL 的特性会给 OLAP Server 带来诸多困难。
复杂报表困难
事实上，报表才是 OLAP 业务的重头戏，OLAP 的查询需求中有相当大一部分都是事先做好的报表查询界面，而不是自由拖拽的多维分析，而复杂报表又经常占据报表需求的一半以上。这类报表的典型特点是数据处理逻辑复杂，每个报表都需要单独编写代码进行数据准备，常见的做法是使用复杂 SQL 或存储过程，如果碰到一些数据库无法实现的场景（如文件等外部数据源、跨数据源计算、前后端分离等）还需要通过 JAVA 完成，过程十分繁琐。
SQL 实现这些计算很难，存储过程也有很多缺点（无移植性、有安全隐患等）导致越来越少使用，Java 集合运算困难且无法热切换而难以适应复杂多变的报表需求。当前 OLAP Server 在复杂报表这方面就表现的很不理想了。
自助关联差
即使不管复杂报表，只考虑多维分析的这种基础的 OLAP 任务，使用 SQL 作为查询语言时也很难胜任，只能解决一小部分无关联的单表分析，满足一些相对固定的多维分析需求，适用范围很小，难以适应灵活的自助分析场景。
体系封闭
当前 OLAP Server 严重依赖数据库，数据库有“库”的概念，数据只有“入库”才能处理，而且通常只能同时处理一个数据库，无法同时计算数据库外部的数据。而 OLAP 名为在线分析，业务上还要求做 T+0 式的实时查询分析。其他数据源的数据需要先 ETL 到数据库中才能计算，这就造成了不实时。典型的场景是 OLAP 业务经常要查询业务库的实时数据，要将实时数据（业务库）和历史数据（分析库）混合查询分析（T+0 查询），这是当前 OLAP Server 难以满足的。何况还有很多非关系数据库的数据也无法被 OLAP Server 直接计算。
性能低
退一步来讲，即使只关注历史数据，不考虑实时生产数据，也只使用单一的数据库，当前 OLAP 查询也面临性能低的问题，我们经常会遇到查询报表要等几分钟、实时查询不实时、多维分析卡顿的情况。根本原因仍然是 SQL 的问题，基于关系代数理论的 SQL 难以实现高性能算法，仅靠数据库在工程上优化并不能根本解决问题，SQL 复杂时数据库优化经常无效而导致性能仍然很低。
开源 SPL 重新定义 OLAP Server
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 写要简单得多：
| A | |
| 1 | =T(“/dw/stockRecord.txt”) |
| 2 | =A1.group@i(closePrice< closePrice[-1]).max(~.len()) |
SPL 提倡分步运算，复杂计算可以按照自然思维一步一步实现。
再借助 SPL 丰富的计算类库可以大幅简化数据处理难度。
针对 SQL 的调试困难，SPL 还提供了简洁易用的开发环境，单步执行、设置断点，所见即所得的结果预览窗口…
业务开展过程中报表会不断新增、修改。使用报表工具可以解决报表呈现模板的快速制作，但却无法应对复杂多变的报表数据准备，以往无论使用 SQL/ 存储过程还是 Java 都难以很好应对。
使用 SPL 完成报表数据准备，可以实现报表数据准备工具化，加之原有呈现端的报表工具，使报表开发全面工具化，从而低成本、快速地应对没完没了的报表。
SPL 是解释执行的程序语言，天然支持热切换。报表（数据准备）修改无需重启服务即可生效，以适应不断修改的报表需求。
不仅如此，借助 SPL 敏捷和易切换特性，还可以很好与微服务等开发框架融合。SPL 提供不依赖数据库的计算能力，算法外置完成微服务数据处理，相对 Java 硬编码也更有优势，能有效降低应用各个模块间的耦合性。
体系开放
相对传统 OLAP Server 的封闭性，基于 SPL 实现的 OLAP Sever 体系则更加开放。SPL 的计算不依赖于数据库，也不再有“库”的限制，甚至没有“库“的概念。无论什么数据源都可以直接使用，CSV、Excel、JSON/XML、NoSQL、RestAPI、HDFS、Kafka、Elasticsearch、SAP 均能支持，还可以进行混合计算。数据源可以来自本地应用系统，也可以是外部系统或者远程云应用。
这种开放的计算体系能很方便完成 T+0 实时数据查询，同时连接存储热数据的业务库和存储冷数据的分析库（或文件）进行混合计算即可实现 T+0。
高性能
SPL 没有基于关系代数理论，而是创新地发明了离散数据集代数。这样，很多 SQL 很难实现的高性能算法及存储方案用 SPL 却可以轻松实现，而软件提高性能关键就在于算法和存储。
例如，SPL 支持更彻底的集合化，可以把 TopN 理解为聚合运算，这样可以将高复杂度的排序转换成低复杂度的聚合运算，而且很还能扩展应用范围。
| A | ||
| 1 | =file(“data.ctx”).create().cursor() | |
| 2 | =A1.groups(;top(10,amount)) | 金额在前 10 名的订单 |
| 3 | =A1.groups(area;top(10,amount)) | 每个地区金额在前 10 名的订单 |
SQL 描述上面的运算会涉及大排序，性能非常低下，只能寄希望于数据库的优化。但在稍复杂的情况（比如 A3 中伴随分组运算）数据库优化器就会失效。
再比如，SPL 的游标支持复用，可以在一次遍历中聚合出多个结果。
| A | ||
| 1 | =file(“order.ctx”).create().cursor() | 准备遍历 |
| 2 | =channel(A1).groups(product;count(1):N) | 配置复用计算 |
| 3 | =A1.groups(area;sum(amount):amount) | 遍历，并获得分组结果 |
| 4 | =A2.result() | 取出复用运算的结果 |
而 SQL 无法描述这种算法，实现上述运算就会不可避免地将大数据遍历多次，造成性能低下。而且这个问题还是理论层面的，数据库优化引擎无能为力。
SPL 提供的其它与 OLAP 业务相关性能优化技术还有：有序归并实现订单和明细之间的关联、预关联技术实现多维分析中的多层维表关联、位存储技术实现上千个标签统计、布尔集合技术实现多个枚举值过滤条件的查询提速、时序分组技术实现复杂的漏斗分析，倍增分段存储技术实现列存的平滑并行、…。其中有相当一部分是 SPL 发明的算法。
用 TPCH 国际标准实测，SPL 能在低性能 ARM 芯片上跑出比高性能 Intel 芯片上 Oracle 快出数倍的成绩，这就是创新算法带来的优势。。
在 SPL 的高性能算法和存储方案的支持下，历史大数据的计算会获得更高的性能，配合实时业务热数据进行混合查询还可以进一步提升 T+0 查询效率。
关联查询
针对传统 OLAP Server 多维分析时关联能力差的问题，基于 SPL 还发展了一种关联查询分析语法 DQL。DQL（Dimensional Query Language）是以维度为核心的类 SQL 查询语言在解决表间关联问题时采用了与 SQL 不同的思路。
当前基于 SQL 的 OLAP Server 在实现多表关联时并没有特别好的办法，要么采用逻辑宽表，但由于会产生过多字段（维表字段会被复制多次，多层关联、自关联、循环关联都会加剧这种情况）导致用户无法使用，而且性能也很差。有些 BI 产品可以根据用户选择的字段在页面上自动关联，但只适用简单的的情况，当遇到同维字段（如同一个表有 2 个以上地区字段）时就无法匹配了，自关联的情况也没法处理。将表和字段都开放给用户让用户自己关联显然更不现实。
那么 DQL 是如何处理的呢？比如这样一句 SQL：
--SQL SELECT A.* FROM EMPLOYEE A, DEPARTMENT B, EMPLOYEE C WHERE A.country='USA' AND C. country ='China' AND A. dept_id =B. dept_id AND B. manager=C. emp_id
其中涉及多表和自关联，很难让业务用户在 BI 界面中正确地描述出其中的关联关系。
而同样的查询用 DQL 写出来是这样：
--DQL SELECT * FROM EMPLOYEE WHERE country ='USA' AND dept_id.manager.country ='China’
将复杂的多表关联转换成了简单的单表查询，普通业务用户都能理解并在界面中自行实施。
总结
SPL 及 DQL 的问世，将对 OLAP Server 产生深刻的影响。
基于 SPL 的敏捷性（过程计算、算法外置、解释执行）可以很好适应 OLAP 业务中复杂报表的需要，快速开发、热切换、低耦合可以很好与微服务融合；开放的计算体系以及无约束数据组织形式打破了传统 OLAP 产品的封闭性，可以直接使用各类数据源，轻松实现 T+0 查询；通过基于 SPL 的 DQL 则可以解决多维分析时的实时关联查询的难题；SPL 的高性能算法和存储技术则保证了 OLAP 运算性能，高效完成报表查询、T+0 查询、多维分析等查询分析任务。
我们期待基于 SPL 技术的新一代 OLAP Server 以及 BI 产品的出现。
