Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
pandasはPolarsに性能面で追いつき追い越せるのか
Search
vaaaaanquish
October 29, 2024
Technology
6
6.1k
pandasはPolarsに性能面で追いつき追い越せるのか
以下イベントでの発表内容です
『Polarsとpandasで学ぶデータ処理アイデアレシピ55』出版記念Polars勉強会
https://connpass.com/event/333059/
vaaaaanquish
October 29, 2024
Tweet
Share
More Decks by vaaaaanquish
See All by vaaaaanquish
LLMが機械学習分野と他分野に起こしたキャズムから見極めるエンジニアの未来像
vaaaaanquish
0
120
エムスリー流!難読クイズを作ってPythonの深淵に触れるコツ! - 技育CAMPアカデミア
vaaaaanquish
1
310
Pythonのパッケージ管理の中級者の壁を超える stapy#98
vaaaaanquish
19
21k
Tech LT #4 人を選ぶ技術
vaaaaanquish
3
4.5k
CADDi AI LabにおけるマネージドなMLOps
vaaaaanquish
2
3.5k
RustとCADDi AI LabとML
vaaaaanquish
1
1.1k
機械学習OSSの変遷と未来
vaaaaanquish
2
4.3k
文字列(ダジャレを言いシャレ)
vaaaaanquish
1
16k
xonshとかいうshellの話
vaaaaanquish
1
1.9k
Other Decks in Technology
See All in Technology
LIXIL基幹システム刷新に立ち向かう技術的アプローチについて
tsukuha
1
380
対話型音声AIアプリケーションの信頼性向上の取り組み
ivry_presentationmaterials
3
1k
推し書籍📚 / Books and a QA Engineer
ak1210
0
140
Microsoft Defender XDRで疲弊しないためのインシデント対応
sophiakunii
1
310
「現場で活躍するAIエージェント」を実現するチームと開発プロセス
tkikuchi1002
3
300
Data Engineering Study#30 LT資料
tetsuroito
1
180
AIエージェントが書くのなら直接CloudFormationを書かせればいいじゃないですか何故AWS CDKを使う必要があるのさ
watany
18
7.6k
Transformerを用いたアイテム間の 相互影響を考慮したレコメンドリスト生成
recruitengineers
PRO
2
430
20250708オープンエンドな探索と知識発見
sakana_ai
PRO
4
1k
【あのMCPって、どんな処理してるの?】 AWS CDKでの開発で便利なAWS MCP Servers特集
yoshimi0227
6
950
AIでテストプロセス自動化に挑戦する
sakatakazunori
1
530
セキュアな社内Dify運用と外部連携の両立 ~AIによるAPIリスク評価~
zozotech
PRO
0
120
Featured
See All Featured
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
Optimising Largest Contentful Paint
csswizardry
37
3.3k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
60k
Art, The Web, and Tiny UX
lynnandtonic
299
21k
Into the Great Unknown - MozCon
thekraken
40
1.9k
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
Designing for humans not robots
tammielis
253
25k
Agile that works and the tools we love
rasmusluckow
329
21k
BBQ
matthewcrist
89
9.7k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
48
2.9k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
35
2.4k
Transcript
pandasはPolarsに 性能面で追いつき 追い越せるのか エムスリー株式会社 VPoE 河合 俊典
発売おめでとう🎉
Polarsが高速でメモリ効率が良いとされている理由 • Apache Arrow • ゼロコピー • 遅延評価 まずはこの3つから追ってみよう
列指向フォーマットを簡単おさらい 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をマスター!