应用成本低出N倍的数据分析引擎esProc SPL

本篇可结合 《高效数据分析引擎》 阅读

高效数据分析引擎
右侧扫码查看 ⇨

目前网上有很多涉及 esProc SPL 的帖子，有方案介绍、测试报告、案例分享等，但这些材料大多只有某一方面，读者用户仍然难以整体理解。这里将原来各个点的内容串起来形成一个全貌，以便从整体上认识和理解 esProc SPL。

我们介绍的 esProc SPL 是一个数据分析引擎，具备 4 个主要特点：低代码、高性能、轻量级、全功能。SPL 不仅写得简单，跑得也更快，既可以独立使用还能与应用集成嵌入，同时适用于多种应用场景。使用 esProc SPL 实现数据分析业务，整体应用成本将比以 SQL 为代表的传统技术低出几倍。我们在后面会逐步解释。

esProc SPL 是什么？

首先我们来说一下 esProc SPL 是什么。

esProc SPL 是一款面向结构化和半结构化数据的计算和处理引擎，可以用做分析型数据库和数据计算中间件。esProc SPL 主要应用于线下跑批和在线查询两个数据分析型应用场景。值得一提的是，和市场上常见的分析型数据库不同，esProc SPL 并不是 SQL 体系的，但也不是常说的 NoSQL 技术（比如 MongoDB、HBase 等），而是采用了独创的 SPL（Structured Process Language）语法，相对现有的数据处理技术不仅编码更简单，运行效率也更高。

esProc SPL 具体能解决哪些痛点呢？

主要就是写着费劲、跑得慢和运维困难的数据问题。这里我们举几个例子。

现在很多行业都有跑批的业务，一般都是晚上业务空闲的时间做，因此会有一个固定的时间窗口，要在这个时间段内做完才行，否组就会影响业务。但随着业务的积累跑批的压力会越来越大，时间有限但业务和数据量越来越多，有时就会出现跑批跑不完的情况，月末年末这种现象更显著，担惊受怕的。

还有查报表，总有几张比较重要的查起来很慢，三两分钟甚至更长时间，优化几轮效果也不明显，导致用户拍桌子，业务不满意。有时查询人数一多，选择的时间跨度一大，就更查不出来了。

我们实际业务中还经常能见到那种超长超复杂的 SQL，嵌套 N 层不说，一句写下来要上千行，不光写得费劲，想改都没法改，过几天自己都看不懂。存储过程就更夸张，有时能达到几十上百 KB，编写维护都很费劲。

有些复杂计算用存储过程总还能写出来，相比 JAVA 还是简单一些。但是存储过程没有移植性，过度依赖又会造成应用无法扩展，耦合性高等应用结构问题。

另外我们现在数据源种类很多，光数据库就好多种，还有 NoSQL、文本、Excel、JSON 这些，想要把这些数据源混合在一起使用就比较困难，都导到数据库里吧不太值，不仅数据实时性差，还会占用数据库空间增加数据库压力；不入库吧硬编码又太难写，进退两难。

总体来说，像涉及跑批慢、查询慢等性能问题；数据库压力问题；SQL 难写难维护问题；多数据源混算问题；应用结构不合理问题，这些都是 esProc SPL 要解决的。

我们这里列出来的要更多，可以再看一下。

• 时间窗口不够，半夜跑批跑不完，出错来不及重来；月末年头担惊受怕

• 出个报表十分钟，业务人员拍桌子；预计算难预测，业务人员不满意

• 在线用户多一点，时间跨度长一点，数据库就像死了一样

• N 层嵌套长 SQL，存储过程几十 K，过几天自己都看不懂

• DB/NoSQL/ 文本 /Json/Web 几十种数据源，做梦都想跨源混合算

• 数据量大了冷热数据分库，再想全量（T+0）统计难死人

• 过度依赖存储过程，应用难移植，架构难调整

• 数据库里表太多，存储计算资源耗尽，想删不敢删

• 报表没完没了做不完，人员成本投入何时休

• ……

当然，esProc SPL 面向的场景现在也都有相应技术在处理。那么 esProc SPL 主要对标哪些技术呢？

最主要的一类是采用 SQL 语法应用于 OLAP 场景的数据库和数据仓库。如常规的 MySQL、PostgreSQL、Oracle、DB2 等关系型数据库；还有 Hive、Spark SQL 等 Hadoop 体系的数据仓库；以及新型的 MPP 数据仓库和云数据仓库，如 Snowflake 等；还有一类商用数据库一体机，像 Oracle 的 ExaData。

从开发语言的角度来看，SPL 还可以替代一些其他数据分析和统计技术。如 Python，Scala，Java，Kotlin 等。

esProc SPL 相对这些技术更具备低代码、高性能、轻量级、全功能等特点。SPL 在实施计算尤其是复杂计算时更简洁，比 Python、SQL 这些都要简单，也就是更低代码；esProc SPL 提供了大量高性能算法以及高性能存储可以达到更快的计算速度；esProc SPL 可以独立使用也可以集成嵌入，还可以基于多种数据源直接计算，具备更加轻量开放的特性；SPL 除了提供常规运算能力，还提供了很多包括矩阵、拟合甚至 AI 建模的函数，绝大多数数据任务都可以在 SPL 体系内轻松完成，功能更加全面。

