あなたのコードの基盤となるエンジンが入れ替わりました
Polars 2.0は、基本的かつ目に見えにくい変化を実装しました。デフォルトのクエリエンジンが置き換えられたのです。コードを修正しなくても、既存のクエリは従来のインメモリシステムから新しいストリーミングエンジン上で実行されるようになります。このコアアーキテクチャの変更は、アップグレードした瞬間にすべてのPolarsユーザーに影響を与えます。
以前のインメモリエンジンは倉庫のように機能しており、処理を開始する前にデータセット全体をRAMに読み込む必要がありました。クエリの各ステップは、完全に読み込まれたデータに対して実行されていました。この方法はデータセット全体が利用可能なメモリに収まる場合にのみ高速であり、大規模な操作におけるスケーラビリティを制限していました。
新しいストリーミングエンジンは、組み立てラインのような異なるパラダイムを採用しています。データをCPUのキャッシュに収まるように最適化された小さなmorsels（断片）に分割します。これらのmorselsはクエリプランに従って順次処理されますが、そこには決定的な違いがあります。
このパイプライン化されたチャンクベースのアプローチこそが、大幅な速度向上の直接的な要因です。クエリの異なる部分が別々のmorselsに対して同時に実行できるようになり、あるステップがデータセット全体の処理を待たなければならないという以前のボトルネックが解消されました。この並行処理（concurrency）によりデータフローが効率化され、効率的で継続的な処理ラインを実現することで、複雑な操作が大幅に高速化されます。エンジンの変更は、データを局所化し移動させ続けることでCPU使用率を最大化することを目的としています。
速度の代償：データの順序が崩れる
新しいストリーミングエンジンにおける並列処理には、大きな代償が伴います。それは行の順序が保証されなくなったことです。結合（join）、グループ化（group-by）、アンピボット（unpivot）などの操作では、入力時とは異なる順序で行が返される可能性があります。この動作は、組み立てラインの作業員のように、複数のタスクが独立して完了するエンジンのデータ「morsels」の並列処理を反映したものです。
この変更は、サイレント障害を引き起こす可能性があるため、Polars 2.0における最も危険な変更です。コードはクラッシュせず、計算された数値も算術的には正しいままかもしれません。しかし、後続のプロセスが入力行の順序に暗黙的に依存している場合、データが誤ったエンティティに紐付けられ、エラーを生成することなく分析結果が破損する可能性があります。このような問題は、明示的な例外よりもはるかに検出が困難です。
順序付けには明示的な意図が必須となりました。操作で特定の行順序が必要な場合は、Polarsに直接指示する必要があります。例えば、結合操作では左側の順序を維持するために maintain_order='left' を指定できるようになりました。この設計は、暗黙的な利便性を明示的な正確性と引き換えにするものであり、開発者に順序付けの要件を宣言するよう強制します。
Polars 2.0はデータ順序に対する宣言的なアプローチを強制し、データ破損につながる可能性のある前提を防ぎます。explain() 関数でクエリの背後にある動作を明らかにすることはできますが、開発者は順序付けの影響を積極的に調査しなければなりません。この変更は、過去の暗黙的な保証よりもパフォーマンスと堅牢なデータ整合性を優先し、データパイプラインの透明性を高めるという決意を強調しています。
意図的に破壊をもたらす「退屈な」リリース
Polars 2.0には、主要な新機能は一切含まれていません。その代わり、ライブラリの内部基盤を強化するクリーンアップリリースとしての役割を果たします。このバージョンは意図的に破壊的な変更を導入しており、マイナーアップデートにおける後方互換性よりも、長期的な一貫性とアーキテクチャの堅牢性を優先しています。
多数のメソッドが名称変更または削除されました。主な変更点は以下の通りです：
meltはunpivotに変更read_csvはscan_csv().collect()に変更LazyFrame.profile()は削除join_nullsはnulls_equalに変更- 整数からカテゴリカル型への直接キャストには
cat.to()が必要 concatは、ユーザーの意図を推測するのではなく、高さが一致しない場合にエラーを返すように変更
Polarsは、これらの変更に対して役立つ AttributeRemovedError を発行します。このエラーは、使用すべき新しい関数やメソッドを明示的に詳細に説明し、ユーザーの移行をガイドします。
この哲学は、曖昧さや潜在的な問題をランタイムまで持ち越すことが多い Pandas のアプローチとは対照的です。Polarsはエラーを早期に検出し、実行前にコードの予測可能性と堅牢性を高めることを目指しています。これらの破壊的変更は、非常に詳細なエラーメッセージと組み合わされており、Polarsの予防的設計戦略の中核を成しています。
この記事が気に入ったら、毎朝同じようなものをメールで受け取れます。
1日1通 · 2クリックで解除 · サードパーティのトラッキングなし
結論：今すぐアップグレードすべきか、待つべきか、それとも監査すべきか？
新しい streaming engine による5倍の高速化というPolarsの主張は期待値であり、普遍的なベンチマークではありません。このエンジンは基盤となるものですが、まだ真のアウト・オブ・コア処理を提供するものではなく、データは依然としてRAM内に収まる必要があります。2.0リリースは、将来的にメモリサイズを超えるデータセットを扱えるようにするための準備段階です。
現在、Polars 2.0は release candidate であり、インストールには --pre フラグが必要です。このバージョンはまだ安定しておらず、group_by_dynamic がストリーミングエンジン上で日時範囲外エラーを引き起こすという優先度の高い問題などのバグが存在します。さらに、str.to_datetime は例外を発生させる代わりにnullを返すようになり、limit メソッドは結合後に早期終了しなくなりました。
新規プロジェクトでは、最初から更新されたAPIを採用するためにPolars 2.0の利用を検討すべきです。既存のコードベースに対しては、無計画なアップグレードは推奨されません。開発者は、結合やグループ化など、暗黙的に row order に依存している操作がないかコードを監査する必要があります。データの整合性を確保し、サイレントなデータ破損を防ぐために、明示的にソートを追加するか、maintain_order フラグを使用してください。
よくある質問
Polars 2.0における最大の変更点は何ですか？
デフォルトのクエリエンジンが新しい「ストリーミング」エンジンに変更されました。このエンジンはデータを小さな並列チャンクで処理することで大幅なパフォーマンス向上を実現しますが、トレードオフとして、デフォルトでは元の行順序を保証しなくなりました。
なぜPolars 2.0で行順序が変わるのですか？
新しいストリーミングエンジンは、データチャンク（「morsels」）に対する操作を並列化します。速度を最大化するために、これらのチャンクを元の順序で再構成するのを待機しません。今後は maintain_order=True などのパラメータを使用して、順序の保持を明示的に要求する必要があります。
Polars 2.0は本当に5倍速いのですか？
「5倍高速」という数値はPolarsチームの期待値であり、保証されたベンチマークではありません。新しいエンジンは明らかに高速ですが、実際のパフォーマンス向上はハードウェア、データセット、実行する特定の操作によって異なります。
Polars 2.0における「ストリーミング」とはどういう意味ですか？
現在、「ストリーミング」とは、CPUキャッシュに合わせてサイズ調整されたデータ断片を処理する、チャンク化およびパイプライン化された実行モデルを指します。これは、データセットがマシンのRAMより大きくても処理できる、真のアウト・オブ・コア処理を意味するものではありません。
Polars 2.0は本番環境で使用しても安全ですか？
初期の2.0バージョンはリリース候補版です。大幅な挙動の変化（行順序など）やいくつかの既知のバグを考慮すると、重要な本番環境にデプロイする前に、既存のコードベースを徹底的に監査し、安定版のリリースを待つのが賢明です。