本文正在参加「金石方案 . 瓜分6万现金大奖」

SPL作为专门用于结构化和半结构化数据的处理技能，在实践运用时常常能比SQL快几倍到几百倍，一起代码还会短许多，尤其在处理杂乱核算时优势十分显着。用户在看到这些运用作用后对SPL往往很感兴趣，但又忧虑把握起来太难，究竟SPL的理念和语法都跟SQL有较多不同，这要求用户需求重新了解一些概念和学习新的语法，用户或许会意生疑虑。

那么SPL的上手难度终究如何呢？这儿咱们以SQL为起点讨论一下这个问题。

1

SQL一直以来都是运用最广泛的结构化数据查询言语，在完结一般的查询核算时十分简略。像分组汇总一句简略的group by就完结了，相对Java这种要写几十行的高档言语几乎不能更简略。并且，SQL的语法规划也契合英语习惯，查询数据时就像说一句英语，这样也大大下降了运用难度。

不过，SQL的简略还主要面向简略查询，状况稍一杂乱就不太相同了，三五行的简略查询只存在于教科书中，实践事务要杂乱得多。

咱们用一个常常举的比如来阐明：核算某只股票的最长接连上涨天数。

这个核算并不难，依照天然的办法能够先按交易日排好序，设置一列计数器，逐条记载比较，假如上涨计数器就累加1，不然就清零，最终求出计数器的最大值即可。

可是，很不幸，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支撑的运算，可是SQL只要等值分组，没有依照数据的次第来做的有序分组，成果只能用子查询和窗口函数硬造分组符号，将接连上涨的记载的分组符号设置成相同值，这样才干再进行等值分组求出期望的最大值，这种很绕的写法要了解一下才干看懂。并且这仍是利用了SQL在2003规范中供给的窗口函数，能够直接核算比昨日的涨幅，从而比较方便地核算出这个符号，但依然需求几层嵌套。假如是更前期的SQL92规范，连涨核算都很难，整个句子还会杂乱许多倍。

读懂这句SQL就能感受SQL在完结这类核算时并不轻松，不支撑进程以及有序核算（窗口函数支撑程度依然较低）的SQL使得本来很简略的求解变得十分困难。

除了短少有序核算才干外，SQL还有不支撑游离记载，调集化不彻底、短少目标引证机制等缺乏，这些都会导致代码编写的困难。一个问题从想到解法（天然思路）到完结（写出代码）变得十分绕，要费很大劲才干完结，这就大幅添加了开发难度。事实上，咱们在实践事务中常常看到成百上千行的巨长SQL，常常是由于这种“绕”造成的。这些代码的开发周期常常以周乃至月为单位计，开发本钱极高。并且即便写出来，还会呈现过一两个月连作者都看不懂的为难状况，维护和交接本钱也很高。

代码写的杂乱，除了开发功率低本钱高以外，往往功能也不佳，即便写得出来也跑不快。

仍是用一个常常举的简略比如：1 亿条数据中取前 10 名。用SQL写出来并不杂乱：

SELECT TOP 10 x FROM T ORDER BY x DESC

这个查询用了ORDER BY，严格按此逻辑履行，意味要将全量数据做排序，而大数据排序是一个很慢的动作。假如内存不可还要向外存写缓存，屡次磁盘读写更会使功能急剧下降。

咱们知道，这个核算根本不需求大排序，只需始终保持一个10个最大数的调集，遍历（一次）数据时去小留大最终剩余的便是最大的10个了，只需求很少内存就能够完结，不触及重复外存读写。不幸的是，SQL却写不出来这样的算法。

不过还好，尽管语法有约束但能够在工程完结上想办法，许多数据库引擎碰到这个查询会自动进行优化，从而防止过于低效的算法。可是这种自动优化依然只对简略的状况有效。

现在咱们把TopN核算变得杂乱一些，核算每个分组内的前10名。SQL完结（现已有点麻烦了）：

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

这儿要先凭借窗口函数造一个组内序号出来（组内排序），再用子查询过滤出契合条件的记载。由于调集化不可彻底，需求用分区、排序、子查询才干变相完结，导致这个SQL变得有些绕。并且这时分，大部分数据库的优化器就会犯晕了，猜不出这句 SQL 的目的，只能老老实实地履行按句子书写的逻辑去履行排序（这个句子中仍是有ORDER BY的字样），成果功能陡降。

完全靠数据库自动优化靠不住，就得去了解履行方案来改造句子，有时分短少必要的运算根本无法改造成功，只能写UDF自己算，很难也很繁。乃至UDF也不管用，由于无法改动存储，为了保证功能常常还得自己用Java/C++在外围写，这时的杂乱度就十分高了，开发本钱也会急剧上升。

