pandasはPolarsに 性能面で追いつき 追い越せるのか エムスリー株式会社 VPoE 河合 俊典

発売おめでとう🎉

Polarsが高速でメモリ効率が良いとされている理由 ● Apache Arrow ● ゼロコピー ● 遅延評価 まずはこの３つから追ってみよう

列指向フォーマットを簡単おさらい id name date 1 kawai 2021/01/01 2 onodera 2022/01/01 id name date 1 kawai 2021/01/01 2 onodera 2022/01/01 行指向フォーマット 行単位操作を行うOLTPな DBで使うとつよい 列指向フォーマット 特定列の集計などでつよい 列で見るとカーディナリティが 低くなりやすく圧縮効率も良い キャッシュに乗りやすい SIMD処理にも優しい 列指向な考え方は Parquet、Feather、BigQuery など応用先が多い その中で色んな言語やフレーム ワークの共通実装作ろうぜと 颯爽と出てきたのが ”Apache Arrow”

Apache Arrowとpandas/Polarsを取り巻く環境 pandas 2.0から利用可能 Apacheが提供する 公式bindingsのpyarrow経由 polars-arrowを自前実装 カリカリチューニング 例えば 所有権でメモリ管理するRustでは arrow側strがclone必須な状況があり得るので 参照カウンタを見る疑似GCを自前実装 +SIMD +並列化 ❗ ❓ → polars-rsで”perf”から始まるパフォーマンス改善PRはどれも面白いのでオススメ

pandasとApache Arrow pandas 3.0からpyarrowがstring columnに対してのみデフォルトになります🎉 や、やったか…！？ numpyはstringが苦手なので極端に改善出来るdtype 他にもいくつかのメリットがある（後述） pandas roadmapを見る限りApache Arrow化が進む事はほぼ確実

Polarsが高速でメモリ効率が良いとされている理由 ● Apache Arrow ○ Apache Arrowは凄いがPolarsはその扱い方も凄い ■ RustなApache Arrow自前実装wrapperをカリカリチューニング ■ SIMDや並列化を使った高速化を標準とした実装 ○ Apache Arrow自体はpandasも扱えるしデフォルトになっていく ● ゼロコピー ● 遅延評価

copyとviewの概念を簡単おさらい id name date 1 kawai 2021/01/01 2 onodera 2022/01/01 3 Johann 2023/01/01 View df1 df2 id name date 1 kawai 2021/01/01 2 onodera 2022/01/01 3 Johann 2023/01/01 Copy df1 df2 id name date 1 kawai 2021/01/01 2 onodera 2022/01/01 当然Copyの方がメモリを使うことになる

ゼロコピーを簡単におさらい じゃあ全部viewで良いかというと難しい 以下のような場合は初見の書き手としてはcopyされていて欲しい気もする 1つの処理でcopyとwriteが出来るからこそpandasらしい書き方ができる メソッドチェーン強制で コピーが極力発生しない世界観を実現 そりゃメモリ効率は良いわな

ゼロコピーとpandasを取り巻く環境 pandas 3.0からCopy-on-Write原則が導入されます🎉 以下の書き方はChainedAssignmentErrorになります や、やったか…！？ 書きたい時はloc等を使って 実質的なゼロコピーで（遅延コピー）

Polarsが高速でメモリ効率が良いとされている理由 ● Apache Arrow ● ゼロコピー（※Apache Arrow同士の変換やプロトコル観点でゼロコピーという言葉が使われたりもするが、ここではDataframeメモリモデルとしてのゼロコピー） ○ Polarsは思想としてメソッドチェーンを使いviewの利用を徹底している ○ pandasも破壊的変更で近いものが導入される（Copy-on-Write） ● 遅延評価

Polarsといえば遅延評価 Polarsの遅延評価周辺（LazyAPI/StreamingAPI） を丁寧に解説した書籍があるらしい 一体、何処理アイデアレシピなんだ…

Polarsといえば遅延評価 SQLの最適化処理と同様 “”” 結果が欲しくなる実行時までLazyに処理する 　↓ 欲しい時にcollect 一連の処理内容全体を見て 不必要な計算の削除 branch predictions キャッシュミス削減 実行順や並列実行計画を最適化 “””

pandasを取り巻く遅延評価 ● Copy-on-Write原則 ○ 遅延copyな世界が実現、遅延処理の環境も整う ○ 特殊な書き方をErrorとすることで疑似メソッドチェーンベースへ Polars同様のインターフェースに近付いている ● 完全なApache Arrow化が終わった未来 ○ Apache Arrowモデルに対するQuery Optimizer実装は多い や、やったか…！？

Polarsが高速でメモリ効率が良いとされている理由 ● Apache Arrow ○ Apache Arrowは凄いがPolarsはその扱い方も凄い ■ RustなApache Arrow自前実装wrapperをカリカリチューニング ■ SIMDや並列化を使った高速化を標準とした実装 ○ Apache Arrow自体はpandasも扱えるしデフォルトになっていく ● ゼロコピー（※Apache Arrow同士の変換やプロトコル観点でゼロコピーという言葉が使われたりもするが、ここではDataframeメモリモデルとしてのゼロコピー） ○ Polarsは思想としてメソッドチェーンを使いviewの利用を徹底している ○ pandasも破壊的変更で近いものが導入される（Copy-on-Write） ● 遅延評価 ○ 遅延で評価することでQuery最適化できる ○ CoWとApache Arrowでpandasにも実装可能な未来が待っている

