对于桌面数据分析用户，如果说 DuckDB 是轻巧灵活的 "SQL 瑞士军刀"，那 esProc SPL 简直就是自带 Python 技能的 "全能工具箱"，既保留 SQL 的便捷，又突破 SQL 的天花板。
和 DuckDB 一样，esProc SPL 对文件处理的支持相当到位。CSV、Excel 这类常见格式直接当数据库用，直接就能跑 SQL。比如查个销售数据：
$SELECT region, SUM(amount) FROM sales.csv GROUP BY region
这种轻量级操作手到擒来。和 DuckDB 类似，esProc 也支持数据的二进制化，不过是存成文件的，压缩比很好，加载百万行数据秒开，比直接读 CSV 快三倍不止。
esProc 的 SQL 目前不支持窗口函数，不如 DuckDB 完善。不过 esProc 有个杀手锏是它的原生语言 SPL，处理复杂任务要比 SQL 简单很多，其实也用不着再写挠头的窗口函数了。
比如给各省销售额 Top3 的销售员发奖金的计算。用 SQL 得写多层嵌套：
WITH ranked_sales AS (
SELECT province, salesman, amount,
ROW_NUMBER() OVER(PARTITION BY province ORDER BY amount DESC) as rank
FROM sales
)
SELECT * FROM ranked_sales WHERE rank <=3
换 SPL 就直白得多：
sales.groups(province;top(-3;amount))
这种任务用 SQL 还能写出来，如果再难一点，比如要算“客户连续购买天数超过 5 天时，自动触发积分翻倍奖励”，恐怕就干瞪眼了。涉及流程控制，想在 SQL 里搞个循环，根据条件动态调整计算逻辑，对不起，SQL 的 IF 和 LOOP 弱得跟摆设一样，绕来绕去费劲写出来的代码 3 天以后自己都看不懂。所以 Duckdb 经常要依靠 Python。
DuckDB 的 Python 接口做得非常流畅，但组合使用时还是会有分裂感：SQL 查完数据读出到 DataFrame，完事儿可能又得写回数据库。两套体系，编写和调试都不一样，不仅思维需要切换，左右横跳也难受。就像在川菜馆点牛排，不是不行，就是别扭。
而 esProc SPL 则直接把 Python 的核心能力内置了。
上面”连买 5 天”的计算用 SPL 写：
| A | |
|---|---|
| 1 | $SELECT * FROM orders.csv ODDER BY client,order_date |
| 2 | =A1.group(client).conj(~.run(streak = if(order_date[-1] && order_date==order_date[-1]+1, streak+1, 1)).select(streak>=5)) |
| 3 | =A2.groups(client;"Doubling":bonus) |
这代码其实比 Python 还要更简洁。
有完善计算能力、支持过程计算、提供流程控制机制，esProc SPL 的能力超越了加装 Python 的 DuckDB。既有 SQL 的轻快，又有编程语言的灵活，还不用在多个工具间来回折腾。对于经常要处理复杂计算的桌面分析师来说，这可能是比 "SQL+Python" 组合更优雅的解法。毕竟，谁不想在一个窗口里就搞定所有累活呢？
