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.3k
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
生成AIによるソフトウェア開発の収束地点 - Hack Fes 2025
vaaaaanquish
35
18k
LLMが機械学習分野と他分野に起こしたキャズムから見極めるエンジニアの未来像
vaaaaanquish
0
190
エムスリー流!難読クイズを作ってPythonの深淵に触れるコツ! - 技育CAMPアカデミア
vaaaaanquish
1
370
Pythonのパッケージ管理の中級者の壁を超える stapy#98
vaaaaanquish
19
22k
Tech LT #4 人を選ぶ技術
vaaaaanquish
3
4.6k
CADDi AI LabにおけるマネージドなMLOps
vaaaaanquish
2
3.6k
RustとCADDi AI LabとML
vaaaaanquish
1
1.1k
機械学習OSSの変遷と未来
vaaaaanquish
2
4.4k
文字列(ダジャレを言いシャレ)
vaaaaanquish
1
17k
Other Decks in Technology
See All in Technology
roppongirb_20250911
igaiga
0
120
品質視点から考える組織デザイン/Organizational Design from Quality
mii3king
0
150
ChatGPTとPlantUML/Mermaidによるソフトウェア設計
gowhich501
1
120
Autonomous Database - Dedicated 技術詳細 / adb-d_technical_detail_jp
oracle4engineer
PRO
4
10k
LLMを搭載したプロダクトの品質保証の模索と学び
qa
0
990
複数サービスを支えるマルチテナント型Batch MLプラットフォーム
lycorptech_jp
PRO
0
230
allow_retry と Arel.sql / allow_retry and Arel.sql
euglena1215
1
160
Snowflakeの生成AI機能を活用したデータ分析アプリの作成 〜Cortex AnalystとCortex Searchの活用とStreamlitアプリでの利用〜
nayuts
1
430
Grafana MCPサーバーによるAIエージェント経由でのGrafanaダッシュボード動的生成
hamadakoji
1
1.5k
20250903_1つのAWSアカウントに複数システムがある環境におけるアクセス制御をABACで実現.pdf
yhana
3
500
MCPで変わる Amebaデザインシステム「Spindle」の開発
spindle
PRO
3
3.1k
react-callを使ってダイヤログをいろんなとこで再利用しよう!
shinaps
1
210
Featured
See All Featured
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Optimising Largest Contentful Paint
csswizardry
37
3.4k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Testing 201, or: Great Expectations
jmmastey
45
7.6k
Build The Right Thing And Hit Your Dates
maggiecrowley
37
2.8k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
33
2.4k
Large-scale JavaScript Application Architecture
addyosmani
512
110k
Building Better People: How to give real-time feedback that sticks.
wjessup
368
19k
The Power of CSS Pseudo Elements
geoffreycrofte
77
5.9k
Building Applications with DynamoDB
mza
96
6.6k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
30
9.6k
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をマスター!