先说观点：因为还没找到更好的。

接下来说原因，首先来看看大数据平台都在干什么。

原因

结构化数据计算仍是重中之重

大数据平台主要是为了应对海量数据存储和分析的需求，海量数据存储的确不假，除了生产经营产生的结构化数据，还有大量音视频等非结构化数据，这部分数据很大，占用的空间也很多，有时大数据平台 80% 以上都存储着非结构化数据。不过，数据光存储还不行，只有利用起来才能产生价值，这就要进行分析了。

大数据分析要分结构化和非机构化数据两部分讨论。

结构化数据主要是企业生产经营过程中产生的业务数据，可以说是企业的核心，以往在没有大数据平台的时候企业主要或全部在使用的就是这部分数据。随着业务的不断积累，这部分数据也越来越大，传统数据库方案面临很大挑战，建设大数据平台自然要解决这部分核心数据分析问题。

有了大数据平台，给大家的想象空间也大了起来，以往无法利用的日志、图片、音视频等非结构化数据也要产生价值，这就涉及到非结构化数据分析了。相对核心业务数据分析，非结构化数据分析看起来更像是锦上添花。即使如此，非结构化数据分析并不是孤立存在，也还会伴随大量结构化数据处理。采集非结构化数据的同时，常常会伴随着采集许多相关的结构化数据，比如音视频的制作人、制作时间、所属类别、时长、…；有些非结构化数据经过处理后也会转变成结构化数据，比如网页日志中拆解出访问人 IP、访问时刻、关键搜索词等。所谓的非结构化数据分析，经常实际上是针对这些伴生而出的结构化数据。

结构化数据分析仍然是大数据平台的重中之重。而结构化数据处理技术就比较成熟了，比如我们常用的基于关系数据模型的关系数据库（SQL）。

SQL 仍是目前最广泛的结构化数据计算技术

回归 SQL 却是当前大数据计算语法的一个发展倾向。在 Hadoop 体系中，早期的 PIG Latin 已经被淘汰，而 Hive 却一直坚挺；Spark 上也在更多地使用 Spark SQL，而 Scala 反而少很多（Scala 易学难精，作为编译型语言不支持热部署也有很多不方便之处）。其它一些新的大数据计算体系一般也将 SQL 作为首选的计算语法，经过几年时间的混战，现在 SQL 又逐步拿回了主动权。

这个现象，大概有这么两个原因：

1. 实在没什么别的好用

关系数据库过于普及，程序员对 SQL 相当熟悉，甚至思维习惯都是 SQL 式的。SQL 用来做一些常规查询也比较简单，虽然用于处理复杂的过程计算或有序运算并不方便，但其它那些替代技术也好不到哪里去，碰到 SQL 难写的运算一样要写和 UDF 相当的复杂代码，反正都是麻烦，还不如继续用 SQL。

2. 大数据厂商的鼎力支持

大数据的技术本质是高性能，而 SQL 是性能比拼的关键阵地。比性能要面对同样的运算才有意义，过于专门和复杂的运算涉及的影响因素太多，不容易评估出大数据平台本身的能力。而 SQL 有国际标准的 TPC 系列，所有用户都看得懂，这样就有明确的可比性，厂商也会把性能优化的重点放在 SQL 上。

兼容 SQL 更利于移植

大数据平台兼容 SQL 的好处是很明显的，SQL 的应用非常广泛，会 SQL 的程序员很多，如果继续采用 SQL 则可以避免许多学习成本。支持 SQL 的前端软件也很多，使用 SQL 的大数据平台很容易融入这个现成的生态圈中。大数据平台打算替代的传统数据库也是 SQL 语法的，这样兼容性会很好，移植成本相对较低。

好了，我们说完大数据平台为什么会回归关系数据模型了。那么继续使用关系数据模型（SQL）会存在哪些问题呢？

问题

性能低

继续使用 SQL 的最大问题就是难以获得大数据计算最需要的高性能。

SQL 中缺乏一些必要的数据类型和运算定义，这使得某些高性能算法无法描述，只能寄希望于计算引擎在工程上的优化。传统商业数据库经过几十年的发展，优化经验已经相当丰富，但即使这样仍有许多场景难以被优化，理论层面的问题确实很难在工程层面解决。而新兴的大数据平台在优化方面的经验还远远不如传统数据库，算法上不占优，就只能靠集群更多的机器获得性能提升。另外，SQL 描述过程的能力不太好，不擅长指定执行路径，而想获得高性能常常需要专门优化的执行路径，这又需要增加许多特殊的修饰符来人为干预，那还不如直接用过程性语法更为直接，这也会妨碍用 SQL 写出高性能的代码。

