作者：好物所得
SPL 作为专门用于结构化和半结构化数据的处理技术，在实际应用时经常能比 SQL 快几倍到几百倍，同时代码还会短很多，尤其在处理复杂计算时优势非常明显。用户在看到这些应用效果后对 SPL 往往很感兴趣，但又担心掌握起来太难，毕竟 SPL 的理念和语法都跟 SQL 有较多不同，这要求用户需要重新了解一些概念和学习新的语法，用户可能会心生疑虑。
那么 SPL 的上手难度究竟如何呢？这里我们以 SQL 为起点讨论一下这个问题。
1
SQL 一直以来都是使用最广泛的结构化数据查询语言，在实现一般的查询计算时非常简单。像分组汇总一句简单的 group by 就实现了，相对 Java 这种要写几十行的高级语言简直不能更简单。而且，SQL 的语法设计也符合英语习惯，查询数据时就像说一句英语，这样也大大降低了使用难度。
不过，SQL 的简单还主要面向简单查询，情况稍一复杂就不太一样了，三五行的简单查询只存在于教科书中，实际业务要复杂得多。
我们用一个经常举的例子来说明：计算某只股票的最长连续上涨天数。
这个计算并不难，按照自然的方法可以先按交易日排好序，设置一列计数器，逐条记录比较，如果上涨计数器就累加 1，否则就清零，最后求出计数器的最大值即可。
但是，很不幸，SQL 无法直接描述这个有过程的逻辑（除非用存储过程），于是只能更换思路实现：
使用另一个思路，把交易记录分组，连续在上涨的记录都分到一组，这样只要计算出最大的那一组的成员数就可以了。分组和统计都是 SQL 支持的运算，但是 SQL 只有等值分组，没有按照数据的次序来做的有序分组，结果只能用子查询和窗口函数硬造分组标记，将连续上涨的记录的分组标记设置成相同值，这样才能再进行等值分组求出期望的最大值，这种很绕的写法要理解一下才能看懂。而且这还是利用了 SQL 在 2003 标准中提供的窗口函数，可以直接计算比昨天的涨幅，从而比较方便地计算出这个标记，但仍然需要几层嵌套。如果是更早期的 SQL92 标准，连涨计算都很难，整个句子还会复杂很多倍。
读懂这句 SQL 就能感受 SQL 在实现这类计算时并不轻松，不支持过程以及有序计算（窗口函数支持程度仍然较低）的 SQL 使得原本很简单的求解变得十分困难。
除了缺乏有序计算能力外，SQL 还有不支持游离记录，集合化不彻底、缺少对象引用机制等不足，这些都会导致代码编写的困难。一个问题从想到解法（自然思路）到实现（写出代码）变得非常绕，要费很大劲才能实现，这就大幅增加了开发难度。事实上，我们在实际业务中经常看到成百上千行的巨长 SQL，经常是因为这种“绕”造成的。这些代码的开发周期经常以周甚至月为单位计，开发成本极高。而且即使写出来，还会出现过一两个月连作者都看不懂的尴尬情况，维护和交接成本也很高。
代码写的复杂，除了开发效率低成本高以外，往往性能也不佳，即使写得出来也跑不快。
还是用一个经常举的简单例子：1 亿条数据中取前 10 名。用 SQL 写出来并不复杂：
这个查询用了 ORDER BY，严格按此逻辑执行，意味要将全量数据做排序，而大数据排序是一个很慢的动作。如果内存不够还要向外存写缓存，多次磁盘读写更会使性能急剧下降。
我们知道，这个计算根本不需要大排序，只要始终保持一个 10 个最大数的集合，遍历（一次）数据时去小留大最后剩下的就是最大的 10 个了，只需要很少内存就可以完成，不涉及反复外存读写。不幸的是，SQL 却写不出来这样的算法。
不过还好，虽然语法有限制但可以在工程实现上想办法，很多数据库引擎碰到这个查询会自动进行优化，从而避免过于低效的算法。但是这种自动优化仍然只对简单的情况有效。
现在我们把 TopN 计算变得复杂一些，计算每个分组内的前 10 名。SQL 实现（已经有点麻烦了）：
这里要先借助窗口函数造一个组内序号出来（组内排序），再用子查询过滤出符合条件的记录。由于集合化不够彻底，需要用分区、排序、子查询才能变相实现，导致这个 SQL 变得有些绕。而且这时候，大部分数据库的优化器就会犯晕了，猜不出这句 SQL 的目的，只能老老实实地执行按语句书写的逻辑去执行排序（这个语句中还是有 ORDER BY 的字样），结果性能陡降。
完全靠数据库自动优化靠不住，就得去了解执行计划来改造语句，有时候缺少必要的运算根本无法改造成功，只能写 UDF 自己算，很难也很繁。甚至 UDF 也不管用，因为无法改变存储，为了保证性能常常还得自己用 Java/C++ 在外围写，这时的复杂度就非常高了，开发成本也会急剧上升。
本来很多按照正常思维编写就能完成的任务，使用 SQL 却要经常迂回才能实现，导致代码过长且性能很差，经常自己都很难读懂就更别提数据库的自动优化引擎了。跑的慢就需要使用更多硬件资源来弥补，这又会增加硬件成本，导致开发成本和硬件成本双高！
其实，现在业界已经意识到 SQL 在处理复杂问题时的局限了，成熟好用的数据仓库并不能只提供 SQL。有一些数据仓库已经开始引入了 Python、Scala，以及应用 MapReduce 等技术来解决这个问题，但目前为止效果并不理想。MapReduce 性能太差，硬件资源消耗极高，而且代码编写非常繁琐，且仍然有很多难以实现的计算；Python 的 Pandas 在逻辑功能上还比较强，但细节上比较零乱，明显没有精心设计，有不少重复内容且风格不一致的地方，复杂逻辑描述仍然不容易；而且缺乏大数据计算能力以及相应的存储机制，也很难获得高性能；Scala 的 DataFrame 对象使用沉重，对有序运算支持的也不够好，计算时产生的大量记录复制动作导致性能较差，一定程度甚至可以说是倒退。
这也很容易理解，地基不稳的高楼再在楼上怎么修补也无济于事，只有推到重盖才能从根本解决问题。
而这些正是 SPL 要解决的问题。