Polarsが高速でメモリ効率が良いとされている理由 ● Apache Arrow ○ Apache Arrowは凄いがPolarsはその扱い方も凄い ■ RustなApache Arrow自前実装wrapperをカリカリチューニング ■ SIMDや並列化を使った高速化を標準とした実装 ○ Apache Arrow自体はpandasも扱えるしデフォルトになっていく ● ゼロコピー（※Apache Arrow同士の変換やプロトコル観点でゼロコピーという言葉が使われたりもするが、ここではDataframeメモリモデルとしてのゼロコピー） ○ Polarsは思想としてメソッドチェーンを使いviewの利用を徹底している ○ pandasも破壊的変更で近いものが導入される（Copy-on-Write） ● 遅延評価 ○ 遅延で評価することでQuery最適化できる ○ CoWとApache Arrowでpandasにも実装可能な未来が待っている

や、やったか…！？

実はそれだけではないPolarsの強み ● Apache Arrow ○ SIMD ○ 並列化 ● ゼロコピー ● 遅延評価 ○ Lazy API - Query Optimization ○ Streaming APIによるOut-of-Memory Processing ● vectorized execution ○ 一部の処理は行列演算化され高速に処理される ● map/reduce model ○ group byなどの処理はmap/reduceの概念を使って擬似的に並列化 ● mmap ○ バッファプール自前実装により高いI/O効率 ● GPU対応 ○ cudfを綺麗にwrapしている（将来的にはcuda直接叩くのでは…？というくらいの勢い） ○ Rustのメモリ管理との相性の悪さも解消するカリカリチューニング ● Rust ○ Python Packageの依存関係なしでのinstall ○ CPythonのPyObjectに比べて省メモリなタイミングが多い …

pandasの弱みと強み ● つよみ ○ 堅牢な開発体制とコミュニティ ■ プロポーザル制度『PDEP』(※PythonでいうPEPのようなもの) ■ Apache Arrow化などを含むRoadmapも ○ 機械学習既存ツールの多くがpandas基準 ● よわみ ○ 開発はどうしても遅くなる ■ CoW導入のような破壊的変更には SettingWithCopyWarningでFBを1年issueで受け メジャーバージョンアップでやっと導入 pyarrowやCoWのissueを見ればわかるが破壊的変更に対する一部ユーザの反感は凄い dtype string[pyarrow]など文字列dtypeが増えてしまう事への難しさ…pandasパッケージサイズが肥大化する事への難しさ… PDEP, Roadmapを見ないままコメントするユーザも多い

ソフトウェア開発の歴史を鑑みるとよくある ● 最近だとpipenv/poetry/rye問題 ○ poetryが早いとされていたが pipenvの諸問題解決 + poetryの諸問題対応で同等に ○ ryeが出てきたが内部で使われるアルゴリズムや工夫は真似出来るものが多く ryeもまたいずれPython Packaging全体の課題に行き着く ○ ユーザはインターフェースや開発体験、パワーワードに惹かれ、エッジケースは考慮しない ● Pythonに限らず普遍的に起こってきたこと 性能面で強いモダンツールが話題に… 1⃣　後からメジャーツールが追いつく 2⃣　メジャーツールが体力切れで萎んでいく 3⃣　両者の目的が変わり別の分野に変化する 良い悪いではなく 技術が進化していく過程とはそういうもの イノベーションのジレンマ

主題「pandasはPolarsに性能面で追いつくのか」 ● 結論：わからない！！ @vaaaaanquishの意見は厳しい寄り ● 機能面 ○ Polarsの性能最適化に追いつくにあたって強いて厳しい側面があるとしたら PythonとRustという言語の差になる可能性が高いと感じる （切り詰めるとpyarrow vs polars-arrowやFFIボトルネック最小化勝負になるのではないか説） ○ DaskやFireDucksなど今日紹介した実装をやっているpandas互換フレームワークもあるが それ以上にカリカリチューニング思想で実績も出ているのがPolarsという現状 ● 開発カルチャー面 ○ pandasは影響範囲が大きく、開発体制は言語やOSの開発に近くなっている ○ Polars開発は早すぎる、高速化のためだけにメモリマップを再設計したり破壊的変更を平気でやる ○ 流行がフレームワークの未来や開発、金銭面を左右しやすい時代である 爆発的に性能が優れたアルゴリズムが開発されたり、Polarsがチューニングしすぎて局所最適解になってしまったり、 コーディング系のAIが全てを移植、改善してpandasが超強化されるパターン等はあり得るかもしれないが 大企業vsスタートアップ議論みたいなもので、先を読む事自体がなかなか難しくなってきている…

私達に出来ること ● 巨人の肩に乗ってツールは移り変わるという イノベーションの現実を受け入れる ● pandas 3.0でかなり状況が変わるので 最新情報を要ウォッチ！ ● 今度こそpolarsをマスター！