大数据时代的分布式数仓（如 MPP）是个热门技术，甚至到了提到数据仓库言必称分布式的地步。
但是，分布式数仓真有必要吗？毕竟这些分布式数仓产品都不便宜，无论是采购成本还是运维成本都很高。是不是有低成本轻量级的方案呢？
其实，结构化数据计算任务（数据仓库的主要目标）涉及的数据量通常并不会非常大。比如一个有数千万帐户的银行，一年的交易量也就是数亿条，大概也就是几 G 到几十 G 的规模；有个几百万帐户的电商系统能积累的数据也还是这种规模。即便是少数有巨大数据量的头部企业，也还是会有大量任务只涉及少量数据。单个计算任务的数据规模上百 G 并不多，很难积累到很多大数据厂商宣称的 PB 级。
从另一个方面也可以看出来，大多数分布式数仓的节点数也不是很多，经常在十个左右或更少。个别头部企业的计算中心可能会有数千甚至上万个节点，但单个任务也只会用到其中几个到十几个节点。比如 SnowFlake 销售数量较多的 Medium 型数仓，也只有 4 个节点而已。这才是分布式数仓的主流规模。一个 PB 级数据量的任务，一个节点处理 1T（通常也需要数小时），也需要 1000 个节点，这显然不是常态。
按说单体数据库就能轻松处理几十 G 规模的数据，但实际上并不是，跑批动不动几小时，查询一次几分钟也是家常便饭。于是，用户就会琢磨着上分布式了。
这又是为什么？
这有两方面原因。一方面是这些计算任务的数据量虽然不大，但却有相当的复杂度，经常会涉及多次关联。另一方面是数据库采用的 SQL 语法不能方便地描述这些复杂的运算，勉强写出来的代码不会被数据库优化，导致计算量过大。换句话说，SQL 数据库无法充分利用硬件资源，只能寄希望于分布式扩容。
esProc SPL 可以。
esProc SPL 是开源的轻量级计算引擎，在这里：https://github.com/SPLWare/esProc 。作为纯 Java 开发的程序，可以直接无缝嵌入到 Java 应用中，无须数据库也能获得高性能计算的体验。
esProc SPL 常常能跑出远超 MPP 的性能，单机顶集群。
国家天文台的星体聚类任务，数据规模仅约 5000 万行，某分布式数据库动用 100CPU 跑 500 万行也要 3.8 小时，跑完 5000 万行估算要 15 天（平方级复杂度）。esProc SPL 在 16CPU 单机上跑全量 5000 万数据不到 3 小时。
某银行的贷款业务跑批，HIVE 集群 10 节点，1300 行 SQL 跑 4300 秒；esProc SPL 用 34 行代码在单机上跑 1700 秒。
某银行的反洗钱准备，11 节点的 Vertica 跑出 1.5 小时，esProc SPL 单机 26 秒，竟然把跑批任务跑成了查询！
某电商漏斗运算，SnowFlake 的 Medium 型集群（4 节点）3 分钟跑不出结果，用户放弃。esProc SPL 在单机上 10 秒完成。
某时空碰撞任务，ClickHouse 集群 5 节点 1800 秒，被 esProc SPL 优化成单机 350 秒。
.......
这些实例还可以进一步说明，大量的实际任务的集群节点数并不多，这类场景几乎都可以被 esProc 用单机解决。
esProc SPL 如何做到这一点？
在工程方面，esProc 也采用了压缩、列存、索引以及向量式计算等 MPP 常用的提速技术；更重要的，esProc 没有再基于 SQL，而是采用了自有的程序语言 SPL，其中有不少 SQL 理论基础下无法实现的高性能存储机制和算法类库：
有了这些基础，就容易编写出更低计算复杂度的代码，有效地避免 SQL 代码计算量过大的问题，充分利用硬件资源，做到单机顶集群。
关于 esProc 的性能优势，在 快出数量级的性能是怎样炼成的 有通俗的解释 写着简单跑得又快的数据库语言 SPL 中深入解释为什么 SQL 无法写出高性能代码。
上图中列出了部分 SPL 的高性能技术，可以看到 esProc 也支持集群计算。但由于 esProc 的高性能，在实践任务中都仅用单机就实现原有集群的能力。结果，除了部分为了应对高并发和热备的简单集群场景外，esProc 的集群计算能力一直没有机会被深度历练，甚至一定程度可以说还不够成熟。
看个具体的例子，前述那个时空碰撞问题，总数据量约 250 亿行，SQL 看起来并不算很复杂：
WITH DT AS ( SELECT DISTINCT id, ROUND(tm/900)+1 as tn, loc FROM T WHERE tm<3*86400)
SELECT * FROM (
SELECT B.id id, COUNT( DISINCT B.tn ) cnt
FROM DT AS A JOIN DT AS B ON A.loc=B.loc AND A.tn=B.tn
WHERE A.id=a AND B.id<>a
GROUP BY id )
ORDER BY cnt DESC
LIMIT 20
传统数据库跑得太慢，用户转而求助于 ClickHouse，结果用了 5 节点的集群环境下也跑了 30 分钟多，达不到期望。同样数据量，SPL 代码只用一个节点不到 6 分钟即可完成计算，超出了用户期望。考虑到硬件资源的差距，SPL 相当于比 ClickHouse 快了 25 倍以上。
|---|----------------------------------------------------------------------|
| | A |
| 1 | =now() |
| 2 | >NL=100000,NT=3*96 |
| 3 | =file("T.ctx").open() |
| 4 | =A3.cursor(tm,loc;id==a).fetch().align(NL*NT,(loc-1)*NT+tm\900+1) |
| 5 | =A3.cursor@mv(;id!=a && A4((loc-1)*NT+tm\900+1)) |
| 6 | =A5.group@s(id;icount@o(tm\900):cnt).total(top(-20;cnt)) |
| 7 | =interval@ms(A1,now()) |
（SPL 代码写在格子里，这和普通程序语言很不像，参考这里 写在格子里的程序语言 ）
SQL 中的 DISTINCT 计算会涉及 HASH 和比对，数据量很大时计算量也会很大，然后还有自关联以及进一步的 COUNT(DISTINCT)，都会严重拖累性能，而 SPL 可以充分利用 SQL 没有的有序分组和序号定位，有效避免复杂度很高的自关联和 DISTINCT 运算。虽然在存储效率上比 ClickHouse 并没有优势，Java 也会略慢于 C++，但仍然获得了数量级的性能提升。
跑出 300 公里时速不见得总要高铁（分布式 MPP），家用小轿车（esProc SPL) 也可以。