Polars 2.0换了个默认值，管道全变了

🚨 一个默认值，让管道悄悄换了答案

数据工程里最危险的bug，是那种不报错的bug。

Polars 2.0在2026年10月6日发布，Ritchie Vink的发布博客里只用一句话描述了这次核心变更：LazyFrame.collect()现在默认运行流式引擎（streaming engine），带来「massive memory and performance」的收益。

听起来全是好消息。但流式引擎有一个隐含代价：对join、group_by和unpivot这三类操作，它不再承诺保持输入行序，除非你显式设置maintain_order。

有人实测过。在polars 2.0.0上，一个200万行的inner join，默认配置下返回的行序已经和输入不一致；一旦在join上加上maintain_order，输入顺序又回来了。行为切换干净利落，但代价由不知情的用户承担。

问题是，大量数据管道恰恰依赖这种隐式行为。你的测试代码逐行比对输出？你的下游按位置读取上一步写的文件？都可能因为换了一台机器、换了一个版本，给出不一样的答案——而且不报错、不告警，只是安静地『变』了。

性能是显性的，确定性是隐性的。而生产系统里，隐性假设往往才是成本最高的那部分。

⚙️ 流式引擎成默认，底层到底改了什么

先说清楚这次变更的技术事实，一共三条：

第一，collect()默认走流式引擎。这意味着即使你的代码一行没改，执行路径已经从传统的内存批处理引擎切换到了流式引擎。

第二，join、group_by、unpivot不再默认保证输入行序。这是流式执行模型的自然结果——数据以分块（chunk）方式流动，算子并行处理，各块的到达和处理顺序不等于输入顺序。

第三，out-of-core处理默认开启。内存用到约80%时开始向磁盘溢写（spill），默认磁盘预算为64 GB。这是「massive memory and performance」承诺的另一面：引擎可以处理超出内存的数据集，但磁盘IO从此成为你性能模型里的一部分。

把这些串起来，一次collect()背后的执行链路大致是这样的：

如果你在2.0之前写过依赖行序的逻辑，这份链路图里有两个分叉点需要重点关注：maintain_order的开关，和磁盘溢写的触发时机。

据多位在生产环境里踩过坑的从业者私下反馈，这类『引擎升级、行为变化』造成的翻车，往往不是在发布当天爆出来，而是在某个节假日后的批量对账环节才被发现——因为只有那时候，才会有人逐行核对两份数据是否一致。

📊 显式确定性：数据工程的新门槛

这次变更最值得讨论的，不是Polars本身，而是它把一个问题摆上了台面：你的管道里，有多少逻辑依赖的是引擎的『脾气』，而不是契约？

行序就是最典型的隐式契约。SQL标准从来不保证join和group_by的输出顺序，老牌数据库用户对此心知肚明——想要顺序就显式ORDER BY。但DataFrame生态长期用『默认保序』宠坏了用户，很多管道的确定性建立在实现细节而非语义承诺之上。

把这次变更的关键行为整理成一张表，方便对照排查：

一个务实的判断标准：如果你的管道只在单机、单版本、内存充裕的条件下测试通过，那它大概率带着行序假设。升级到2.0后，第一个该做的不是跑性能测试，而是跑正确性测试——尤其是逐行比对类的回归用例。

当然，也别只盯着风险。流式引擎加out-of-core，本质上是把Polars从『pandas的快替身』推向『单机海量数据处理引擎』的定位。过去需要拆分数据或上分布式框架的场景，现在可能一台大内存机器加一个64 GB的磁盘预算就够。对一个体量中等的团队来说，这是实打实的架构降本。

省下来的机器钱是显性的，但前提是，你得先把隐式行为变成显式契约。

🤔 发布基准的footnote，值得多看一眼

还有一条容易被忽略的信息：发布博客里那组漂亮的基准测试，是Ritchie Vink团队自己的运行结果，而且footnote明确写了——这些结果不可与官方TPC结果作比较。

这不是Polars独有的问题，而是所有引擎发布宣传的通病。厂商自测的基准，选数据、选硬件、选对比对象都有自由度；官方TPC结果至少要接受审计。两者之间的差距，只有读footnote的人才知道。

给工程团队的务实建议是：任何引擎升级决策，用你自己的数据和查询重跑一遍基准。发布博客的数字可以当作『值得一看』的信号，但不必当作『可以拍板』的依据。

再放大一点看，这次变更发生的行业节点也很微妙。同期，Apache Doris 5.0正在通过接入Fluss的日志表和主键表，把Paimon的历史数据与近实时数据做Union Read，实现流批统一查询。两条新闻放在一起，指向同一个趋势：

引擎们都在往『更大数据量、更低资源门槛、统一读写路径』的方向走。性能和资源效率在进步，代价则是——曾经由实现细节免费提供的那些『副作用』（比如保序），开始被重新计价。要么付显式设置的成本，要么接受不确定性的风险。

🛠️ 三条落地建议

结合这次变更，给正在或计划升级Polars 2.0的团队三条可执行建议：

一、升级前先做行序审计。 全局搜索管道里所有join、group_by、unpivot调用，逐个判断下游是否依赖行序：逐行比对的测试、按位置读取的文件写入、固定顺序的导出报告，都是高危点。确认依赖的，显式加maintain_order；不依赖的，加个注释说明『此处无需保序』，让下一个维护者不用再猜。

二、把磁盘溢写纳入容量规划。 out-of-core默认开启后，80%内存触发线加64 GB默认磁盘预算，意味着高峰期的性能模型里多了磁盘IO这一项。如果你的机器磁盘是慢速盘，或者和日志写入共享磁盘，提前评估，别让溢写成为高峰期的隐形瓶颈。

三、基准测试用自己的数据重跑。 发布博客的数字仅作参考，footnote里那句『不可与官方TPC结果比较』要认真对待。拿真实的查询负载、真实的机器环境跑一遍，才是决策依据。

小结

Polars 2.0的这次变更是『一个默认值』引发的连锁反应，但它真正揭示的，是数据工程从『依赖引擎脾气』走向『依赖显式契约』的行业拐点。流式引擎和out-of-core带来的是性能与规模的跃迁，行序与溢写行为的变化则是必须付清的账单。往后的引擎竞争，比的不只是谁跑得快，还有谁把『什么会变、什么不会变』写得足够清楚。而对工程师来说，最好的应对从来只有一条：把隐式假设，一个一个变成显式的代码。