Polars 换了个默认值，无数数据管道慌了

一行 collect()，改变了无数数据管道的运行方式。

2026 年 10 月 6 日，Polars 发布 2.0：LazyFrame.collect() 默认切换到流式引擎（streaming engine），换来的是官方所称的「大规模内存与性能优势」。但同一句话里还藏着另一个后果——对 join、group_by 和 unpivot 这三类算子，除非显式设置 maintain_order，输入行的顺序不再被保证。

这不是一个 feature，而是一次静默的契约变更。大量 pipeline 从来没有「声明」过自己依赖行序——它们只是恰好一直在拿到有序结果。2.0 之后，这份运气到期了。

⚡ 一次 collect()，暴露了被隐藏的依赖

最常见的翻车场景是这样的：一段跑了很久的数据处理代码，做了一次 inner join，然后逐行对比输出、或者把结果写成文件，让下游步骤按位置读取。在旧版本里，结果一直是对的——不是因为代码写对了，而是因为引擎「碰巧」保住了顺序。

有开发者实测：在 polars 2.0.0 上跑一个 200 万行的 inner join，默认配置下返回的行不再按输入顺序排列；而只要在 join 上显式设置 maintain_order，顺序就被保留。

问题在于，「碰巧正确」的代码，故障表现极其隐蔽。同一份数据，在不同机器、不同并行度下，可能给出不同的答案。测试环境对，生产环境错；今天对，明天错。这不是崩溃，是静默的数据漂移——比崩溃可怕得多。

产业逻辑很清楚：每一次引擎层面的默认值变更，都是一次对全量用户代码的隐性审计。引擎作者认为「行序本就不该是承诺」，这在理论上是站得住的——SQL 语义里 join 本来就无序。但工程现实是，十年积累下来的 pipeline 里，大量代码把「实现细节」当成了「契约」。升级即翻车，翻车还无声。

据社区里的私下反馈，不少团队已经把 2.0 的升级评估列为专项，重点不是性能回归，而是行序敏感性扫描。

🔀 流式引擎为什么「不敢」保序

为什么流式引擎偏偏不保证 join、group_by、unpivot 的行序？答案藏在它的运行方式里。

流式引擎的核心卖点是数据不必全部装进内存——数据以流的方式分块（chunk）流过算子，边算边吐。join 要把左右两侧的数据做匹配，group_by 要把散落各处的行归拢到一起，这些操作一旦并行化、分块化，输出顺序就取决于调度和完成的先后，而不是输入的先后。要强行恢复顺序，要么插入昂贵的排序步骤，要么牺牲并行度——流式引擎的性能优势会立刻打折。

所以这是一个教科书式的工程权衡：

注意表格里的措辞：旧版本是「事实上保序」——它是实现的结果，不是承诺。2.0 做的事，本质是把「事实」和「契约」对齐：想要顺序，请显式声明 maintain_order，并为它付费。

这对整个数据处理生态是个信号。当引擎越来越快、越来越并行，顺序正在从免费默认变成显式选项。pandas 时代养成的「行序即语义」的直觉，正在被新一代引擎系统性纠正。

💾 80% 内存、64GB 磁盘：溢写的代价与底气

2.0 的另一个默认变更：out-of-core（核外处理）默认开启。

具体机制是：当内存使用达到约 80% 时，引擎开始把数据溢写（spill）到磁盘，磁盘预算默认 64GB。这意味着过去那种「数据比内存大就跑不动、得换 Spark 或者分片处理」的场景，现在单机 Polars 就能硬扛。

从这张定位图能看出 2.0 的野心：以前 Polars 卡在「快但受内存限制」的象限，out-of-core 默认开启后，它正在向右上方移动——既保留单机的易用性，又蚕食分布式引擎的规模地盘。64GB 的磁盘预算给了溢写充足的余量，80% 的水位线则是在性能和稳定性之间取的平衡点：留 20% 余量给运行时开销，避免 OOM。

但溢写不是免费的。磁盘 IO 的速度比内存慢一到两个数量级，一旦触发 spill，查询耗时会显著上升。工程上的判断是：out-of-core 是兜底能力，不是常态优化。合理的用法是把数据量控制在内存内吃满性能，让溢写只作为「偶尔超了也能跑」的安全网，而不是把 64GB 磁盘预算当成设计容量。

📊 基准测试的脚注，比正文更值得读

2.0 的发布帖由 Ritchie Vink 撰写，其中附带的基准测试相当亮眼。但真正体现专业度的，是那条容易被略过的脚注：测试结果是厂商自己的运行，其注释明确说明结果不可与官方 TPC 结果直接比较。

这句话的分量，老数据工程师都懂。数据库领域的基准测试历来是重灾区：硬件配置、数据生成方式、调参深度，每一项都能让结果差出数倍。厂商自测结果作为性能方向的参考没问题，作为选型依据则要打折扣。Polars 团队主动在脚注里声明这一点，反而是一种可信度的体现——相比之下，把自测跑分当卖点的项目并不少见。

更深层的问题是：基准测试测的是算子速度，但生产事故往往出在语义边角。行序就是一个典型的语义边角——它不出现在任何跑分里，却能让对账失败。引擎选型时，看两份材料：一份是性能基准及其脚注，一份是行为变更清单（behavior changes）。后者通常更短，也更致命。

🛠️ 从「碰巧正确」到「显式正确」

那么，已经上生产的老代码该怎么办？工程上的答案只有一条：把所有对行序的依赖显式化。

具体执行上有三个层次。第一层是机械动作：在所有已知依赖行序的 join、group_by 上加 maintain_order 参数，这一步保住正确性。第二层是语义重构：审视为什么下游需要行序——如果是因为按位置读文件、按顺序对比结果，更好的修法是引入显式排序或主键，让代码不再依赖任何「碰巧」。第三层是容量规划：评估哪些任务会触发溢写，把磁盘预算和数据规模纳入监控。

业界私下有句话说得很直白：升级大版本，性能提升是厂商的事，语义变更是用户的事。2.0 恰好是这句话的完美注脚——流式引擎的性能红利是所有人的，而行序的坑只埋给那些从不显式声明假设的代码。

往前看，这个趋势不会止于 Polars。计算引擎的并行度只会越来越高，隐式保证只会越来越少。对数据工程师来说，真正的护城河不是记住某个版本的默认值，而是写出不依赖任何实现细节的代码——引擎换了、顺序乱了、机器换了，结果依然正确。2.0 只是把这一天提前了。

小结：Polars 2.0 用一次默认值变更，撕开了数据工程里最普遍的技术债——对行序的隐式依赖。流式引擎默认开启、out-of-core 溢写、maintain_order 显式化，三件事指向同一个方向：性能和规模从「免费」变成「需要声明代价」。升级前做一次行序审计，远比看任何跑分都有价值。