SPL 最主要的对标技术还是 SQL，毕竟 SQL 在数据分析领域应用最为广泛。那么 SPL 相对 SQL 有哪些优势呢？

从现代复杂业务和大数据的视角去审视 SQL 会发现，SQL 的计算描述能力是不足的，由于缺少必要的数据类型和计算特性（如有序计算）使得 SQL 在实现复杂计算时经常要采用多层嵌套反复迂回的方式实现，这就带来了两个问题。

首先是开发成本。我们在实际业务中不难看到上千行的 SQL，只要计算逻辑稍复杂 SQL 就要写成嵌套多层的一大串，不仅难写难调试，经常过一段时间自己都看不懂，这势必会造成开发成本的增加。而 SPL 提供了更加丰富的数据类型和计算特性使得计算描述能力大大增强。除了更加敏捷的语法体系外，SPL 还提倡分步编码，我们可以按照“多步骤”的自然思维实现复杂计算逻辑，好写好调试，可以大幅降低开发成本。

SQL 写的复杂还会带来性能方面的问题，明明有更高效的方式但却无法实现，只能忍受慢算法。想要达到目标性能指标就需要更多的硬件资源，造成硬件成本增加。SPL 封装了大量高性能算法（及存储），要达到目标性能需要的硬件更少，硬件成本有效降低，后面我们会看到很多 SPL 使用较少硬件就能达到或超越 SQL 性能的案例。

SQL（数据库）的计算体系是封闭的，数据只有进来才能算，而且通常只能独立使用，这样会导致架构臃肿沉重；另外 SQL 的计算能力其实不完善，有些复杂计算场景并不适合用 SQL 独立完成，还要使用 Python、Java 等补足 SQL 短板，但这些风格完全迥异的技术会增加技术栈的复杂度。SQL 沉重臃肿的架构加上复杂的技术栈会大幅增加运维成本。相比之下，SPL 的计算能力更加开放，可以基于各类数据源直接计算，支持独立或集成使用，架构更加轻盈；同时提供了全面的功能，很容易实现复杂计算，完成绝大多数任务都不需要借助其它技术，技术栈更简单。轻盈的架构加上单一的技术栈使得运维成本更低。

总的来讲，SPL 相对 SQL 可以达到在开发、硬件、运维三方面成本降低数倍的效果。

案例简析

我们来看看 esProc SPL 的实际应用效果。

首先是两个跑批的案例。

 案例  某保险公司车险跑批

某保险公司的车险跑批场景，需要用新保单关联历史保单以便提醒用户续保。保单表有 3500 万行，明细表 1.23 亿行数据量比较大；同时由于关联方式多样需要分别处理计算也很复杂。原来客户使用 informix 的存储过程完成，30 天新增保单计算需要 112 分钟，如果时间跨度再大就很难算出来了，存在性能问题。

采用 esProc SPL 来改造，30 天新增保单计算 17 分钟就可以完成，提升了 6.5 倍，同时代码量由原来的 1800 行降低到 500 行。这就是我们说的，SPL 写得简单跑得也快。

案例详情：开源 SPL 优化保险公司跑批优从 2 小时到 17 分钟

 案例  某银行对公贷款业务跑批

这个案例也是一个跑批场景，某银行用 AIX 小机 +DB2（银行的标配）跑批，其中一个“对公贷款协议明细”存储过程运算时间需要 1.5 小时。这个计算涉及 48 个 SQL 步骤，十分复杂的多表关联，代码量有 3300 行。由于这个跑批任务是整个银行跑批任务的一个环节，这个环节慢就会拖累整体跑批过程，急需优化。

用 SPL 来做 10 分钟就可以完成，提速了 8.5 倍，代码量从 3300 行降到 500 行。这里主要利用了 SPL 的有序计算、遍历复用等特性。

案例详情：开源 SPL 提速银行贷款协议跑批 10+ 倍

下面我们再来看两个在线查询的案例。

 案例  手机银行多并发帐户查询

银行要对外提供手机银行活期明细查询，并发量大要求实时性高。使用 Hadoop 没法满足并发要求，后来搭建了 6 台 ES 集群作为查询后台，这回能满足并发需要了，但却无法实时关联，每次机构代码发生变化数据更新就要几个小时，更新过程中要停机，就会影响业务使用。

使用 esProc SPL 以后将明细数据按照账号排序存储，利用外存索引和有序技术就可以快速读取该账号信息与内存中的机构编码关联，既能满足实时查询的需要，又能实现实时关联，还同时可以应付高并发的需要。最终，esProc SPL 使用 1 台服务器就达到了原来 6 台 ES 的效果，并且实现了实时关联，机构信息更新用户零等待。

案例详情：开源 SPL 将银行手机账户查询的预先关联变成实时关联

 案例  某银行贷款去重户数指标统计

银行贷款业务涉及的指标数量很多，像贷款余额、担保类型、客户类型、放款方式等等，数百个指标之间相互组合形成庞大的计算规模，而且伴随高并发进一步加剧计算难度。这个场景计算过程中都需要对 2000 万行大表及更大的明细表关联、过滤、汇总计算，每个页面涉及近 200 指标计算，10 并发共 2000 多指标同时计算。如此庞大的计算规模只能提前一天使用 Oracle 预计算的方式完成，但预计算又无法满足业务需要。

