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
5.8k
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
エムスリー流!難読クイズを作ってPythonの深淵に触れるコツ! - 技育CAMPアカデミア
vaaaaanquish
1
220
Pythonのパッケージ管理の中級者の壁を超える stapy#98
vaaaaanquish
19
21k
Tech LT #4 人を選ぶ技術
vaaaaanquish
3
4.2k
CADDi AI LabにおけるマネージドなMLOps
vaaaaanquish
2
3.4k
RustとCADDi AI LabとML
vaaaaanquish
1
1k
機械学習OSSの変遷と未来
vaaaaanquish
2
4k
文字列(ダジャレを言いシャレ)
vaaaaanquish
1
16k
xonshとかいうshellの話
vaaaaanquish
1
1.8k
gokartの運用と課題について
vaaaaanquish
5
14k
Other Decks in Technology
See All in Technology
日経のデータベース事業とElasticsearch
hinatades
PRO
0
210
LINEギフトにおけるバックエンド開発
lycorptech_jp
PRO
0
240
CDKでカスタムランタイムを作成して、Lambdaをnode.js23+TypeScriptで動かしてみた
smt7174
2
100
ウォンテッドリーのデータパイプラインを支える ETL のための analytics, rds-exporter / analytics, rds-exporter for ETL to support Wantedly's data pipeline
unblee
0
120
AWSアカウントのセキュリティ自動化、どこまで進める? 最適な設計と実践ポイント
yuobayashi
7
490
ExaDB-XSで利用されているExadata Exascaleについて
oracle4engineer
PRO
3
210
Share my, our lessons from the road to re:Invent
naospon
0
140
抽象化をするということ - 具体と抽象の往復を身につける / Abstraction and concretization
soudai
27
15k
AWSではじめる Web APIテスト実践ガイド / A practical guide to testing Web APIs on AWS
yokawasa
7
600
CDKのコードを書く環境を作りました with Amazon Q
nobuhitomorioka
1
160
AI Agent時代なのでAWSのLLMs.txtが欲しい!
watany
2
200
RayでPHPのデバッグをちょっと快適にする
muno92
PRO
0
190
Featured
See All Featured
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
27
1.6k
The Cost Of JavaScript in 2023
addyosmani
47
7.4k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
Making Projects Easy
brettharned
116
6k
What's in a price? How to price your products and services
michaelherold
244
12k
The World Runs on Bad Software
bkeepers
PRO
67
11k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
133
33k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
30
4.6k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
29
1k
Making the Leap to Tech Lead
cromwellryan
133
9.1k
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をマスター!