一个默认值改动，晃动了半条数据管道

2026 年 10 月 6 日，Polars 2.0 发布。发布说明里最要命的一行字不是性能提升多少，而是：collect() 默认跑流式引擎了，join、group_by、unpivot 不再保证输入行序。我的核心判断是：这一次，性能红利是真的，工程账单也是真的——数据基础设施里的『默认值』从来不是细节，而是契约。

🔄 发布说明一句话，埋了无数管道一颗雷

先讲一个正在很多团队复现的场景。凌晨两点，批处理作业跑完，数据质量校验突然红了：输出和昨天对不上。没人改业务逻辑，唯一的变量是 Polars 从 1.x 升到了 2.0。

这不是段子。Polars 作者 Ritchie Vink 在发布说明里用一句话交代了这次变更：LazyFrame.collect() 现在默认使用流式引擎，带来『大规模的内存和性能收益』。但性能收益的另一面写在了 TL;DR 里：对 join、group_by 和 unpivot 三类操作，除非你显式设置 maintain_order，否则不再保证输入行序。

素材作者自己做了验证：在 polars 2.0.0 上跑一个 200 万行的 inner join，默认配置下返回结果就是乱序的；给 join 设置 maintain_order 之后，输入顺序被保留。一乱一稳，边界清清楚楚。

产业逻辑很简单：默认值就是 API 的一部分。绝大多数用户不会读完整发布说明，他们默认『升级是安全的』。引擎作者有权改默认值，但改动的代价不会消失，只会转移到下游每一个按行序写校验、写文件的工程师头上。

⚠️ 行序：一个没人写进文档的隐式依赖

金句先行：最危险的依赖，是那些你从未显式声明过的依赖。

行序就是典型。现实中依赖行序的写法太多了——代码里逐行比对新旧两张表的输出；上游写一个文件，下游按位置读回去；宽表转长表之后，靠行号对齐指标。这些写法在过去『碰巧』是对的，因为旧引擎的执行顺序稳定。而流式引擎为了并行和流水线化，天然不承诺顺序——你收到的行，取决于哪个线程先算完。

把风险和对策摊开看：

这次变更还有一个容易被忽略的细节：out-of-core 处理默认开启了。内存用到约 80% 就开始向磁盘溢写，默认磁盘预算是 64 GB。这意味着引擎的行为模型变了——过去你担心的是内存够不够，现在你还要关心磁盘预算够不够、溢写盘的 IO 是不是瓶颈。据多位做过迁移的工程师私下讲，很多人的第一反应是先回滚版本，第二反应才是回头排查到底哪里乱了序——先止血，再治本，这本身就是对『默认值即契约』的最好注脚。

📊 基准测试的脚注里，藏着厂商的门道

性能数字要看，脚注更要看。

这次发布说明里附了基准测试，但有两个前提值得点名：第一，这是厂商自己的运行结果；第二，脚注明确写了，结果不可与官方 TPC 结果类比。也就是说，这是 Polars 在自己选的场景、自己的调优下的成绩单，和你在生产数据、生产集群上跑出来的数字之间，可能隔着一条河。

「大规模的内存和性能收益」这句话大概率是真的——流式引擎加 out-of-core，对超内存数据集的收益是结构性的。但『真』和『对你真』是两回事。数据基础设施领域的买家最该建立的纪律是：厂商基准只当筛选器，不当决策依据。把发布说明里的查询搬到自己的数据上重跑一遍，成本可能就是一个下午，但它能避免一次以月计的错误选型。

从这个定位看，Polars 的野心很清楚：守住单机易用性的同时，用流式引擎和 out-of-core 向上够到原本属于 Spark 的一部分中小规模分布式场景。这是一条很聪明的路线——不正面攻集群生态，而是把『单机+磁盘』的天花板抬高。

🧭 流式加落盘，DataFrame 引擎绕不开的下一站

把镜头拉远一点看，这次变更其实是整个 DataFrame 生态的一个转折信号。

过去几年，单机引擎阵营（pandas、DuckDB、Polars）与分布式阵营（Spark）的边界相对清晰：数据装得进内存就用前者，装不进就上后者。而 out-of-core 默认开启，意味着引擎自己在抹平这条边界——内存装不下？溢写到磁盘接着算，用户无感。这套思路本质上是把数据库几十年的工程积累搬进 DataFrame 引擎，代价则是行为语义必须重新定义，行序不保证只是其中一环。

换句话说，性能上的每一分激进，都要用语义上的明确来买单。流式引擎并行执行注定乱序，那就把『是否保序』变成用户必须显式声明的选项。这其实是好事——把隐式行为变成显式契约，长期看让系统更可预测。痛只痛在迁移那一刻：所有靠『碰巧有序』活着的代码，一次性暴露。

对整个赛道，我的判断是：中小规模数据场景会加速从重量级分布式方案回收到高性能单机引擎，而竞争的胜负手会从『跑分』转向『语义清晰度+迁移成本』。谁先把契约讲清楚、把升级做得不动声色，谁就能吃下那批被默认值变更吓过的用户。

✅ 升级不可怕，可怕的是默认值当空气

给工程团队的清单不该是情绪，而是动作：

再补三条纪律：锁定版本，升级永远走灰度，先在影子流量上验证；消灭位置语义，任何『按第 N 行』的逻辑都是定时炸弹，趁这次一起拆掉；把默认值变更当 breaking change 对待，哪怕官方把它归类为优化。

数据基础设施的成熟，从来不体现在跑分多漂亮，而体现在行为多可预期。默认值就是产品对世界许下的诺言，改诺言可以，但得大声说出来。

小结

Polars 2.0 用一个默认值改动，换来了流式引擎和 out-of-core 的性能上限，也把行序契约从隐式变成了显式。短期看，这是一次让无数管道红绿闪烁的迁移阵痛；长期看，这是 DataFrame 引擎向数据库工程标准靠拢的必经一步。对使用者的启示只有一句：别依赖任何没写进文档的行为——引擎会变，契约要握在自己手里。下一场竞争，比的不是谁更快，而是谁让用户升级得更安心。