使用 SPL 改造时借助有序归并、布尔维序列以及多线程并行等手段进行了指标实时计算，并且达到了性能需要，10 并发共 2000 指标计算不到 3 秒。数据无需预先计算，临时选择任意标签组合，实时查询结果。

案例详情：开源 SPL 优化银行预计算固定查询成实时灵活查询

离线跑批和在线查询有很大不同，跑批业务涉及的数据量往往很大，计算逻辑也很复杂，但没有并发，也不要求计算的实时性，只要在规定时间内算完就行；而在线查询则刚好相反，并发量大，实时性要求高通常很难实现加工。这两类场景，esProc SPL 都能很好满足。

其实不仅是开发效率和性能，在应用结构方面 esProc SPL 也能提供很大帮助。我们再来看两个案例。

 案例  某银行 BI 系统的前置数据库

这个银行建设有中央数据仓库，但由于中央数据仓库承担全行的数据任务压力很大，所以只能分配给 BI 系统 5 个并发，无法满足需要。

所以要解决这个问题就需要搭建一个前置数据库（银行称为前置机）专门为 BI 系统服务。但使用数据库搭建时面临一个问题，如果仅把高频使用数据从数据仓库导入前置机当涉及查询其他数据时就查不到，无法响应业务需求；如果把所有数据都导入前置机又不现实，这相当于重新建设一个数据仓库，代价太大。

使用 esProc SPL 搭建前置机，仅把高频数据导入前置机即可，这样可以避免重复建设。esProc SPL 承担绝大多数的高频计算任务，剩下少量低频任务通过 esProc SPL 自动路由到中央数据仓库由数据仓库响应，这样就解决了前面提到的两个问题。这里的关键就是 esProc SPL 提供的自动路由功能。

 案例  某保险公司 - 库外存储过程

另外一个案例是使用 esProc SPL 充当 Vertica 存储过程。客户是一家加拿大保险公司，他们使用 Vertica、MySQL、Access 等数据库，主要面临两个问题。由于 Vertica 不支持存储过程，涉及复杂计算时只能借助 Java 硬编码实现十分困难；当涉及多个数据源混合计算时，需要将 MySQL 等数据先导入 Vertica 再使用，不仅十分繁琐，数据也不实时，导入后还会导致 Vertica 数据库臃肿，毕竟有些数据是不需要持久化的。

使用 esProc SPL 主要完成了两件事儿。一是在 Vertica 外充当库外存储过程，将原来需要硬编码的计算都用 esProc SPL 来接管，实现不仅简单而且更高效。二是借助 esProc SPL 的跨数据源计算能力直接基于多源进行混算，不再需要将数据同库就可以直接完成，数据实时性更高，效率也更高，同时保持 Vertica 更加清爽。

通过这几个案例我们基本能了解到 esProc SPL 的适用场景和应用效果。当然 esProc SPL 还有很多案例，这里我们就不再过多介绍了。

esProc SPL 凭什么？

从上面的案例，我们可以看到， SPL 在代码效率和运算性能两个方面都比 SQL 有非常明显的优势。那么是 SPL 有什么特别的过人之处吗？

其实，这个问题应该反过来问，并不是 SPL 为什么做得更好，而是 SQL 为什么做得不好。

先看 SQL 为什么这么难写。这个例子是要计算一支股票最长连涨了多少天？

