Polars 2.0 リリース：主要機能とパフォーマンス改善のハイライト

本日、Polars 2.0 がリリースされました。前回の発表ではバージョンアップの背景について触れましたが、本稿では新たに追加された機能を解説します。当初大規模な新機能リリースを意図していませんでしたが、実際には多くの価値ある機能が搭載されており、期待以上の成果となりました。

リリースハイライト

• 非コア機能（ディスクへのダンプ/spill-to-disk）の初期実装有効化
• パフォーマンス面での大幅な改善
• SQL を第一級市民とする完全なサポート体制的确立
  • TPC-H および TPC-DS ベンチマークにおいて、DataFusion や DuckDB にて優位性を実証。
• 新しい Map データ型の実装
• データ型（dtypes）への厳格化と明確性の向上
  • フィードバックの高速化および AI 開発におけるイテレーション速度の向上を実現。

パフォーマンス向上と SQL の第一級市民としての位置づけ

Polars 2.0 は、SQL を**「第一級市民」**として扱う節目となります。過去数年間構築してきた堅牢なエンジン能力を、より広範なワークロード、とりわけ SQL ワークロード に適用します。高いパフォーマンスを実現するために、以下の改善が実装されました。

• クエリオプタイマーの改良
• 結合順序のリオーダー（Reordering）
• 非常に優れた共通サブプラン排除（Common-Subplan-Elimination）
• 動的プリディケートおよびブルームフィルタの採用

ベンチマーク結果と環境

TPC-H および TPC-DS から派生したデータセットを用い、最新の DuckDB リリースおよび DataFusion と対比させました。

• 評価環境:

  c7a.4xlarge

  (16 コア vCPU, 32GB RAM) および

  c7a.metal

  (192 コア vCPU, 384GB RAM)
• 実行設定:
  • 熱い設定（hot setting）下での 5 回実行
  • 各クエリごとに独立したプロセス起動
  • タイムアウト値: 60 秒
  • エンジン切り替え時のファイルキャッシュクリアは行いましたが、クエリ間の再読み込みは行いません。
  • 評価指標: 最速の実行時間、総和時間、幾何平均。
• データ生成:

  tpcgen-cli

  (コミット 99bedae) を使用。デフォルトの行グループサイズで確認。

主要な所見

• Polars: 例外を除き、すべてのベンチマークにおいて最速のパフォーマンスを発揮しました。
• DuckDB と DataFusion: 比較対象として機能し、特定の条件下で Polars が優位でした。
  • DataFusion は TPC-DS クエリ q72/q67 でタイムアウト。TPC-H クエリ q18 ではメモリ不足となりました（除外）。

注意点:

• スケーリングに際して Polars は一定のオーバーヘッドがあり、データ量が少ないクエリの性能を低下させる傾向があります。
• 32 コア制限下では、あらゆるベンチマークで競争力があり、場合によっては他エンジンを上回っています（この原因は特定済みで、次リリースでの修正予定）。
• 詳細は ベンチマーク用リポジトリ を参照してください。

ストリーミングエンジンと OOC（Out-of-Core）をデフォルト設定へ

これは Polars 2.0 の最も大きな影響を与える変更の一つです。

1. ストリーミングエングンのデフォルト採用

LazyFrame に

collect()

• 背景: ストリーミングエンジンは特定の操作（結合、グループ化、転置など）に対してデフォルトで行順序を保証しないためです。
• 対応策: 明確な行順序が必要な場合は、明示的に

  maintain_order=True

  を設定します。

2. 非コア機能（Spill to Disk）のデフォルト有効化

RAM 使用率が約 80% に達した時点でディスクへのダンプ（spill）を開始し、メモリ不足を防ぎます。

• 初期実装: ソート、ウィンドウ関数、多数の式などに対応。
• デフォルト割り当て予算: 64GB
• 今後の予定: 結合およびグループ化操作への非コア機能実装も予定されています。

これにより、Polars は高メモリ使用ワークロードにおける耐障害性が格段に向上します。

新しい Map データ型

Arrow の

MapType

Map dtype

データ型の読み込み

2.0 以前には List of Struct として扱われていましたが、今や正式なデータ型として扱われます。

import polars as pl

df = pl.DataFrame(
    {
        "user": ["alice", "bob", "carol"],
        "scores": pl.Series(
            [{"math": 90, "art": 75}, {"math": 60}, {}],
            dtype=pl.Map(pl.String, pl.Int64),
        ),
        "subject": ["art", "art", "math"],
    }
)

クイックな辞書的操作

Map タイプは専用の式（Expression）をサポートします。固定キーの検索、値への反復処理、キー/値の抽出が可能です。

df.select(
    "user",
    pl.col("scores").map.get("math").alias("math"),                # 固定されたキー
    pl.col("scores").map.get(pl.col("subject")).alias("by_subject"),  # 別の列からキーを取得
    pl.col("scores").map.contains_key("art").alias("has_art"),
    pl.col("scores").map.len().alias("n"),
    pl.col("scores").map.keys().alias("keys"),
    pl.col("scores").map.values().alias("values"),
)

より厳格な Polars (Strict Mode)

Polars はエラーを早期に検出・失敗させることを重視しています。暗黙的な動作によるデータ不整合はデフォルトではなくオプションとして設定されます。

厳格化のメリット

• AI 開発の高速化: エージェントや人間が

  collect_schema()

  を呼び出し、データを実際にロードする前に型解析を行いスキーマレベルの不整合を検出できます。
• フィードバック速度の向上: エラー発生時をパイプライン実行後ではなく、最初から即座に返すことで、イテレーション速度が向上します。

注意: すべてのエラーがコンパイル時に検出できるわけではありません（データ依存型）。そのため、不整合を検出することを目的とした厳格な動作をデフォルトとしています。

今後の展望とまとめ

Polars 2.0 のリリースに大変興奮しております。今後数ヶ月間、以下のような改善を重ねてまいります。

• 非コア機能の更なる強化
• 大規模なコア数を有する環境でのスケーリング性能向上
  • Polars Cloud を「利用可能な最も高速な分散エンジン」へ進化させるため。
• GeoPolars の開発着手

アップグレードとバグ報告

新しいリリースに関連する問題を見つけた場合は、ぜひご報告ください。

• Issues: GitHub Issues
• 移行ガイド: 2.0 へのアップグレードをスムーズに行うためのガイドが公開されています。