本文正在参与「金石方案 . 瓜分6万现金大奖」
SPL作为专门用于结构化和半结构化数据的处理技能，在实践运用时常常能比SQL快几倍到几百倍，一起代码还会短许多，尤其在处理杂乱核算时优势非常明显。用户在看到这些运用效果后对SPL往往很感兴趣，但又忧虑把握起来太难，毕竟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源代码
