SPL 集群不提供复杂沉重的自动化管理功能,而是允许对每个节点进行个性化配置。程序员可以根据数据特征和计算目标来决定各节点存储什么样的数据,完成哪些计算。这样做,不仅大大降低了架构复杂度,也是提升性能的重要手段。以订单分析为例,订单表很大,要通过产品号字段与较小的产品表主键做关联,再按照产品供应商分组汇总订单金额。SPL 集群可以很容易的将订单表分段存放在各个节点的硬盘上,再将较小的产品表读入每个节点的内存中。计算时,每个节点仅对本机上的订单分段和产品数据做关联、分组汇总,可以缩短总计算时间;再将结果传输到一个节点上做二次汇总。由于传输的是第一次汇总的结果,数据量小、网络传输时间较短。总体来说,这个方案可以获得最佳性能,虽然程序员需要做一些更细致的工作,但对于小规模集群来说,增加的工作量并不大。SPL 也不提供超强的容错能力,不会像 Hadoop 那样,在有节点故障的情况下,还要保证任何一个任务都会执行成功。实际上,大多数计算任务的执行时间都在几个小时以内,而几台、十几台机器的集群一般都能做到较长时间正常运行,不会这么频繁的出故障。即使偶尔出现节点故障导致任务执行失败,再重新计算一遍也可以接受,毕竟这种情况不会经常发生。所以,SPL 的容错能力只是保证有少数节点故障的时候,整个集群还能继续工作并接受新任务(包括重算的任务),这就大大降低了 SPL 集群的复杂度。在内存计算方面,SPL 没有使用 Spark RDD 的 immutable 机制,而是采用了指针式复用机制,利用地址(指针)访问内存,在数据结构没有改变的情况下,直接用原数据的地址形成结果集,不必每个计算都将数据复制一遍,仅仅多保存一个地址(指针),可以同时减少 CPU 和内存的消耗,运行起来要比 Spark 轻很多了。并且,SPL 改进了当前的外存计算算法体系,降低了复杂度并扩大了适应范围,可以做到内外存计算结合,充分提升计算性能的同时,还不像 Spark 那样依赖大内存。使用简单SPL 采用轻量级技术,自然更容易安装、配置和运行维护。SPL 不仅可以作为独立服务器使用,还很容易集成到需要高性能计算的应用中,比如即时查询系统,只要引入几个 jar 包即可。Hadoop 则很难集成,只能在边上作为一个数据源运行。有些临时性数据需要随时进行处理,则可使用 SPL 的桌面集成开发环境可视化地计算,快速得到结果。如果要安装部署 Hadoop,那么等环境搭建好时临时数据任务已经过期了。前面展示的众多 SPL 高性能算法,也能让大数据计算编程变得简单。程序员可以在较短时间内掌握这些算法函数,学习成本相对较低。而且,使用这些现成的函数很容易实现各种复杂的计算需求,不仅比 MapReduce/Scala 简单,比 SQL 也简单很多。比如,以电商网站常见的漏斗分析为例,用 SQL 实现三步漏斗的代码大致如下:with e1 as ( select gid,1 as step1,min(etime) as t1 from T where etime>= to_date('2021-01-10', 'yyyy-MM-dd') and etime<to_date('2021-01-25', 'yyyy-MM-dd') and eventtype='eventtype1' and … group by 1 ), with e2 as ( select gid,1 as step2,min(e1.t1) as t1,min(e2.etime) as t2 from T as e2 inner join e1 on e2.gid = e1.gid where e2.etime>= to_date('2021-01-10', 'yyyy-MM-dd') and e2.etime<to_date('2021-01-25', 'yyyy-MM-dd') and e2.etime > t1 and e2.etime < t1 + 7 and eventtype='eventtype2' and … group by 1 ), with e3 as ( select gid,1 as step3,min(e2.t1) as t1,min(e3.etime) as t3 from T as e3 inner join e2 on e3.gid = e2.gid where e3.etime>= to_date('2021-01-10', 'yyyy-MM-dd') and e3.etime<to_date('2021-01-25', 'yyyy-MM-dd') 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.gid = e2.gid left join e3 on e2.gid = e3.gid SQL 写出来要三十多行,理解起来有相当的难度。如果用 MapReduce/Scala 来写,会更加困难。即使是用 SQL 实现,写出来的这段代码和漏斗的步骤数量相关,每增加一步就要再增加一段子查询。相比之下,SPL 就简单得多,处理任意步骤数都是下面这样简洁的代码: