Lock in $30 Savings on PRO—Offer Ends Soon! ⏳
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
pandasはPolarsに性能面で追いつき追い越せるのか
Search
vaaaaanquish
October 29, 2024
Technology
6
5.4k
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
0
150
Pythonのパッケージ管理の中級者の壁を超える stapy#98
vaaaaanquish
18
20k
Tech LT #4 人を選ぶ技術
vaaaaanquish
3
4.1k
CADDi AI LabにおけるマネージドなMLOps
vaaaaanquish
2
3.4k
RustとCADDi AI LabとML
vaaaaanquish
1
950
機械学習OSSの変遷と未来
vaaaaanquish
2
3.8k
文字列(ダジャレを言いシャレ)
vaaaaanquish
1
15k
xonshとかいうshellの話
vaaaaanquish
1
1.8k
gokartの運用と課題について
vaaaaanquish
5
13k
Other Decks in Technology
See All in Technology
振る舞い駆動開発(BDD)における、テスト自動化の前に大切にしていること #stac2024 / BDD formulation
nihonbuson
2
280
お悩みハンドブック紹介資料
grafferhandbook
0
720
ファインディの4年にわたる技術的負債の返済 / Repaying 4 Years of Technical Debt at Findy
ma3tk
7
3.5k
論理レプリケーションを使ったDB統合
kkato1
0
130
pmconf2024_UPSIDER
upsider_tech
0
5.6k
店舗向けSaaSにおける 顧客要望活用の実践アプローチ(20241205_pmconf)
yujirooo
0
2.4k
乗っ取れKubernetes!!~リスクから学ぶKubernetesセキュリティの考え方~/k8s-risk-and-security
mochizuki875
3
450
日本全国・都市3D化プロジェクト「PLATEAU」とデータ変換OSS「PLATEAU GIS Converter」の公開
nokonoko1203
4
340
間違いだらけのポストモーテム - ホントに役立つレビューはこうだ!
jacopen
5
960
専門領域に特化したチームの挑戦
leveragestech
0
250
クラウドネイティブへの小さな一歩!既存VMからコンテナまで、KubeVirtが実現する『無理しないペースの移行』とは!?
tsukaman
0
110
Entra ID の多要素認証(Japan Microsoft 365 コミュニティ カンファレンス 2024 )
murachiakira
0
1.9k
Featured
See All Featured
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
31
2.7k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
6.9k
Code Review Best Practice
trishagee
64
17k
Building Your Own Lightsaber
phodgson
103
6.1k
Build The Right Thing And Hit Your Dates
maggiecrowley
33
2.4k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
4
410
Keith and Marios Guide to Fast Websites
keithpitt
410
22k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
0
7
KATA
mclloyd
29
14k
Rebuilding a faster, lazier Slack
samanthasiow
79
8.7k
Building a Scalable Design System with Sketch
lauravandoore
459
33k
Testing 201, or: Great Expectations
jmmastey
40
7.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をマスター!