Polars 2.0はあなたのコードを破壊します

Polars 2.0には新機能が一切含まれておらず、このリリースは重要なクリーンアップとアーキテクチャの刷新として位置づけられています。開発者はこれを機能アップデートではなく、内部の一貫性と堅牢性を高めるための基盤的な取り組みと説明しています。このアップデートは長期的な安定性を目指しており、ユーザー向けの新しい機能がないにもかかわらず、既存のコードの動作を根本的に変更します。

最も影響の大きい変更は、すべての LazyFrame クエリに新しいデフォルトの streaming engine が導入されたことです。このエンジンは、データを morsels と呼ばれる小さな並列チャンクで処理することで、パフォーマンスとメモリ効率を大幅に向上させます。初期評価では、この新しいパラダイムの下で集計クエリの実行が「容易に5倍高速化」されると予測されており、データセット全体を同時にRAMに読み込むことを避けることでメモリフットプリントを大幅に削減します。

この基盤的なアップデートは、Polarsの野心的な未来にとって不可欠です。新しいストリーミングエンジンは、真のout-of-core処理を実現するための重要な土台を築き、ライブラリが利用可能なシステムメモリを超えるデータセットを効率的に処理できるようにします。また、より強力で洗練されたクエリ最適化への道を開き、Polarsの分析能力とスケーラビリティをさらに強化します。

Polars 2.0では、既存のコードを直接破壊する明示的なAPI変更が導入されています。このアップデートは機能リリースではなく、特定の関数において後方互換性よりも長期的なアーキテクチャの一貫性を優先しています。開発者は、以前のメソッドがその名前で機能しなくなるため、即座にエラーに遭遇することになります。

いくつかのコア関数が名前変更または削除されました。melt メソッドは unpivot になりました。これは、ワイド型からロング型へのデータ整形において、より直感的であると判断されたためです。join_nulls は結合操作の明確化のために nulls_equal に改名されました。さらに、LazyFrame.profile は利用できなくなりました。

これらの変更は、最適化された遅延実行とより厳格なデータ処理への移行を反映しています。例えば、read_csv は内部的に scan_csv().collect() を活用するようになり、自動的な遅延最適化を提供します。符号付きおよび符号なしの64ビット整数を組み合わせると Int128 型が生成されるようになり、以前は浮動小数点数へのキャストによって発生していた静かな精度低下を防ぎます。

移行は改善されたエラーハンドリングによって効率化されています。削除された関数は AttributeRemovedError をスローし、代替メソッドを明示的に詳細に伝えます。この開発者に優しいアプローチにより、melt の呼び出しに対して直接 unpivot の使用が提案されるため、的を絞った修正が可能になり、ダウンタイムを最小限に抑えることができます。

Polars 2.0では、すべての LazyFrame クエリに対してデフォルトの streaming engine が導入されました。これには join、group_by、unpivot などの操作において行の順序を保証しないという性質があります。大幅なパフォーマンスとメモリ効率の向上を目的としたこの根本的なアーキテクチャの変更により、データはより小さな並列チャンクで処理されます。これにより、出力される行の順序が微妙に変わる可能性があり、既存のコードにとっては静かな破壊的変更となります。

この移行には重大なリスクが伴います。出力データは数値的には正しくても、誤った行に静かに紐付けられている可能性があるということです。このような不一致は、検出やデバッグが極めて困難な微妙なデータ破損につながり、後続の分析を損なう可能性があります。明示的なAPI変更とは異なり、この問題は即座にエラーを引き起こさないため、危険な罠となります。

特定の行順序を必要とするユーザーは、影響を受ける操作に対して明示的に maintain_order=True を設定する必要があります。この義務付けは、Polarsの開発者によって「良い破壊的変更」と位置付けられており、以前のエンジンの付随的な行保持に頼るのではなく、ユーザーにデータの正確性を定義させることを強制するものです。Polars 2.0の変更に関する詳細については、Version 2.0-rc - Polars user guide をお読みください。

Polars 2.0は、大規模なシングルマシンでのデータワークロード向けに特別に設計された、RustベースのPandasの高性能な代替品としての地位を強化しています。今回のリリースにはユーザー向けの新しい機能は含まれていませんが、長期的な安定性、メモリ効率、パフォーマンスに焦点を当てた重要なアーキテクチャのオーバーホールです。これは、処理速度とリソース管理が極めて重要なデータサイエンスやAIアプリケーションに不可欠な、基盤となるエンジンのメカニズムとAPIの一貫性に対処するものです。

この内部的なクリーンアップは、将来のデータ処理やAIモデルのトレーニングに不可欠な高度な機能への道を直接切り開くものです。今後の開発には、複雑なクエリ実行プランをインテリジェントに最適化するように設計された cost-based planner や、複雑なデータ結合のパフォーマンスを向上させる強化された join reordering アルゴリズムが含まれます。これらのアーキテクチャの改善は、SQLカバレッジの大幅な拡大と相まって、Polarsがより効率的かつ確実に洗練された分析課題に取り組むことを可能にし、データ準備におけるボトルネックを削減します。

開発者は、この「退屈な」アップデートを、目先の派手な機能よりも堅牢性を優先した、基盤強化への戦略的投資と捉えています。データをより小さな並列チャンク（morsels）で処理する新しいデフォルトの streaming engine は、ほとんどのクエリを合計で「簡単に5倍高速化」すると予測されています。Polars 2.0は、そのコアアーキテクチャを強固にするための意図的な動きであり、一貫した高スループットのデータ操作を必要とするAIや機械学習パイプラインの進化するニーズをサポートできる、より高速で堅牢なデータ処理の未来を確実にします。

なぜPolars 2.0は新機能がないのに「破壊的」なリリースなのですか？

Polars 2.0は、内部アーキテクチャとAPIの一貫性に焦点を当てた「クリーンアップ」リリースです。新しいデフォルトのクエリエンジンを導入し、いくつかのメソッドの名前を変更したため、既存のコードが動作しなくなる可能性がありますが、これらの変更は将来の開発のためのより堅牢な基盤を築くものです。

Polars 2.0における最も重要な変更は何ですか？

最も重要な変更は、新しいデフォルトの「ストリーミングエンジン」が、結合やグループ化などの操作において行の順序を保証しないことです。ユーザーは、データ整合性の問題を未然に防ぐために、明示的に maintain_order=True を設定する必要があります。

Polars 2.0にアップグレードした後、コードを修正するにはどうすればよいですか？

ほとんどの破壊的変更は AttributeRemovedError を引き起こし、代わりに何を使用すべきかを正確に伝えます（例：melt を unpivot に置き換える）。潜在的なサイレントエラーについては、行の順序が重要となるコードをすべて見直し、maintain_order=True を追加してください。

Polars 2.0は以前のバージョンよりも高速ですか？

はい。データを並列チャンクで処理する新しいデフォルトのストリーミングエンジンのおかげで、ほとんどのクエリは大幅に高速化されると予想されており、全体的なパフォーマンス向上は約5倍と推定されています。

Polars 2.0はRAMを超えるデータセットをサポートしていますか？

まだ完全ではありません。ストリーミングエンジンは真のアウトオブコア処理に向けた基礎的なステップですが、現在の実装では依然としてデータセットがメモリに収まる必要があります。完全なアウトオブコアサポートは、将来のリリースで計画されています。