Polars 2.0、コア外処理と高速なSQLクエリを実現
Polars 2.0はデフォルトでディスクへのスワップ(spill-to-disk)処理を有効にし、SQLベンチマークでDuckDBを上回る性能を発揮。AIワークフロー向けにより厳格な型安全性を提供します。
英語の原文から自動翻訳されました。
Polarsチームはデータ処理ライブラリのバージョン2.0をリリースしました。これは、エンジンがメモリおよびSQLワークロードをどのように扱うかにおける大きな転換点となります。2026年10月6日に公開されたこのメジャーアップデートでは、コア外処理(out-of-core processing)がデフォルト機能として導入され、DuckDBやDataFusionなどの競合製品との標準SQLベンチマークにおいてPolarsがトップクラスの性能を持つことを示しています。
何が起きたのか
今回のリリースは、新機能の追加よりも、耐障害性とパフォーマンスに焦点を当てています。最も影響の大きい変更点は、LazyFrameに対するcollect呼び出しが、デフォルトでストリーミングエンジンを使用するようになったことです。この変更により、Polarsは利用可能なRAMを超えるデータセットを扱えるようになり、一時データをディスクへスワップできるようになります。システムは、メモリ使用量が利用可能RAMの約80%に達した時点でディスクへのスワップを開始し、デフォルトのディスク予算は64GBです。現在、ソート、ウィンドウ関数、多くの式がこのコア外動作に対応しており、ジョインやグループ化操作は今後のアップデートで対応予定です。
ストリーミングエンジンはjoin、group_by、unpivotなどの操作において行順を保証しないため、この変更にはメジャーバージョンアップが必要でした。特定の行順に依存しているユーザーは、今後明示的にmaintain_order=Trueを設定する必要があります。このデフォルト動作は、高メモリ負荷のワークロードに取り組むカジュアルなデータ実務者にとってPolarsをより堅牢なものにする目的があり、以前は物理メモリの制限を超えたデータセットで発生していたクラッシュを防ぎます。
メモリ管理に加え、Polars 2.0ではSQLを第一級市民(first-class citizen)として扱います。ライブラリはSQLカバレッジを大幅に拡大し、より優れたジョイン順序付け、共通サブプランの削除、動的述語によってオプティマイザを改善しました。これらの強化により、Polarsは複雑なSQLクエリをより効率的に実行でき、プログラムによるデータ操作と従来のデータベースインタラクション間のギャップを埋めます。
仕組み
SQL実行におけるパフォーマンス向上は、クエリエンジンの深い最適化から生まれています。Polarsは現在、ブルームフィルタと動的述語を活用して、クエリ実行中に処理されるデータ量を削減しています。共通サブプランの削除と効果的なジョイン順序付けにより、エンジンは冗長な計算を最小限に抑えます。これらの技術的改善により、Polarsは確立された分析データベースと直接競合することが可能になりました。
これらの主張を検証するため、チームはAWS c7aインスタンス上でTPC-HおよびTPC-DS由来のデータを使用してベンチマークを実行しました。PolarsをDuckDB 1.5.6、DuckDB 2.0 alpha、DataFusion 54.0.0と比較しています。テストでは、各クエリをホット設定で5回実行し、エンジン間でファイルキャッシュをクリアした後、最良の実行時間を採用しました。結果は、16-vCPUおよび192-vCPUのマシン両方において、ほぼすべてのベンチマークでPolarsが最速のエンジンであることを示しましたが、192スレッドにスケールした際の小規模データクエリではいくつかのオーバーヘッドが見られました。
主要な詳細
- コア外処理はデフォルトで有効になっており、RAM使用量の約80%でディスクへスワップし、デフォルトのディスク予算は64GBです。
- ストリーミングエンジンが
collectのデフォルトになりました。これにより、maintain_order=Trueを設定しない限り、行順が変わる可能性があります。 - Polarsはc7a.4xlargeおよびc7a.metalインスタンスでのTPC-HおよびTPC-DS1ベンチマークにおいて、DuckDBとDataFusionをリードしました。
- 新しい
MapdtypeはArrowMapTypeを直接サポートし、辞書のようなキー検索とイテレーションを可能にします。 - より厳格な型チェックと
collect_schema()により、AIエージェントと開発者のフィードバックループが高速化されます。 - DataFusionはいくつかのクエリでタイムアウトまたはメモリ不足が発生しましたが、PolarsとDuckDBは正常に完了しました。
なぜ重要なのか
ソフトウェアエンジニアやデータサイエンティストにとって、デフォルトのコア外サポートは、大規模データセット処理時の信頼性向上を意味します。従来は、メモリ制限を超えるとプロセスがクラッシュし、手動でのチャンク分割や外部ツールが必要でした。しかし今では、Polarsはディスクスペースを利用することで、メモリを超えるワークロードを優雅に処理できるようになり、広範なインフラ調整なしで堅牢なデータパイプラインを構築しやすくなります。これは、複雑な分散システムを管理するための専用のデータエンジニアリングリソースを持たないチームにとって特に価値があります。
より厳格な型システムとスキーマ検証は、AI駆動の開発における増大するニーズにも対応しています。開発者がコード生成のためにAIエージェントを使用するケースが増えている中、早期のエラー検出が極めて重要になっています。collect_schema()を通じてスキーマ不一致に対して迅速に失敗させることで、Polarsはエージェントと人間がより速く反復できるように支援します。これにより、パイプラインの深層にあるサイレントな失敗や誤ったデータ型のデバッグにかかる時間が短縮され、より保守的で正確なデータ処理コードにつながります。
できること
- Polars 2.0にアップグレードし、破壊的変更に対処するためにチームが提供する移行ガイドを確認してください。
- 既存のパイプラインで行順依存性をテストし、必要に応じて
maintain_order=Trueを追加してください。 - ネストされたキー・バリューデータ構造をより効率的に処理するために、新しい
Mapdtypeを試してください。 - SQLクエリをPolars内で直接実行し、改善されたオプティマイザを活用して、現在のスタックとのパフォーマンスを比較してください。
- 重いデータ操作を実行する前に型エラーを検出するために、開発ワークフローで
collect_schema()を使用してください。 - メモリ使用量を監視し、ワークロードが異なるリソース割り当てを必要とする場合は、ディスクへのスワップ閾値を調整してください。