本来许多依照正常思想编写就能完结的使命，运用SQL却要常常迂回才干完结，导致代码过长且功能很差，常常自己都很难读懂就更别提数据库的自动优化引擎了。跑的慢就需求运用更多硬件资源来弥补，这又会添加硬件本钱，导致开发本钱和硬件本钱双高！

其实，现在业界现已意识到SQL在处理杂乱问题时的限制了，老练好用的数据仓库并不能只供给SQL。有一些数据仓库现已开始引入了Python、Scala，以及运用MapReduce等技能来处理这个问题，但目前为止作用并不抱负。MapReduce功能太差，硬件资源耗费极高，并且代码编写十分繁琐，且依然有许多难以完结的核算；Python 的Pandas在逻辑功能上还比较强，但细节上比较零乱，显着没有精心规划，有不少重复内容且风格不一起的当地，杂乱逻辑描绘依然不简略；并且短少大数据核算才干以及相应的存储机制，也很难获得高功能；Scala的DataFrame目标运用沉重，对有序运算支撑的也不可好，核算时发生的大量记载复制动作导致功能较差，一定程度乃至能够说是后退。

这也很简略了解，地基不稳的高楼再在楼上怎么修补也无济于事，只要推到重盖才干从根本处理问题。

而这些正是SPL要处理的问题。

2

SPL没有再根据SQL的联系代数系统，而是发明晰新的离散数据集理论以及在此基础上完结的SPL言语（相当于把SQL的高楼推倒重盖）。SPL支撑进程核算，并供给了有序核算等多种核算机制，在算法完结上与SQL有很大不同。

拿上面的比如来看。SPL核算股票最长接连上涨天数：

A
1 =stock_price.sort(trade_date)
2 =0
3 =A1.max(A2=if(closing_price> closing_price[-1],A2+1,0))

根本是依照天然思想解题进程完结的，排序、比较（用[-1]取上日数据）、求最大值，一二三步完结，十分简练。

即便运用SQL的完结逻辑，SPL也写起来也很简略：

stock_price.sort(trade_date).group@i(closing_price<closing_price[-1]).max(~.len())

核算思路和前面的 SQL完全相同，但SPL直接支撑有序分组，表达起来简略多了，不用再绕来绕去。

语法简练会大幅提高开发功率，开发本钱随之下降。一起，也会带来核算功能上的好处。

A
1 =file(“data.ctx”).create().cursor()
2 =A1.groups(;top(10,amount)) 金额在前10名的订单
3 =A1.groups(area;top(10,amount)) 每个地区金额在前10名的订单

像前面的TopN 运算在SPL中被认为是和 SUM 和 COUNT 相同的聚合运算，只不过返回值是个调集罢了。这样能够将高杂乱度的排序转换成低杂乱度的聚合运算，并且很还能扩展运用规模。

这儿的句子中没有排序字样，不会发生大排序的动作，数据量大也不会触及硬盘交互，在全集仍是分组中核算TopN的语法根本一起，都会有较高的功能。相似的高功能算法SPL还有许多，有序分组、位置索引、并行核算、有序归并等等，都能够大幅提高核算功能。

关于SPL的简练和高效的原因，咱们能够再看这个类比：

核算 1+2+3+…+100，普通人便是一步步地硬加，高斯很聪明地用50 *101一下搞定了。有了乘法这种新的运算类型，不管是描绘解法（代码简练）仍是施行核算（高效履行）都有了巨大的改观，完结使命变得简略得多了。

所以咱们说，50年前诞生的SQL（联系代数）就像只要加法的管用系统，代码繁琐且功能低下也是必定的。而SPL（离散数据集）则是发明晰乘法的管用系统，代码简练且高效也便是天然而然的事情了。

有人或许会问，运用乘法后的确更简略，但需求聪明的高斯才干想得到，而究竟不是人人都有高斯这么聪明，那是不是说SPL必须要聪明的程序员才干用起来，会不会难度更大？

这要从两方面来说。

一方面，有些核算本来或许想得出但写不出，像前面提到过的有序分组、不必大排序的TopN用SQL就完不成，最终只能忍受“加法”的绕；而SPL供给了许多“乘法”，你想得出解法的一起也能写出来，乃至还很简略。

另一方面，有些解法由于咱们没有高斯聪明的确想不到，但高斯现已想到了，咱们只需学会就能够了。1+2+…+100会，2+4+…+500也能会，常用的招术并不多， 做一些操练就都能把握。但的确也不是天生就能会的，需求一些练习，练习多了，这些手法就变成“天然”思想了，难度也并不大。

3

其实在实践事务中，SQL很难敷衍的场景还有许多。这儿咱们试举几个玩爆SQL的比如。

  • 杂乱有序核算：用户行为转换漏斗剖析

用户登录电商网站/APP后会发生页面阅读、查找、加购物车、下单、付款等多个操作事情。这些事情依照时刻有序，每个事情之后都会有用户丢失。漏斗转化剖析一般先要统计各个操作事情的用户数量，在此基础上再做转换率等杂乱的核算。这儿多个事情要在指定时刻窗口内完结、按指定次第发生才有效，属于典型的杂乱多步有序核算，SQL完结起来就十分不易。

  • 多进程大数据量跑批