SQL 发明之初的计算机硬件能力还比较差，要保证实用性，SQL 的设计必须适应当时的硬件条件，这就导致了 SQL 很难充分利用当代计算机的硬件能力，具体来说就是大内存、并行和集群。SQL 中的 JOIN 是按键值对应的，而大内存情况下其实可以直接用地址对应，不需要计算 HASH 值和比对，性能可以提高很多；SQL 的数据表无序，单表计算时还容易做到分段并行，多表关联运算时一般就只能事先做好固定分段，很难做到同步动态分段，这就难以根据机器的负载临时决定并行数量；对于集群运算也是这样，SQL 在理论上不区分维表和事实表，JOIN 运算简单地定义为笛卡尔积后过滤，要实现大表 JOIN 就会不可避免地产生占用大量网络资源的 HASH Shuffle 动作，在集群节点数太多时，网络传输造成的延迟会超过节点多带来的好处。

举个具体的例子，我们想在 1 亿条数据中取出前 10 名，用 SQL 写出来是这样的：

select top 10 x,y from T order by x desc

这个语句中有个 order by，严格按它执行就会涉及大排序，而排序非常慢。其实我们可以想出一个不用大排序的算法，但用 SQL 却无法描述，只能指望数据库优化器了。对于这句 SQL 描述的简单情况，很多商用数据库确实都能优化，使用不必大排序的算法，性能通常很好。但情况复杂一些，比如在每个分组中取前 10 名，要用窗口函数和子查询把 SQL 写成这样：

select * from
 (select y,*,row_number() over (partition by y order by x desc) rn from T)
where rn<=10

这时候，数据库优化器就会犯晕了，猜不出这句 SQL 的目的，只能老老实实地执行排序的逻辑（这个语句中还是有 order by 的字样），结果性能陡降。

开发效率低

不仅跑的慢，开发效率也不高，尤其在复杂计算方面，SQL 实现很繁琐。比如根据股票记录查询某只股票最长连续上涨天数，SQL（oracle）的写法如下：

SELECT MAX(ContinuousDays)-1
    FROM (
        SELECT code, NoRisingDays, COUNT(*) ContinuousDays
        FROM (
            SELECT code,
            SUM(RisingFlag) OVER (PARTITION BY code ORDER BY day) NoRisingDays
            FROM (
                SELECT code, day,
                CASE WHEN price>
                    LAG(price) OVER (PARTITION BY code ORDER BY day)
                THEN 0 ELSE 1 END RisingFlag
                FROM stock
            )
        ) GROUP BY NoRisingDays
    )

用了很绕的方式实现，别说写出来，看懂都要半天。

此外，SQL 也很难实现过程计算。什么是过程性计算呢？就是一步写不出来，需要多次分步运算，特别是与数据次序相关的运算。

我们举几个例子来看：

一周内累计登录时长超过一小时的用户占比，但要除去登录时长小于 10 秒的误操作情况

信用卡在最近三个月内最长连续消费的天数分布情况，考虑实施连续消费 10 天后积分三倍的促销活动

一个月中有多少用户在 24 小时连续操作了查看商品后加入购物车并购买的的动作，有多少用户在中间步骤中放弃？

……

（为了便于理解，这些例子已经做了简化，实际情况的运算还要复杂很多）

这类过程性运算，用 SQL 写出来的难度就很大，经常还要写 UDF 才能完成。如果 SQL 写都写不出来，那么 SQL 的使用效果将大打折扣。

开发效率低导致性能低

复杂 SQL 的执行效率往往也很低，这就又回到性能的问题了，实际上开发效率和计算性能是密切相关的，很多性能问题本质上是开发效率造成。

复杂 SQL 的优化效果很差，在嵌套几层之后，数据库引擎也会晕掉，不知道如何优化。提高这类复杂运算的性能，指望计算平台的自动优化就靠不住了，根本手段还要靠写出高性能的算法。象过程式运算中还常常需要保存中间结果以复用，SQL 需要用临时表，多了 IO 操作就会影响性能，这都不是引擎优化能解决的事情，必须要去改写计算过程。

所以，本质上，提高性能还是降低开发难度。软件无法提高硬件的性能，只能想办法设计复杂度更低的算法，而如果能够快速低成本地实现这些算法，那就可以达到提高性能的目标。如果语法体系难以甚至没办法描述高性能算法，必须迫使程序员采用复杂度较高的算法，那也就很难再提高性能了。优化 SQL 运算无助于降低它的开发难度，SQL 语法体系就是那样，无论怎样优化它的性能，开发难度并不会改变，很多高性能算法仍然实现不了，也就难以实质性地提高运算性能。

