DuckDB 风头正劲，这不是没道理的。作为桌面分析工具的当红明星，它把 SQL 玩得贼溜，CTE 递归查询、窗口函数套三层、复杂 JOIN，样样拿得出手。甚至跑个亿级数据的聚合统计，甩个SELECT AVG(revenue) FROM terabyte_table GROUP BY region就完了，这实力确实配得上掌声。但江湖再强的高手也有罩门，DuckDB 的短板就藏在那些“SQL 不擅长但业务偏偏爱折腾”的角落里。

遇上“变态需求”

举个例子，老板要算“每个客户最近 3 次下单的金额移动平均，且仅统计周末订单”。用 SQL 写？准备好三层嵌套吧：先过滤周末订单，再按客户分组排序，最后用窗口函数算移动平均。
当然，费点劲也能写出来，但这种事情不是费劲一次就完了，类似的需求很多，每次都呕心沥血毕竟不是长久之计。

还有更扎心的流程控制。想在 SQL 里搞个循环，根据条件动态调整计算逻辑？比如“若今日销量涨超 10% 则启动促销计算，否则跳过”。对不起，SQL 的 IF 和 LOOP 弱得跟摆设一样，绕来绕去费劲写出来的代码 3 天以后自己都看不懂。

Python 救场？

当然，DuckDB 早就想好了后路：“SQL 费劲的，交给 Python 嘛！”这话没毛病，DuckDB 库的 Python API 确实好用，随便 conn.sql().to_df() 就能无缝切到 pandas。

比如算“客户连续购买天数超过 5 天时，自动触发积分翻倍奖励”。用 SQL 写，窗口函数能算连续日期，但动态条件判断费事儿了，不如 Python 来的直接：

df = duckdb.sql("SELECT client, order_date FROM orders ORDER BY client, order_date").df()
df['order_date'] = pd.to_datetime(df['order_date'])
results = []
for client, group in df.groupby("client"):
    streak = 1  
    prev_date = None
    for date in group["order_date"]:
        if prev_date and (date - prev_date).days == 1:  
            streak += 1
        else:  
            streak = 1
        if streak >= 5:  
            results.append({"client": client, "bonus": "Doubling"})
        prev_date = date
print(results)

这代码能跑，但数据从 DuckDB 导出到 DataFrame，一个逻辑连贯的业务需求，非得拆成 SQL 预处理 +Python 后加工，思维在两个之间不停切换，编写调试别扭不说，时间也耗到数据搬运上了，直接让人精神分裂。

而且 Python 也不是啥都强，数据量较大时缺乏大数据处理能力，没提供真正的并行计算，从这方面来讲还不如 DuckDB。

SPL 专治各种“不服”

用 esProc SPL 就没这些问题了，它像是 DuckDB 和 Python 的“合体进化版”，一个体系搞定，省心省力。

和 DuckDB 一样，esProc SPL 提供 SQL 支持。CSV、Excel 这类常见格式直接就能跑 SQL。比如查个销售数据：

$SELECT region, SUM(amount) FROM sales.csv GROUP BY region

这种轻量级操作手到擒来。而且还提供了二进制格式文件，压缩比不错，数据读写很快，这些跟 DuckDB 的能力是一致的。

而对于复杂需求，esProc 还有原生的 SPL 语法来“兜底”，比如前面那个连续购买奖励的需求，用 SPL 写：

这个不仅算出来了该给哪些客户翻倍奖励，还可以获得这些客户的购买明细（A3），是不是有种想到业务前面的感觉？

SPL 对 JSON 的支持也比 DuckDB 好很多，多层数据直接点下去就行了：example. contact(1). metadata.verified，比 DuckDB 这种 json_extract(contact[1],’$.metadata.verified’) 要清爽多了。

面对 Python 大数据能力弱的缺点，SPL 则提供了完善支持。数据量大时，SPL 的游标机制直接教做人：

=file("huge.log").cursor@t()
=A1.groups(;sum(amount):total, count(~):rows)

数据流式读取，内存里只保留当前批次，百 GB 文件照样跑得飞起。还能并行分段处理：

=file("huge.log").cursor@tm(;4)  //4线程并行

DuckDB+Python 就像西餐刀叉配老干妈，分开用都挺香，凑一起总差点意思。esProc SPL 呢？直接给你上电火锅：SQL 的严谨它有，Python 的灵活它也有，外加一把“多源混算 + 大数据计算”的万能底料，一个体系搞定所有事情。数据工程师的终极梦想，不就是少写点代码多摸鱼吗？SPL 可能就是离摸鱼最近的捷径了。