目前网上有很多涉及 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 相对 Java 也有很大优势。Java 是一个功能全面的开发语言，理论上任何数据计算任务都能写出来。但由于过于原生，缺少必要的计算类库，所有计算任务都需要从头开发导致实现困难。
尤其对于高性能算法实现更加困难，好不容易写出来最后性能却很差。不仅开发成本高，性能过低同时也拉高硬件成本。
Java 在工程上还有一些缺点，比如作为编译型语言很难热切换、不同应用 / 模块要随主应用一同部署导致紧耦合，这些缺点对于经常发生变化的数据分析类场景伤害很大。所以，现实业务中经常是 Java 和 SQL 混用，毕竟很多计算用 SQL 更简单方便，这就又导致 SQL 的问题没解决又增加了 Java，不仅技术栈复杂，使用有难度，运维成本也很高。
相对来讲，SPL 没有这些问题，类库丰富实现简单、提供诸多低复杂度算法保证性能，而作为解释型语言 SPL 天然支持热切换，更不会出现耦合性问题。比起 SQL，SPL 相对 Java 的优势更大。
Python 在结构化数据处理上也存在一些问题。Python（Pandas）本身提供了很丰富的计算类库，很多简单计算写起来很方便，基本与 SQL 相当。但用 Python 做一些稍复杂的计算就有难度了，开发成本仍然不低。
Python 的大数据能力很弱。没有提供针对外存的游标类型，在计算超出容量的数据不仅繁琐且性能低下导致硬件成本提升。
Python 还有版本混乱的问题，高低版本并不兼容会导致使用、运维成本高，同时 Python 集成性很差，很难跟应用结合使用，经常还要部署单独的服务，又会增加运维成本。与 Java 一样，实际业务中 Python 也常常和 SQL 配合使用，又会出现既没解决又添新问题的情况。
SPL 在开发和性能上的优势前面已经介绍了很多，SPL 也不存在版本混乱的问题，同时良好的集成性可以跟应用无缝结合，功能全面技术栈也更简单不需要借助其他技术运维成本也更低。
总的来讲，SPL 相对 SQL、Java、Python 都可以达到在开发、硬件、运维三方面成本降低数倍的效果。
案例简析
我们来看看 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 名这个：
A
1 =file(“data.ctx”).create().cursor()
2 =A1.groups(;top(-10,amount)) 金额在前 10 名的订单
3 =A1.groups(area;top(-10,amount)) 每个地区金额在前 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-10') 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 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 的写法就要简洁很多了：
A
1 =["etype1","etype2","etype3"]
2 =file("event.ctx").open()
3 =A2.cursor(id,etime,etype;etime>=date("2021-01-10") && etimet && etime<t1+7).etime, null))))
7 =A6.groups(;count(~(1)):STEP1,count(~(2)):STEP2,count(~(3)):STEP3)
SPL 提供有序计算且集合化更彻底，直接按自然思维写出代码，简单且高效。而且这段代码能够处理任意步骤数的漏斗，只要改变参数即可。
这是个实际案例的简化版（原 SQL 有近 200 行），用户使用 Snowflake 的 Medium 级服务器（相当于 4*8=32 核）3 分钟没有跑出来；而 SPL 代码在一个 12 核 1.7G 的低端服务器上仅用不到 20 秒就跑出来了。
我们说 SPL 就像在加法的基础上增加了乘法的计算体系，其实 SPL 中还有很多乘法。这里列出了部分 SPL 算法，其中加星号的都是 SPL 的独创发明。
像遍历复用可以实现一次遍历完成多种运算的效果；外键指针化，将外键字段映射成外键指向的记录地址再使用时会更高效；倍增分段并行，可以适应急剧膨胀的数据规模，存取使用都很高效。
延伸阅读： 结构化大数据高性能计算技术
那么 Java 为什么也不行？
前面我们已经说过，Java 由于过于原生缺少必要数据类型和计算类库导致计算都要从头实现很繁琐。像分组汇总用 Java 实现就需要十几行代码，虽然 Java8 提供的 Stream 一定程度地简化了这类运算，但复杂一点的计算仍然十分困难（相对 SQL 都有很大差距）。
对于性能要求高的计算，Java 写起来就更难。像不用大排序的 TopN 运算、性能更好的 HASH 连接，以及利用有序进行有序归并等。这些算法本身实现就很有难度，加之 Java 的类库缺乏导致很多应用程序员并不会，经常不得不采用相对简单的慢算法，最后连 SQL 都跑不过，还怎么解决这些问题。
大数据的运算性能很大程度上还和数据 IO 相关，如果数据的 IO 成本太高，运算再快也没用。高效的 IO 经常依赖于专门优化的存储方案，但遗憾的是，Java 没有应用较广泛的高效存储方案，一般会使用文本文件或数据库存储数据，数据库的接口效率性能很差，文本虽然好一点，但又会在数据类型解析上消耗过多时间导致性能仍然不高。
如果再加上工程上的难以热切换、紧耦合等缺点，Java 与 SQL 相比尚且不足，更别说超过 SQL 去解决前面的那些问题了。
Python 为什么还不行？
通过 Java 的比较我们基本能感受到 Python 的缺点很多是类似的。比如相对复杂一点的计算实现困难，像相邻引用、有序分组、定位计算、非等值分组等做起来都没那么简单。
对于大数据计算又没提供相应的外存计算机制，导致大数据能力差。而且，Python 不支持真正的并行计算，Python 的并行是伪并行，对于 CPU 来说就是串行，甚至比串行还慢，难以充分利用现代 CPU 多核的优势。在 Cpython 解释器 (Python 语言的主流解释器) 中，有一个全局解释锁（Global Interpreter Lock），执行 Python 代码时，先要得到这个锁，意味着即使是多核 CPU 在同一时段也只可能有一个线程在执行代码，多线程只能交替执行。而多线程涉及到上下文切换、锁机制处理等复杂事务，结果不快反慢。
Python 无法在进程内使用简单的多线程并行机制，很多程序员只能采用复杂的多进程并行，进程本身的开销和管理复杂得多，并行程度无法和多线程相提并论，加上进程间的通信也很复杂，有时只好不直接通信，用文件系统来传递汇总结果，这又导致性能大幅下降。
与 Java 一样，Python 也没提供高效的存储方案用于高性能计算。只能借助开放文件或数据库，性能很低。很多时候，Python 也会和 SQL 结合使用，一样解决不了 SQL 面临的那些问题。再加上 Python 的版本问题、集成性问题等原因，Python 真的也不行。
技术特性
前面我们解释了 esProc SPL 写得简单和跑得快的原因，也就是 SPL 的低代码和高性能。
下面我们来具体看一下 esProc SPL 的技术特性。
esProc 目前是纯 Java 软件，只要有 JDK1.8 及以上版本的 JVM 环境的任何操作系统都可以运行，包括常见的 VM 和 Container。
esProc 正常安装后占用空间不到 1G，但绝大多数都是引用的第三方外部数据源驱动包。其核心包不足 15M，甚至可以在 Android 上运行。
除 JVM 外，esProc 对运行环境没有其它硬性要求。对硬盘和内存的容量要求和计算任务相关，不同计算任务相差很大。执行同样计算任务时，esProc 需要的硬件资源通常小于传统数据库（特别是针对分布式数据库时会远小于）。加大内存、选用更高主频和核数的 CPU 以及使用 SSD 通常对提升计算性能都有提升作用。
架构最左面是业务数据库和传统数据仓库（如已建设），事实上数据源的种类可以很多，这些数据可以通过“数据固化”将数据转换到 esProc 的高性能文件存储中，转换以后可以获得更高的计算性能。
当然，数据转换不是必须的。对于一些数据实时性要求较高的场景 esProc 可以基于数据源提供的接口（如 JDBC）实时读取进行计算。不过，由于数据接口性能 esProc 无法干预，可能会存在不同数据源的性能不同，也会有比较慢的情况。如果用户同时对数据实时性和性能有要求，那么可以采用冷数据固化、热数据实时读取的方式，将不变的历史冷数据转换到 esProc 高性能存储中，热数据从数据源中读取，再借助 esProc 的混合计算能力进行全量数据处理同时以同时兼顾这两方面的需求。
esProc 高性能文件存储下面还会详细介绍。
架构的中间部分是 esProc Server，用于承担真正的数据处理工作。可以进行多机分布式部署进行集群运算，支持集群负载均衡和容错机制。esProc 设计的集群规模相对较小（不超过 32 节点），将更多的资源用于计算（而非管理和调度）。不过，在已实施的诸多案例中，esProc 绝大部分情况采用单机就可以完成传统技术（MPP/HADOOP）的集群运算场景而且性能更高，所以不用担心不够用的问题。
每个集群节点分步 esProc 的 SPL 计算脚本，脚本可以通过 esProc 的 IDE 进行远程开发调试，调试时数据不会被本地保存或下载，更加安全。
esProc 封装了标准的 JDBC/RESTful 等接口供应用程序调用。对于 Java 应用可以直接集成 esProc 作为其应用内计算引擎。非 Java 应用可以通过其他接口调用。
从整个架构来看，esProc 除了提供简单、高效的数据处理能力，在应用形式上也更加灵活，既可以独立使用也可以集成，同时相对轻量的计算方式使用上也很轻便，不似传统分布式技术那样沉重。
在开发调试方面，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 可以处理的数据类型包括：
- 结构化文本：txt/csv
- 普通文本，字串分析
- Excel 文件内数据
- 多层结构化文本：json， xml
- 结构化数据：关系数据库
- 多层结构化数据：bson
- KV 型数据：NoSQL
特别地，esProc 对 json,xml 等多层结构化数据有强大的支持能力，远远超过传统数据库。所以 esProc 可以很好地和 mongodb 以及 kafka 等类 json 数据源配合，也能方便地和 HTTP/Restful 以及微服务交换数据并提供计算服务。
esProc 还能方便地计算 Excel 文件中的数据，但不擅长处理 Excel 的格式。esProc 也不擅长处理图像音频和视频等数据。
更进一步，esProc SPL 还提供了自有的高效数据文件存储，私有数据格式性能更高，还可以按照文件系统树状目录方式按业务分类存储数据。
目前 esProc SPL 提供了两种文件格式，集文件和组表。
集文件是一种基础二进制数据格式，采用了压缩技术（占用空间更小读取更快），存储了数据类型（无需解析数据类型读取更快），还支持可追加数据的倍增分段机制，利用分段策略很容易实现并行计算提升计算性能。
组表提供了更复杂的存储结构，支持行列混合存储，有序存储可以进一步提高压缩率和定位性能，支持更高效的智能索引，支持主子表合一有效减少存储与关联，同时支持倍增分段机制更容易并行提升计算性能。
基于文件存储无需数据库参与，没有元数据，使用上更加灵活高效，也更轻量级。同时成本也更低，更适合大数据时代的需要。
esProc 没有传统数据仓库中“库“的概念，没有元数据概念，不对某个主题的数据进行统一管理。对 esProc 来讲，数据没有“库内”和“库外”的区分，也没有明确的“入库”和“出库”的动作。
任何可访问到的数据源都可以看作 esProc 的数据，并可被直接计算。计算前不需要先“入库”，计算后也可以用接口写出目标数据源中，不需要刻意“出库”。
esProc 对常见的数据源都封装了访问接口，各种数据源在逻辑上地位基本相同，不同之处仅仅在于访问接口以及不同接口表现出来的性能，这些接口是数据源厂商提供的，esProc 无法干预其功能和性能。
esProc 设计了特殊格式的文件（集文件和组表）来存储数据以获得更多的功能和更好的性能，这些数据文件存放在文件系统中，esProc 在技术上并不占有这些数据文件。esProc 已经将文件格式公开（访问代码开源），可以被任何能访问到这些数据文件的应用程序按照公开规范（或基于开源代码）读写，当然更方便的是直接使用 SPL 语写。
从这样意义上讲，esProc 与外部的数据交换没有“入库”“出库”的动作，但可能会有“转换”的动作，即把外部数据转转换成 esProc 格式的文件以获得更多功能和更好性能，也可以把 esProc 格式的文件转换成外部数据供其它应用继续使用。这些转换工作都可以使用 SPL 完成。
esProc 原则上并不管理数据，也不对数据的安全负责。一定程度上可以说，esProc 没有也没必要有安全机制。
持久化数据的安全性原则上数据源本身负责。对于 esProc 格式的数据文件，很多文件系统或 VM 都提供了完善的安全机制（访问控制、加密等），可以直接利用。esProc 的云版本也支持从 S3 等对象存储服务上获取数据再计算，也可以利用它们的安全机制。
嵌入式的 esProc 和主 Java 应用是同一个进程，仅向主程序提供计算服务，没有外部服务接口，不存在安全和权限问题。独立服务进程的 esProc 使用标准的 TCP/IP 和 HTTP 通信，可以被专业的网络安全产品监控和管理，具体安全措施将由这些产品负责。
esProc 专注于计算，对持久化存储的可靠性也不负责，这些方面同样的专业的技术和产品，esProc 尽量使用标准的规范，从而可以和这些技术和产品配合工作。比如可以将数据持久化到高可靠的对象存储上，esProc 实现了这些存储方案的接口，可以访问这些数据源实施计算。
esProc 是专业的计算技术，不拥有专业的安全能力，esProc 的理念是和其它专业技术配合。
以上我们介绍了 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 可以像传统数据库一样运行成独立服务进程，对外提供了标准的 JDBC 驱动和 HTTP 服务供应用程序调用。Java 应用程序可以通过 JDBC 发出 SPL 语句就可以执行，调用 esProc 上的脚本代码相当于调用关系数据库中的存储过程。非 Java 应用程序可以使用 HTTP/Restful 机制访问 esProc 提供的计算服务。
对于 Java 开发的应用程序，esProc 还提供了完全嵌入的方式，即在 JDBC 驱动中封装了所有计算功能，和主应用程序在同一进程内运行，不依赖于外部的独立服务进程。
因为 esProc 是纯 Java 软件，也可以嵌入式运行，所以可以完全无缝地集成进各种 Java 框架和应用服务器中，比如 Spring,Tomcat,…，可以被这些框架调度和运维，对于这些框架而言，esProc 的逻辑地位和用户写的 Java 应用程序完全相同。
需要指出的是，对于计算型框架（比如 Spark），虽然 esProc 能被无缝集成，但并没有实际意义。esProc 要求把数据转换成 SPL 特有的数据对象才能实施计算，不仅转换消耗时间，而且原计算框架中的数据对象都将失去意义，两类数据对象的优点不能融合。这些计算框架的关键点主要就是其数据对象（比如 Spark 的 RDD），如果不能继续使用，则计算框架本身也将失去意义。esProc 的计算能力远远超过常见的计算框架，也没有必要再使用这些框架。
特别地，对于流计算框架（比如 Flink），esProc 即使能集成也不能发挥作用。esProc 独立服务过多次流式计算案式，完全不需要流计算框架的支持，完成同样计算量消耗的资源通常会比这些流计算框架低一个数量级，而且功能更丰富。
esProc 能基于现有数据库工作吗?
esProc 提供了多种数据源支持，数据库、文本、excel、json/xml、webservice 等几十种数据源，数据库当然也不例外。esProc 可以完成数据库与其他数据源（如文本）的关联混合运算。
不过，对于数据密集型任务（大数据时代的大部分场景）由于数据库 I/O 性能不佳，数据从数据库读出会消耗大量时间，即使最后 esProc 计算的时间很短总体时间仍然很长，达不到性能要求。因此对于高性能场景，需要将数据（大量冷数据）从数据库中转存到 esProc 高性能文件存储中才能获得最优性能。同时，少量热数据仍然可以存储在数据库中，借助 esProc 的多源混算能力可以轻松实现 T+0 全量数据查询。
esProc 把数据存在哪里?
esProc 采用文件存储数据，可以支持开放的文本格式，也提供了高性能的私有文件格式。文件具备更强的开放性和灵活性等特性，基于文件更容易设计高性能存储方式以及通过并行来提升运算性能。任何操作系统下的文件系统都能支持，包括本地文件系统、网络文件系统都可以使用。这样 esProc 可以天然支持存算分离，而不像数据库那样绕过文件系统直接操作硬盘导致存算分离困难。
esProc 高可用如何保障？
esProc 支持分布式计算，可以多节点配合工作，但实际应用中很少用到，因为除高并发场景外，绝大多数任务的数据量和响应期望，esProc 都可以用单机实现。
esProc 即将发布的云版本（可支持私有化部署）将支持自动的弹性计算，请求量变大时会自动启用新的 VM 实施计算，请求量变小时将自动关闭闲置的 VM。
嵌入式的 esProc 仅上主应用程序提供计算服务，不能对外提供服务，也不能负责对外服务的可靠性，这由主应用程序以及框架来负责。
独立进程的 esProc 支持热备机制，JDBC 会在当前仍可工作的服务进程中选择负担较轻的来实施计算。esProc 的分布式计算也提供了容错能力，但 esProc 设计目标不是大规模集群，计算任务过程中发现节点故障后，该任务将被宣布失败。esProc 容错程度仅到发现节点故障时还允许集群能接受新任务，仅适合小规模集群。
esProc 的服务进程目前也没有提供故障后自动恢复的功能，需要管理人员来处理，不过做个监控进程来实现这个自动功能也并不难。
esProc 云版本的弹性计算机制在分配 VM 时会避开当前失效的节点，一定程度地实现高可用性。
esProc 如何进行功能扩展？
esProc 是 Java 写的软件，提供了接口调用 Java 写的静态函数，这样可以扩充 esProc 的功能。esProc 也开放了自定义函数的接口，应用程序员可以用 Java 编写新的函数挂载到 esProc 中，使用就可以在 SPL 中使用。
esProc 有什么不足吗?
和 RDB 相比
esProc 的元数据能力相对不成熟。
esProc 不是 DBMS，没有传统意义上的元数据概念，数据多以文件的形式存储、管理和使用，大部分运算都要从访问数据源（文件）开始，对简单运算会比数据库麻烦一点，而复杂计算则更有优势。
和 Hadoop/MPP 相比
Hadoop/MPP 数据库集群规模相对较大（虽然 MPP 通常有数量限制），这些技术有成熟的集群使用和运维管理经验，而 esProc 的集群定位是中小规模，通常几台到几十台，即使这样 esProc 集群仍然缺少实际使用经验（相对 Hadoop/MPP 来说），在客户实际应用中经常单机就能达到甚至超越原来集群的效果，集群往往用不上，这更导致 esProc 集群的应用经验相对缺乏。
和 Python 相比
esProc SPL 目前正在发展人工智能功能，AI 建模预测等功能在逐渐完善，但与 Python 丰富的人工智能算法库相比还相差较远。
SPL 与 SQL 兼容性如何？
esProc 不是 SQL 体系的计算引擎，目前仅支持不涉及大数据量的简单 SQL，且不保证性能。在大数据需求场景下，可以认为 esProc 不支持 SQL，当然也不会和任何 SQL 存储过程兼容。
esProc 未来会发展出支持 SQL 的双引擎，但仍然很难保证高性能和大数据，仅仅是让存量的 SQL 代码易于迁移到 esProc。
有没有将 SQL 自动转成 SPL 的工具?
鉴于 SQL 使用的广泛性，尤其针对存量系统的改造（优化）时大家很自然的想法是能否把 SQL 自动转换成 SPL 以降低迁移成本。
很遗憾，不可以。
首先数据库虽然可以作为 SPL 的数据源，但基于数据库（主要是存储）无法获得高性能，因此基于数据库无法做到二者的自动转换。更重要的是，SQL 的描述能力不足，很多高性能算法无法实施，强行将 SQL 转换成 SPL 后，只能保证功能，性能通常会差很多。
这里还要提到一点，SPL 没有提供像 SQL 那么强的自动优化机制，SQL 经过几十年的积累发展，很多数据库都拥有很强的优化引擎，碰到相对简单的慢 SQL 语句，能“猜”出其真实意图，再自动优化采用高性能方式执行（如前面讲到的 TopN）；相比之下，SPL 没有做多少自动优化的功能，SPL 团队也远远没有数据库厂商那么丰富的优化经验，我们不会“猜”语句的意图，只会照代码去执行。这时，要跑出高性能，几乎全靠程序员写出低复杂度的代码。
SPL 有多难学？
SPL 专门用于低代码和高性能。SPL 语法很容易，比 Java 简单多了，数小时即可掌握，数周就能熟练。难的是设计优化算法，好在这些能力都是可以学会的，我们已经把这些知识点总结成一系列“套路”，跟着学习就能掌握这些能力成为高手。
【程序设计】 前言及目录
【性能优化】 前言及目录
SPL 比 SQL 更难了还是更容易？
如何启动性能优化项目？
大多数程序员习惯了 SQL 思维方式，不熟悉高性能算法，需要用一两个场景训练和理解。性能优化套路并不是很多，几十招中常用的不超过十招，经历过也就学会了，算法设计和实现并不是那么难。最初的 2-3 个场景，需要由我方工程师介入配合用户实现，用户在这个过程中训练了思路、掌握了方法就能达到授人以渔的效果。
延伸阅读： SQL(及存储过程)跑得太慢怎么办
总结
最后我们来总结一下 esProc SPL 用作数据分析引擎优势。
性能卓越
在实际应用中，esProc SPL 的大数据处理性能可以比传统方案平均提升 1-2 个数量级，性能优势十分明显。
高效开发
借助 SPL 敏捷语法以及丰富的计算类库，在过程化的加持下采用自然思维就可以实现复杂算法，开发效率更高。
灵活开放
esProc SPL 支持多数据源混合计算，有效利用多源优势的同时还能以最小代价实现 HTAP。而且 esProc SPL 还可以集成嵌入到应用中使用，做到真正的开放、灵活。
节约资源
在高算力的支持下，esProc SPL 使用更少硬件（单机顶集群）就能实现业务目标，因此更加环保，绿色低碳。
成本锐减
esProc SPL 这些优势都反映到成本上就能达到开发、硬件、运维成本降低 X 倍的效果。