编写 UDF 在许多场景时确实能提高性能，但一方面开发难度很大，另一方面这是程序员硬写的，也不能利用到 SQL 引擎的优化能力。而且经常并不能将完整运算都写成 UDF，只能使用计算平台提供的接口，仍然要在 SQL 框架使用它的数据类型，这样还是会限制高性能算法的实现。

根本的解决方法，还是要让大数据平台真地有一些更好用的语法。

解法

使用开源集算器 SPL 就可以作为 SQL 很好的替代和延伸，作为大数据平台专用的计算语言，延续 SQL 优点的同时改善其缺点。

SPL 是一款专业的开源数据计算引擎，提供了独立的计算语法，整个体系不依赖关系数据模型，因此在很多方面都有长足突破，尤其在开发效率和计算性能方面。下面来盘点一下 SPL 都有哪些特性适用于当代大数据平台。

强集成性

首先是集成性，不管 SPL 多优秀，如果与大数据平台无法结合使用也是白费。要在大数据平台中使用 SPL 其实很方便，引入 jar 包就可以使用（本身也是开源的，想怎么用就怎么用）。SPL 提供了标准 JDBC 驱动，可以直接执行 SPL 脚本，也可以调用 SPL 脚本文件。

…
Class.forName("com.esproc.jdbc.InternalDriver");
Connection conn =DriverManager.getConnection("jdbc:esproc:local://");
Statement st = connection.();
//直接执行SPL脚本
//ResultSet rs = st.executeQuery("=100.new(~:baseNum,~*~:square2)");
//调用SPL脚本文件
CallableStatement st = conn.prepareCall("{call SplScript(?, ?)}");
st.setObject(1, 3000);
st.setObject(2, 5000);
ResultSet result=st.execute();
...

高效开发

敏捷语法

在结构化数据计算方面，SPL 提供了独立的计算语法和丰富的计算类库，同时支持过程计算使得复杂计算实现也很简单。前面举的计算股票最长连涨天数的例子，用 SPL 实现是这样的：

	A
1	=db.query("select * from stock order by day")
2	=A1.group@i(price<price[-1]).max(~.len())-1

按交易日排好序，将连涨的记录分到一组，然后求最大值 -1 就是最长连续上涨天数了，完全按照自然思维实现，不用绕来绕去，比 SQL 简单不少。

再比如根据用户登录记录列出每个用户最近一次登录间隔：

	A
1	=ulogin.groups(uid;top(2,-logtime))	最后2个登录记录
2	=A1.new(uid,#2(1).logtime-#2(2).logtime:interval)	计算间隔

支持分步的 SPL 语法完成过程计算很方便。

SPL 提供了丰富的计算类库，可以更进一步简化运算。

 

直观易用开发环境

同时，SPL 还提供了简洁易用的开发环境，单步执行、设置断点，所见即所得的结果预览窗口…，开发效率也更高。

 

多数据源支持

SPL 还提供了多样性数据源支持，多种数据源可以直接使用，相比大数据平台需要数据先“入库”才能计算，SPL 的体系更加开放。

 

SPL 支持的部分数据源（仍在扩展中…）

不仅如此，SPL 还支持多种数据源混合计算，充分发挥各类数据源自身的优势，扩展大数据平台的开放性。同时，直接使用多种数据源开发实现上也更简单，进一步提升开发效率。

热切换

SPL 是解释执行的，天然支持热切换，这对 JAVA 体系下的大数据平台是重大利好。基于 SPL 的大数据计算逻辑编写、修改和运维都不需要重启，实时生效，开发运维更加便捷。

 

高计算性能

前面我们说过，高性能与高开发效率本质上是一回事，基于 SPL 的简洁语法更容易写出高性能算法。同时，SPL 还提供了众多高性能数据存储和高性能算法机制，SQL 中很难实现的高性能算法及存储方案用 SPL 却可以轻松实现，而软件提高性能关键就在于算法和存储。

例如前面说过的 TopN 运算，在 SPL 中 TopN 被理解为聚合运算，这样可以将高复杂度的排序转换成低复杂度的聚合运算，而且很还能扩展应用范围。

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

这里的语句中没有排序字样，也不会产生大排序的动作，在全集还是分组中计算 TopN 的语法基本一致，而且都会有较高的性能。