开源 SPL 重新定义 OLAP Server

??技术活，该赏

??点赞 ?? 收藏 ?再看，养成习惯

PC端左侧加我微信，进群，有送书等更多活动！

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复杂时数据库优化经常无效而导致性能仍然很低。