Polars 2.0

原文 ↗ Hacker News 讨论 ↗

Polars 2.0 是一个基于 Rust 的 dataframe 引擎，被认为是一次重大升级：它加入了一级 SQL 支持，改进了分析型基准测试中的性能，并引入了更好的扩展能力和外存处理能力。许多用户报告从 pandas 甚至 Spark 风格流水线迁移到 Polars（通常与 DuckDB 搭配使用），原因包括更简洁的 API、在大数据集上的速度，以及适合从量化交易到天气分析等生产工作负载。同时，评论者也指出地理空间工具仍不成熟，并提醒应将与 DuckDB 和 DataFusion 的基准结果视为具有参考性的优化表现，而非绝对性能排名。

发布时机与定位

  • 一些人注意到它与 DuckDB 即将到来的 2.0 版本巧合；Polars 贡献者表示 2.0 早已规划多年，分支上的工作自 2026 年中期就已开始。
  • 若干评论将 Polars 2.0 视为与 DuckDB 和 DataFusion 的直接竞争，尤其是在 SQL 支持以及 TPC-H/TPC-DS 基准方面。

性能、流式处理与基准测试

  • 多位用户报告相比 pandas 有大幅提速；有一位提到“10 亿行”基准测试，其中 Polars 和 DuckDB 比 pandas 快约 50 倍。
  • 流式/外存支持被强调为一项重大改进，解决了 pandas/polars 以前会耗尽内存的场景。
  • Polars 维护者承认在极高核心数（例如 192 线程）下，由于 join 分区带来的开销存在问题，并计划进一步优化。
  • 有人报告 DataFusion 在他们的工作负载上胜过 Polars；另一些人则发现 DuckDB 比两者都慢。
  • 基准测试专家警告不要把厂商基准当作绝对排名；TPC-H/DS 很有用，但并不能完全代表现代，尤其是半结构化工作负载。

Polars vs Pandas vs DuckDB（以及其他）

  • 许多人认为 Polars 在“99.9%”的情况下几乎可以直接替代 pandas，并且性能更好、可扩展性更强、API 也更简洁。
  • 也指出了一些缺口：地理空间（GeoPandas 已经很成熟；GeoPolars 仍处于早期阶段）、某些逐行/原地操作，以及更丰富的生态/互操作性（绘图、统计）。
  • DuckDB 因其以 SQL 为中心的工作流、低内存占用、地理空间扩展，以及作为进程内分析数据库的能力而受到称赞。
  • 有些人偏好用 SQL/DuckDB 做复杂清洗（一条查询胜过多行 dataframe 代码），而另一些人更喜欢 Polars 的 dataframe API 而不是 SQL。

特性、SQL 与缺失项

  • Polars 的 SQL 支持被视为一大进步；不过，某些操作（例如 asof_join）虽然在核心 API 中已有，但通过 SQL 仍不可用。
  • 有人提出对时间戳精度的疑问；另一位评论者表示，只要指定 schema，纳秒级 Datetime("ns") 是可用的。
  • 对字符串拼接笨拙的最初抱怨，被一些示例反驳，说明可以使用类似 Pandas 的语法。

生态、互操作性与使用场景

  • Narwhals 被提及为一个与 dataframe 无关的层，可抽象覆盖 pandas/polars 等。
  • 团队报告从 pandas/R 栈迁移到 Polars + DuckDB。
  • 真实使用场景包括量化交易机器人、大规模包裹数据处理，以及预计算数十亿条天气评分。

担忧：内存、线程与易用性

  • 一些人因重度多线程而经历更高的内存使用和 OOM；降低 POLARS_MAX_THREADS 有时能同时提升稳定性和速度。
  • 少数评论者仍在小型、科学导向的工作流中坚持使用 pandas，因为下游库期望 pandas/NumPy。