select max (consecutive_day)
from (select count(*) (consecutive_day
    from (select sum(rise_mark) over(order by trade_date) days_no_gain
        from (select trade_date,
                case when closing_price>lag(closing_price) over(order by trade_date)
                    then 0 else 1 END rise_mark
            from stock_price ) )
    group by days_no_gain)

SQL 采用了这样嵌套 4 层的写法，整体比较绕。这道题曾经作为我司的招聘考题，通过率不足 20%；因为太难，后来被改成另一种方式：把 SQL 语句写出来让应聘者解释它在算什么，通过率依然不高。这说明什么？说明情况稍有复杂，SQL 就变得即难懂又难写！

其实这个计算按照自然思维很好解，只要按交易日排好序然后得到一些连涨连跌的区间，最后数一下最大连涨区间的天数就行了，很简单。但是 SQL 对有序运算支持不足，未直接提供有序分组，只能采用迂回嵌套的方式，既难懂又难写。而这个计算并不是多难碰到的罕见问题，我们实际业务中比这复杂的情况比比皆是，那些上千行的 SQL 都在解决这类难题。

再来看 SQL 跑不快的问题，还是举例，从 1 亿条数据中取前 10 名。

SELECT TOP 10 * FROM Orders ORDER BY Amount DESC

这条语句并不复杂，但有个 ORDER BY 字样，这意味着要对所有数据进行大排序，然后再取出前 10 个。大数据排序很慢，会涉及多次内外存交互，如果按照表面的意思去执行效率会很低。其实这个计算有更快的方法不需要全排序，始终保留一个 10 个最大成员的集合遍历一次就能算完，但 SQL 却无法描述这样的计算。这时候只能指望数据库的优化器了，对于这种简单取前 10 条的情况，大部分数据库都会在工程上优化，并不会真排序，就可以很快地计算出来。但如果计算变得复杂优化引擎就会犯晕最后只能执行慢算法了。像下面这种求组内前 10 名：

SELECT * FROM (
   SELECT *, ROW_NUMBER() OVER (PARTITION BY Area ORDER BY Amount DESC) rn
   FROM Orders )
WHERE rn<=10

这个 SQL 和前面从全集里取前 10 名的写法有很大差异了，要使用子查询和窗口函数这样“绕”的方式才能实现，这样复杂的情况数据库优化引擎也不会优化了，只能去执行排序，最后变得很慢。实际测试中发现，Oracle 计算组内 TopN 要比全集 TopN 慢 21 倍之多，本来只多个分组性能应该只下降一点点，但结果和我们想象的差距很大，这说明 Oracle 在计算组内 TopN 时大概率做了排序导致性能陡降（虽然我们没有源码无法证实），优化器也不起作用了。

SPL 是怎么做的呢？

计算股票最长连涨天数：

Stock.sort(TradeDate).group@i(Price<Price[-1]).max(~.len())

SPL 提供了有序分组，虽然实现思路与前面的 SQL 一致，但表达起来就很简洁了。

求前 10 名这个：

SPL 将 TopN 视为返回集合的聚合运算，完全避免全排序；全集和分组时写法基本一样，不用绕来绕去。很多时候，写得简单和跑得快其实是一回事，代码写的简单跑得就快，反过来如果写的太复杂也就没法跑快了。

我们可以再做个类比，要计算 1+2+3+…+100。普通人拿到题就开始 1+2=3,3+3=6,6+4=10，…… 这么一直算下去；但高斯通过观察发现 1+100=101,2+99=101，一共有 50 个 101，最后 50*101=5050 就很快算完了。这个故事相信大家都不陌生，我们在小学课本里就读过。大家都会感慨高斯小朋友很聪明，但大家很容易忽略另外一件事情，那就是高斯那个年代已经有了乘法，我们知道乘法是晚于加法发明出来的，如果没有乘法即使高斯再聪明也没办法那么算了。SQL 就像只有加法的算数体系，要解决连加这样的问题就只能一个一个累加，代码冗长计算低效；而 SPL 则相当于发明了乘法，书写简单性能也更高。

SQL 的困难源自关系代数，这种理论上的缺陷无法通过工程优化来弥补；SPL 基于完全不同的“离散数据集”体系，在理论上就提供了更丰富的数据类型和基础运算，因此拥有更强大的表达能力。

那是不是 SPL 只有像高斯这样聪明的程序员才能用起来呢？

并不是，SPL 就是面向一般程序员的，大多数情况只要按自然思维就可以写出正确的代码，而 SQL 在面对复杂问题时反而经常要“绕”，不是有经验的高手还想不出来，从这个意义上，SPL 比 SQL 更简单。不过，用好 SPL 确实需要掌握更多知识，这些知识有些我们已经学过（如大学学习的算法和数据结构），有些虽然原来不会但“高斯”们已经总结好了，而且知识点并不多，我们照着学习就好了。而一旦掌握了这些知识再处理复杂问题就变得十分得心应手了。

现实业务中，还有很多 SQL 搞不定的场景，我们试举几例：

电商行业的用户行为转换漏斗分析，要计算每个事件（页面浏览、搜索、加购物车、下单、付款等）后的用户流失率。这些事件在指定时间窗口内完成、按指定次序发生才有效。用 SQL 描述这种跟次序相关的复杂计算就很繁琐，即使写出来效率也不高，更难优化。

前面案例中的大数据量复杂多步骤跑批任务，有些复杂过程需要借助游标完成，游标读数计算很慢，而且没法并行，浪费计算资源。多步骤计算过程还会伴随中间结果反复落地，效率极低，跑批时间窗口内完不成。

大数据多指标计算，一次完成数百个指标的计算，多次使用明细数据，期间还涉及关联，SQL 需要反复遍历；涉及大表关联、条件过滤、分组汇总、去重计数混合运算，伴随高并发实时计算。SQL 算起来都很吃力。

……

限于篇幅，我们以其中的电商漏斗计算为例来感受一下。

with e1 as (
 select uid,1 as step1,min(etime) as t1
 from event
 where etime>= to_date('2021-01-10') and etime<to_date('2021-01-25')
 and eventtype='eventtype1' and …
 group by 1),
e2 as (
 select uid,1 as step2,min(e1.t1) as t1,min(e2.etime) as t2
 from event as e2
 inner join e1 on e2.uid = e1.uid
 where e2.etime>= to_date('2021-01-10') and e2.etime<to_date('2021-01-25')
 and e2.etime > t1 and e2.etime < t1 + 7
 and eventtype='eventtype2' and …
 group by 1),
e3 as (
 select uid,1 as step3,min(e2.t1) as t1,min(e3.etime) as t3
 from event as e3
 inner join e2 on e3.uid = e2.uid
 where e3.etime>= to_date('2021-01-10') and e3.etime<to_date('2021-01-25')
 and e3.etime > t2 and e3.etime < t1 + 7
 and eventtype='eventtype3' and …
 group by 1)
select
 sum(step1) as step1,
 sum(step2) as step2,
 sum(step3) as step3
from
 e1
 left join e2 on e1.uid = e2.uid
 left join e3 on e2.uid = e3.uid

这是一个三步的漏斗计算。SQL 缺乏有序计算且集合化不够彻底，需要迂回成多个子查询反复 JOIN 的写法，编写理解困难而且运算性能非常低下，更难以优化。这里是三步漏斗，如果增加步骤还要增加子查询，难度可见一斑。

SPL 的写法就要简洁很多了：

SPL 提供有序计算且集合化更彻底，直接按自然思维写出代码，简单且高效。而且这段代码能够处理任意步骤数的漏斗，只要改变参数即可。

这是个实际案例的简化版（原 SQL 有近 200 行），用户使用 Snowflake 的 Medium 级服务器（相当于 4*8=32 核）3 分钟没有跑出来；而 SPL 代码在一个 12 核 1.7G 的低端服务器上仅用不到 20 秒就跑出来了。

我们说 SPL 就像在加法的基础上增加了乘法的计算体系，其实 SPL 中还有很多乘法。这里列出了部分 SPL 算法，其中加星号的都是 SPL 的独创发明。

像遍历复用可以实现一次遍历完成多种运算的效果；外键指针化，将外键字段映射成外键指向的记录地址再使用时会更高效；倍增分段并行，可以适应急剧膨胀的数据规模，存取使用都很高效。

延伸阅读：

结构化大数据高性能计算技术
右侧扫码查看 ⇨

技术特性

前面我们解释了 esProc SPL 写得简单和跑得快的原因，也就是 SPL 的低代码和高性能。

下面我们来具体看一下 esProc SPL 的技术特性。

我们按照架构图上的标号依次来解释一下。

1. 算法引擎

esProc SPL 提供了包括高性能计算在内的 400 多个计算函数，内存计算、外存游标、多线程并行以及集群运算等等，可以满足所有结构化数据处理的需要。

2. 存储引擎

存储是计算的基石，esProc SPL 提供了二进制文件存储，同时支持行存和列存两种方式，并提供了文件索引、倍增分段等机制，在保持使用灵活性和开放性的同时获得更高性能。

3. 多源混算

esProc SPL 的开放体系允许计算来自不同数据源的数据，并可以实施混合计算。这样不仅可以保持数据源多样性的优势（各类数据源有自身的优点），数据的实时性和计算的灵活性也更高。

4. 并行框架

esProc SPL 支持单节点多线程并行计算以及多节点分布式计算，任务拆分和汇总既提供了自动机制，也允许手动进行控制灵活性更强。同时，负载均衡和容错机制（冗余容错和备胎容错）可以保证资源充分发挥效力，系统稳定性更强。

5. 敏捷语法

esProc SPL 采用自创的 SPL 作为形式化语言，在表达计算尤其是复杂计算时相对 SQL 更加简洁。同时 SPL 支持过程计算，这样就可以在丰富计算类库的支持下采用自然思维实现计算逻辑。写的简单就更容易应用高性能算法提升计算性能，同时修改和维护也更方便。

6. 嵌入集成

esProc SPL 可以嵌入应用中作为应用内计算引擎使用，在应用端直接实施计算灵活性大大加强，而且本地运算性能往往也更高。利用 SPL 的敏捷性和高性能特征就可以替代原来硬编码等计算方式，为应用提供强计算能力。

7. 数据固化

esProc SPL 提供了将冷数据固化到文件系统的能力。数据固化过程往往还伴随复杂数据处理，利用 SPL 就可以快速完成这类计算，在固定的时间窗口期内完成更多任务。

8. 实时数据

实时数据源可以直接接入 esProc SPL，不需要做外部映射，直接读取和使用更加高效。在多源混算能力的支持下，接入实时数据就可以轻松实现 T+0 查询，有利于更高效地发挥数据价值。

esProc SPL 提供了简洁易用的开发环境。

在 IDE 中可以分步编写代码，每步的运行结果在右侧的结果面板中都能实时查看，调试执行、单步执行、设置断点等编辑调试功能一应俱全。好用的编辑调试功能同样是低代码不可或缺的特性，这与 SQL（及存储过程）编辑调试困难有很大不同，可以显著降低开发成本。有了这些功能，esProc SPL 也经常用于桌面分析，非常方便。

SPL 是专门设计的语法体系，天然支持分步尤其适合复杂过程计算。支持循环、分支、过程、子程序等完整的编程能力，相对 SQL 更加完善。在每步运算中可以使用单元格名引用上一步计算结果，无需定义变量（当然也支持变量）。

同时 SPL 提供了非常丰富的结构化数据计算类库，针对字符串和日期时间的处理、数学计算、对文件和数据库的读写操作、对 JSON/XML 多层数据的支持、分组 / 循环 / 排序 / 过滤 / 关联 / 集合运算 / 有序计算一应俱全，特别针对序列（序表）提供的循环函数可以极大简化集合运算，还有针对大数据计算提供的游标，为了减少硬盘重复遍历的管道，以及并行和分布式计算的支持。此外，还提供针对 AI 的建模和预测函数，对包括 MongoDB、Elasticsearch、HBase、HDFS、Influxdb 等几十种数据源在内的外部库函数等等。

目前 SPL 提供了 400 多个函数，叠加每个函数包含数个选项相当于几千个库函数，再结合过程、循环、分支等完善的程序语言功能可以完成全面的数据处理任务，这是全功能特点的典型表现。

esProc SPL 还具备极强的集成性，esProc SPL 采用 Java 开发，不仅可以独立使用，也可以无缝集成到应用中，作为应用内计算引擎使用，可以在微服务、边缘计算、报表数据准备等场景中发挥重要作用。

良好的集成性体现了轻量级特性，esProc SPL 并不总需要独立服务器才能工作（与数据库有很大不同），将 jar 包集成嵌入就能为应用提供强大的计算能力，而且 jar 包才几十 M，非常小巧轻量，随时随地都可以用，甚至安卓手机上都能工作。

esProc SPL 支持几十种数据源，具备多数据源混合计算能力，多数据源数据无需导入数据库就可以直接计算，除了数据实时性更好，还可以充分保留多样数据源自身的优势。比如 RDB 计算能力强但 IO 效率低，就可以让 RDB 先承担一部分计算再由 SPL 接管；MongoDB 天然适合存储动态多层的数据，SPL 就可以直接基于多层数据进行计算；文件系统不仅读写效率更高，数据文件使用上也更加灵活，SPL 可以直接使用文件计算，还可以充分发挥并行计算的效力。

esProc SPL 对多数据源的支持再一次体现了全功能，同时 esProc SPL 由于没有元数据，多数据源可以直接访问并进行混合计算因此更轻，这是 esProc SPL轻量级的另一面。

更进一步，esProc SPL 还提供了自有的高效数据文件存储，私有数据格式性能更高，还可以按照文件系统树状目录方式按业务分类存储数据。

目前 esProc SPL 提供了两种文件格式，集文件和组表。

集文件是一种基础二进制数据格式，采用了压缩技术（占用空间更小读取更快），存储了数据类型（无需解析数据类型读取更快），还支持可追加数据的倍增分段机制，利用分段策略很容易实现并行计算提升计算性能。

组表提供了更复杂的存储结构，支持行列混合存储，有序存储可以进一步提高压缩率和定位性能，支持更高效的智能索引，支持主子表合一有效减少存储与关联，同时支持倍增分段机制更容易并行提升计算性能。

基于文件存储无需数据库参与，没有元数据，使用上更加灵活高效，也更轻量级。同时成本也更低，更适合大数据时代的需要。

以上我们介绍了 esProc SPL 的一些技术特性，下面我们来看一些 esProc SPL 在更多场景下的应用功能方案。

更多方案

 方案  数据型微服务实现

微服务要求数据处理的工作也要在应用端完成，这就需要相应的数据处理技术。数据库虽然有较强的计算能力，但很难嵌入到应用端使用，因此经常需要硬编码。而 Java 及 ORM 技术缺乏结构化计算类库导致数据处理开发困难，无法热切换，很难适应微服务的需要。

使用 SPL 替代 Java/ORM 在微服务内实施数据计算可以有效解决这些问题。SPL 具备丰富计算类库与敏捷语法可以大幅简化开发，体系开放可以实时处理任意数据源数据，解释执行天然支持热切换，借助高效算法与并行机制可以充分保证计算性能，是微服务内的理想计算引擎。

延伸阅读：

开源 SPL，ORM 的终结者？

开源 SPL 令微服务真地”微“起来

 方案  替代存储过程

存储过程的诟病由来已久，存储过程编辑调试困难，缺乏移植性；对权限要求过高，安全性差；存储过程被多个应用共用还会造成应用间紧耦合。但经常由于没有更好的解决方案（毕竟硬编码成本太高），不得不忍受存储过程的这些缺点。

SPL 专门为复杂结构化数据计算设计，可以很好替代存储过程，实现库外存储过程的效果。SPL 支持多步计算天然适合完成存储过程类的复杂计算，计算脚本天然可移植；脚本只要求数据库的读权限，不会造成数据库安全问题；不同应用的脚本分别存储于不同目录，不会造成应用间耦合。

延伸阅读：爱恨交加的存储过程该往何处去

 方案  消灭数据库中间表

使用数据库时经常为了查询效率或简化开发在数据库中生成大量中间汇总表，久而久之中间表数量越来越多，这些中间表不仅大量占用数据库空间，导致数据库过于冗余臃肿，不同应用使用同一个中间表还会造成紧耦合，大量中间表难于管理。

中间表存储在数据库中是为了利用数据库进行后续计算，可以将中间表外置到数据库外使用文件存储，然后基于 SPL 实施后续计算。外置中间表（文件）更易于管理，采用不同目录存储不会引起应用耦合性问题；中间表外置可以为数据库充分减负，甚至不需要部署数据库。

延伸阅读：开源 SPL 消灭数以万计的数据库中间表

 方案  应对报表没完没了

报表 /BI 开发要经过数据准备和数据呈现两个过程，报表 /BI 工具只能解决呈现环节的问题，但对数据准备无能为力。复杂的数据准备过程只能使用 SQL/ 存储过程 /Java 硬编码，开发维护困难，成本高。我们经常会面临报表需求没完没了的问题，往往很难低成本地快速响应，数据准备主要因素。

借助 SPL 在报表呈现和数据源之间增加计算层来解决数据准备问题，SPL 可以简化报表数据准备，弥补报表工具计算能力不足，全面提升报表开发效率。将报表数据准备环节也工具化以后，报表呈现和数据准备两个环节都能快速响应以低成本应对没完没了的报表需求。

延伸阅读：开源 SPL 优化报表应用应对没完没了

 方案  可编程路由实现前置计算

中央数据仓库承担过多业务会导致压力过大，需要将部分计算任务前置到应用端可以有效缓解压力，由前置计算服务提供专用高频的计算工作。但前置计算的技术选择很少，使用数据库实施前置计算会面临数据同步问题，即如果仅将高频数据导入前置库势必无法满足所有查询需要，但如果将全量数据都同步又面临重复建设工程量巨大等问题。

使用 SPL 可以很好解决这个问题，将高频数据转化成 SPL 文件存储，再借助 SPL 的高性能计算为应用提供高效计算服务。同时 SPL 还提供了智能路由功能，如果应用查询低频数据，SPL 可以将查询请求自动路由到数据仓库得以满足。这样既避免了重复建设的高昂成本，又充分发挥灵活高效的计算能力，实施成本低效果更佳。

延伸阅读：可路由计算引擎实现前置数据库

 方案  混合计算实现实时 HTAP

HTAP 需求本质上是由于数据量大分库后无法进行 T+0 查询产生的。现在 HTAP 数据库在实现 T+0 需求时会面临几个问题。由于原来生产库并不是 HTAP 库，这就涉及更换生产库，会面临巨大的风险；SQL 算力不足，历史数据无法充分整理以达到高性能的要求；数据库的计算能力过于封闭无法利用多样性数据源的优势，复杂 ETL 同库过程还会导致实时性差。

SPL 支持多样性数据源混合计算，天然可以进行 T+0 分析。将历史冷数据根据计算特点精心整理后使用文件存储计算性能更高，交易热数据仍然存在生产库（副本库）中实时读取。这样原来的生产系统无需改造就可以实现高效的 HTAP 效果，风险和成本最低。SPL 用开放的多源混算能力支撑低风险高性能强实时 HTAP。

延伸阅读：HTAP 数据库搞不定 HTAP 需求

 方案  文件计算实现湖仓一体

湖仓一体要求能存能算，既能充分保留原始数据又具备强计算能力可以充分发挥数据价值。但使用数据库实现湖仓一体会面临只能算不能存（只能 House 不能 Lake）的处境。数据库具备强约束性，不合规的数据无法入库导致数据无法原汁原味，同时复杂的 ETL 过程十分低效；数据库具备极强的封闭性，只能计算库内数据又导致无法使用原始多样数据源直接计算，更无法实现混合实时计算。

使用 SPL 可以实现真正的湖仓一体。原始数据可以直接存储在文件系统中，保持原汁原味。

SPL 具备更强的开放性，无论何种类型、是否整理过的数据都可以直接计算，公开的 txt、csv、json 等文件直接使用，其他类型的数据源也可以实时对接混算。在基于原始数据直接计算的同时，数据整理工作可以同步进行，边计算边整理，从而具备更高效的数据利用效率和再计算时的高性能。循序渐进才是解锁湖仓一体的正确姿势。

延伸阅读：现在的湖仓一体像是个伪命题

FAQ

 问题  esProc 基于开源或数据库技术吗?

前面我们详细分析过现有技术（主要是 SQL）的缺点根本原因在于其背后的理论体系，如果继续基于这些理论就无法从根本上解决问题。因此，我们发明了一套全新的模型—离散数据集，基于这个模型开发出 esProc SPL。由于这是一系列全新的内容，市面上并无相关理论及工程产品可以借鉴，因此只能从头自己开发，从模型到代码全部自主原创。

 问题  esProc 可以部署在哪里？

esProc 完全采用纯 Java 开发，因此可以部署在任何有 JVM 的环境中运行，包括但不限于虚拟机、云服务器以及容器。具体使用时，esProc 可以独立使用，也可以与应用集成。前者要运行单独的 esProc 服务，可以搭建分布式集群，后者则以 jar 包的方式完全嵌入到应用中作为应用的一部分（计算引擎）使用。

 问题  应用程序如何调用 esProc?

esProc 提供了标准 JDBC 接口，Java 应用可以直接无缝集成调用。对于.net/Python 等非 Java 应用则可以通过 ODBC/HTTP/RESTful 接口调用。

 问题  esProc 能基于现有数据库工作吗?

esProc 提供了多种数据源支持，数据库、文本、excel、json/xml、webservice 等几十种数据源，数据库当然也不例外。esProc 可以完成数据库与其他数据源（如文本）的关联混合运算。

不过，对于数据密集型任务（大数据时代的大部分场景）由于数据库 I/O 性能不佳，数据从数据库读出会消耗大量时间，即使最后 esProc 计算的时间很短总体时间仍然很长，达不到性能要求。因此对于高性能场景，需要将数据（大量冷数据）从数据库中转存到 esProc 高性能文件存储中才能获得最优性能。同时，少量热数据仍然可以存储在数据库中，借助 esProc 的多源混算能力可以轻松实现 T+0 全量数据查询。

 问题  esProc 把数据存在哪里?

esProc 采用文件存储数据，可以支持开放的文本格式，也提供了高性能的私有文件格式。文件具备更强的开放性和灵活性等特性，基于文件更容易设计高性能存储方式以及通过并行来提升运算性能。任何操作系统下的文件系统都能支持，包括本地文件系统、网络文件系统都可以使用。这样 esProc 可以天然支持存算分离，而不像数据库那样绕过文件系统直接操作硬盘导致存算分离困难。

 问题  esProc 有什么不足吗?

和 RDB 相比

esProc 的元数据能力相对不成熟。
esProc 不是 DBMS，没有传统意义上的元数据概念，数据多以文件的形式存储、管理和使用，大部分运算都要从访问数据源（文件）开始，对简单运算会比数据库麻烦一点，而复杂计算则更有优势。

和 Hadoop/MPP 相比

Hadoop/MPP 数据库集群规模相对较大（虽然 MPP 通常有数量限制），这些技术有成熟的集群使用和运维管理经验，而 esProc 的集群定位是中小规模，通常几台到几十台，即使这样 esProc 集群仍然缺少实际使用经验（相对 Hadoop/MPP 来说），在客户实际应用中经常单机就能达到甚至超越原来集群的效果，集群往往用不上，这更导致 esProc 集群的应用经验相对缺乏。

和 Python 相比

esProc SPL 目前正在发展人工智能功能，AI 建模预测等功能在逐渐完善，但与 Python 丰富的人工智能算法库相比还相差较远。

 问题  SPL 有多难学？

SPL 专门用于低代码和高性能。SPL 语法很容易，比 Java 简单多了，数小时即可掌握，数周就能熟练。难的是设计优化算法，好在这些能力都是可以学会的，我们已经把这些知识点总结成一系列“套路”，跟着学习就能掌握这些能力成为高手。

【程序设计】 前言及目录

右侧扫码查看 ⇨

【性能优化】 前言及目录
右侧扫码查看 ⇨

SPL 比 SQL 更难了还是更容易？

 问题  可否把 SQL 自动转换成 SPL

鉴于 SQL 使用的广泛性，尤其针对存量系统的改造（优化）时大家很自然的想法是能否把 SQL 自动转换成 SPL 以降低迁移成本。

很遗憾，不可以。

首先数据库虽然可以作为 SPL 的数据源，但基于数据库（主要是存储）无法获得高性能，因此基于数据库无法做到二者的自动转换。更重要的是，SQL 的描述能力不足，很多高性能算法无法实施，强行将 SQL 转换成 SPL 后，只能保证功能，性能通常会差很多。

这里还要提到一点，SPL 没有提供像 SQL 那么强的自动优化机制，SQL 经过几十年的积累发展，很多数据库都拥有很强的优化引擎，碰到相对简单的慢 SQL 语句，能“猜”出其真实意图，再自动优化采用高性能方式执行（如前面讲到的 TopN）；相比之下，SPL 没有做多少自动优化的功能，SPL 团队也远远没有数据库厂商那么丰富的优化经验，我们不会“猜”语句的意图，只会照代码去执行。这时，要跑出高性能，几乎全靠程序员写出低复杂度的代码。

 问题  如何启动性能优化项目？

大多数程序员习惯了 SQL 思维方式，不熟悉高性能算法，需要用一两个场景训练和理解。性能优化套路并不是很多，几十招中常用的不超过十招，经历过也就学会了，算法设计和实现并不是那么难。最初的 2-3 个场景，需要由我方工程师介入配合用户实现，用户在这个过程中训练了思路、掌握了方法就能达到授人以渔的效果。

延伸阅读：SQL(及存储过程)跑得太慢怎么办

总结

最后我们来总结一下 esProc SPL 用作数据分析引擎优势。

性能卓越
在实际应用中，esProc SPL 的大数据处理性能可以比传统方案平均提升 1-2 个数量级，性能优势十分明显。

高效开发
借助 SPL 敏捷语法以及丰富的计算类库，在过程化的加持下采用自然思维就可以实现复杂算法，开发效率更高。

灵活开放
esProc SPL 支持多数据源混合计算，有效利用多源优势的同时还能以最小代价实现 HTAP。而且 esProc SPL 还可以集成嵌入到应用中使用，做到真正的开放、灵活。

节约资源
在高算力的支持下，esProc SPL 使用更少硬件（单机顶集群）就能实现业务目标，因此更加环保，绿色低碳。

成本锐减
esProc SPL 这些优势都反映到成本上就能达到开发、硬件、运维成本降低 X 倍的效果。

GitHub：https://github.com/SPLWare/esProc

重磅！开源SPL交流群成立了

简单好用的SPL开源啦！
 开源地址：https://github.com/SPLWare/esProc

为了给感兴趣的技术人员提供一个相互交流的平台，

特地开通了交流群（群完全免费，不广告不卖课）

需要进群的朋友，可长按扫描下方二维码

本文感兴趣的朋友，请到阅读原文去收藏 ^_^