Polars 2.0 のリリース

ブログに戻る Polars 2.0 のリリース Ritchie Vink 著 2026年10月6日（火） 本日、Polars 2.0 を出荷します。以前のアナウンスメント投稿では、バージョンアップの理由について説明しました。この記事では、2.0 がもたらす機能について詳しく説明します。大きな機能リリースを意図していませんでしたが、それでも熱狂するに十分な要素が詰まっています。このリリースのハイライトを見ていきましょう。アウト・オブ・コア（ディスクへのスピル）サポートの初期バージョンが有効化され、多くのコアパフォーマンス改善、ファーストクラスの SQL サポートが追加されました。これらはパフォーマンス改善と相まって、Polars を TPC-H および TPC-DS1 ベンチマークで DataFusion と DuckDB よりリードさせています。新しい Map データ型、そして dtypes と明示性に対するより厳格な Polars により、より迅速なフィードバックと、より速い AI イテレーションが可能になります。 パフォーマンスと SQL をファーストクラスの市民として Polars 2.0 は、SQL をファーストクラスの市民として扱う際の基準点となります。Polars SQL のカバレッジは、過去数ヶ月で劇的に増加しました。私たちは過去数年間、堅牢なエンジンを構築してきたことを知っています。Polars 2.0 では、SQL を含むより多くのワークロードに対応できるようにしたいと考えています。これを高性能にするために、オプティマイザとエンジンの多くの改善をリリースしました。ここでのハイライトは、ジョインの並べ替え、共通サブプラン除去の改善、動的述語/ブルームフィルターです。典型的な SQL ベンチマークでの性能を確認するために、Polars SQL を TPC-H および TPC-DS1 から派生したデータで実行し、最新の DuckDB リリース（1.5.6）、DuckDB 2.0 アルファ（2.0.0.dev2610011535）、および最新の DataFusion リリース（54.0.0）と比較しました。テストは c7a.4xlarge（16 vCPU、32GB RAM）および c7a.metal（192 vCPU、384GB RAM）で行いました。各クエリはホット設定で5回実行し、クエリごとに個別のプロセスを使用し、60秒のタイムアウトを設定しました。ファイルキャッシュは、各エンジン/ベンチマーク間でクリアしました（クエリ間ではクリアしません）。各クエリで5回の実行のうち最良の結果を採用し、合計時間と幾何平均の両方でエンジンを比較しました。データは tpcgen-cli parquet から生成され、ソースはコミット 99bedae からコンパイルされました。tpcgen-cli のデフォルトの行グループサイズを確認し、Polars scan_csv を sink_parquet にパイプしたものや Duckdb COPY が生成するものとおおよそ同等であることを確認しました。SQL クエリは DuckDB 1.5.6 の tpch_queries() および tpcds_queries() を使用して生成されました。データは EBS に保存されました。以下のチャートは、各エンジンでの実行時間（秒、小さい方が良い）をマシン別に示しています。 c7a.4xlarge（16 vCPU、32 GB） c7a.metal（192 vCPU、384 GB） Polars と両方の DuckDB バージョンは、すべてのクエリを完了しました。DataFusion は TPC-DS q72（および一度 q67）でタイムアウトし、c7a.4xlarge の TPC-H q18 でメモリ不足になりました。これらのクエリは、上記のすべてのエンジンの結果から除外されています。デフォルトの Polars は、1つのベンチマークを除き、すべてのベンチマークで最速であることが観察されました。Polars は、192スレッドにスケールする際に一定のオーバーヘッドがあり、これは小規模データクエリのパフォーマンスを低下させます。実際、Polars を32コアに制限すると、すべてのベンチマークで競争力があるか、あるいは勝利することがわかっています。この問題の原因は特定されており、次のリリースで修正されることを期待しています。ベンチマークに関する詳細は付録を参照してください。結果を再現することを推奨します。ベンチマーク用のリポジトリはこちらで共有しています: https://github.com/pola-rs/polars-2.0-benchmark。 ストリーミングエンジンと OOC をデフォルトに これは 2.0 における最も影響の大きい変更の1つです。LazyFrame に対して collect を呼び出すと、デフォルトでストリーミングエンジンが使用されるようになり、ほとんどのクエリでメモリ使用量とパフォーマンスが大幅に改善されます。メジャーバージョンアップが必要だった理由は、ストリーミングエンジンが、特定の操作（join, group_by, unpivot など）において、デフォルトでは行順序を保証しないためです。これらの操作で観測可能な行順序が必要な場合は、maintain_order=True を設定することでオプトインできます。アウト・オブ・コア（ディスクへのスピル）がデフォルトで有効になりました。RAM の約80%でスピルを開始します（調整が必要になる場合があります）。現在アウト・オブ・コアをサポートしている操作（sort, window functions, 多くの式）は、クエリを完了するためにディスクへのスピルを開始できるようになりました。デフォルトのディスクバジェットは 64GB です。今後、join や group_by に対してもアウト・オブ・コアを有効にする予定です。これらの2つの変更により、カジュアルなデータプラクティショナーにとって、Polars は高メモリワークロードにおいて、より回復力のあるものになります。そして、アウト・オブ・コア join および group_by がロードマップにあるため、この回復力はさらに向上するでしょう。 新しい Map データ型 Polars は、Arrow MapType を Polars Map データ型として直接サポートするようになりました。Map は Python の辞書のようなもので、キーを値にマッピングします。2.0 より前は、Arrow MapType は Polars では List(Struct({