离线跑批触及的数据量巨大（有时要触及全量事务数据），且核算逻辑十分杂乱，会随同多进程核算，彼此有先后顺序。一起跑批一般需求在指定时刻窗口内完结，不然会影响事务发生事端。

SQL很难直接施行这些核算，一般要凭借存储进程完结。触及杂乱核算时，要用游标读数进行核算，功率很低且无法施行并行核算，功率低下资源占用高。此外，存储进程完结代码往往多达几十步成千上万行，期间会随同中心成果重复落地，IO本钱极高，使命在跑批时刻窗口内完不成的现象时有发生。

  • 大数据上多目标核算，重复用相关多

目标核算是金融电信等职业的常用事务，随着数据量和目标数量（组合）增多完，由于核算进程会屡次运用明细数据，重复遍历大表，期间还触及大表相关、条件过滤、分组汇总、去重计数混合运算，一起还随同高并发。运用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来做：

A
1 =[“etype1″,”etype2″,”etype3”]
2 =file(“event.ctx”).open()
3 =A2.cursor(id,etime,etype;etime>=date(“2021-01-10”) && etime<date(“2021-01-25”) && A1.contain(etype) && …)
4 =A3.group(uid).(~.sort(etime))
5 =A4.new(~.select@1(etype==A1(1)):first,~:all).select(first)
6 =A5.(A1.(t=if(#==1,t1=first.etime,if(t,all.select@1(etype==A1.~ && etime>t && etime<t1+7).etime, null))))
7 =A6.groups(;count(~(1)):STEP1,count(~(2)):STEP2,count(~(3)):STEP3)

这个核算依照天然主意，其实只需按uid分组后，循环每个分组依照事情类型列表别离检查是否有对应记载（时刻），只是第一个事情比较特殊（需求单独处理），查找到后将其作为第二个事情的输入参数即可，此后第2到第N个事情的处理方式相同（能够用通用代码表达），最终依照用户分组计数即可。

上述SPL的解法与天然思想根本一起，利用有序、调集化分组等特性简略7步就能够完结，很简练。一起，这段代码能够处理任意进程数的漏斗。由于只遍历一次数据就能够完结核算，不触及外存交互，功能也更高。

4

不过，SPL作为一门程序言语，想要运用SPL达到抱负作用，仍是要求运用者对SPL供给的函数和算法有一定了解，才干从诸多函数中挑选适合的，这也是SPL初学者感到困惑的当地。SPL供给的是一套东西箱，运用者根据实践问题开箱挑选东西，是先拧螺丝，仍是先裁木板完全由需求决议，但一旦把握了东西箱内各个东西的运用办法，以后不管遇到什么工程问题都能很好处理，即便要对某些现有的东西进行改造（功能优化）也会游刃有余。而SQL供给的东西很少，这就会导致有时即便想到好办法也无从下手，常常需求经过很绕的方式才干完结，不仅难，还很慢。

当然，运用SPL要把握内容更多，某种意义上讲是“难”了一点。这就如同做运用题，小学生只用四则运算，看起来很简略；而中学生要学会方程的概念，常识要求变高了。可是小学生要根据具体问题来凑出解法，常常挺难的，每次还不相同；中学生则只需用固定套路列方程就完了，你说哪个更简略呢？

把握方程天然是要有学习的进程，没有把握这些常识时，会有些无从下手的感觉，由于陌生，所以会觉得难，SPL也相同。假如拿Java比较的话，SPL的学习难度要远低于Java，究竟Java中那些面向目标、反射等概念也十分杂乱。一个程序员连Java都学得会，SPL完全不在话下，只是要习惯一下，不要先入为主。

此外，对于某些十分杂乱对功能有极致要求的场景会触及一些比较深邃的算法常识，难度会大一些，这时能够找SPL专家来咨询一起制定处理方案。其实，要处理这些难题重要的是算法而不是言语本身，不管用什么技能这些作业都要做。只不过SQL由于调集化、离散性、有序性等方面的缺乏要完结这个作业会异常困难，乃至有些时分力不从心，而SPL要表达这类核算就相对简略。

说了这么多，咱们能够得出这样的结论。SQL只对简略场景简略，当面临杂乱事务逻辑时会由于“绕”导致既难写，跑得又慢，而这些杂乱事务才是咱们实践运用中的大头（28原则）。要让这些杂乱的场景完结变得简略就能够运用SPL来完结，SPL供给了更加简略高效的完结手法。仍是那句话，杂乱数据核算重点是算法，但算法不仅想出来还要能完结，并且完结起来不能太难（SQL就不可），SPL供给了这种或许。

SPL资料

  • SPL下载
  • SPL源代码