ポーラーズ（Polars）
(pola.rs)- 単一マシンで高速なデータ処理が必要な環境を想定したオープンソースのDataFrameライブラリで、5億7,500万回以上のダウンロードと3万8,000以上のGitHubスターを記録
- 性能の中核はRustベースのマルチスレッドクエリエンジンと、カラム指向処理、ベクトル化、SIMD、並列実行にある
- MITライセンスのオープンソースライブラリとして継続提供され、同じAPIで本番ワークロードまで拡張できるPolars Cloudもあわせて提供
- pandas比で30倍以上の性能向上を打ち出しており、派生TPC-Hベンチマークはc3-highmem-22で、scale factor 10かつI/Oを含む条件で実行
- CSV、JSON、Parquet、Delta Lake、AVRO、Excel、Arrow、主要データベース、S3とAzureストレージをサポートし、既存のデータスタックに組み込みやすい
Polarsの提供形態
- Polarsはデータ操作のためのオープンソースライブラリであり、単一マシンにおける最速級のデータ処理ソリューションの1つとして位置づけられている
- 構造化され型付けされたAPIを提供し、表現力と使いやすさの両立を目指している
- 現在の公開指標は以下のとおり
- 575M+ ダウンロード
- 38k+ GitHubスター
- 導入ガイドはGet startedで確認できる
-
オープンソースのPolars
- PolarsはMITライセンスのもとで無料で利用できるオープンソースライブラリ
- 高性能なDataFrameライブラリとして提供され、インストール方法もシンプル
- インストール例は以下のとおり
- Python:
pip install polars - Rust:
polars = { version = "x", features = ["lazy", ...]} - Node.js:
const pl = require('nodejs-polars');
- Python:
-
Polars Cloud
- Polars Cloudは、ノートブック環境のPolarsクエリをクラウドまたはオンプレミスの本番ワークロードへ拡張するマネージドソリューション
- 同じAPIを使ってコード変更なしにスケールできる
- デプロイ方式はCloudまたはOn-Premに対応
- 課金はクエリ実行時にのみ発生
- 体験はPolars Cloudで可能
性能モデルとデータ統合
- Polarsの性能基盤は、Rustベースのマルチスレッドクエリエンジンと並列処理設計にある
- ベクトル化とカラム指向処理により、現代のプロセッサでキャッシュ整合性の高いアルゴリズムと高性能を実現
- 派生した独立TPC-Hベンチマークで複数のソリューションと比較されており、実務のデータ整形作業の再現を目指している
- pandasと比較して30倍以上の性能向上が可能
- ベンチマークはc3-highmem-22で、scale factor 10、I/Oを含む条件で実行
- クエリはopen sourceとして公開されている
- 詳細はLearn moreで確認できる
-
使いやすさと実行最適化
- ユーザーは意図した形でクエリを書き、Polarsのクエリオプティマイザが効率的な実行方法を決定する
- 利用可能なCPUコアに処理を分散し、追加設定やシリアライズのオーバーヘッドなしで並列実行する
- Apache Arrowメモリモデルを使用し、既存のデータツールと統合できる
- zero-copyのデータ共有により、ツール間連携のコストを抑えられる
- 外部依存なしでマシンに近い設計となっており、API、メモリ、実行を制御できる
- メモリより大きなデータセットはストリーミングAPIで処理でき、全データをメモリに載せる必要がない
-
対応データ形式
- Polarsは一般的なデータ形式の読み書きをサポートし、既存のデータスタックと統合できる
- 対応範囲は以下のとおり
- Text: CSV, JSON
- Binary: Parquet, Delta Lake, AVRO, Excel
- IPC: Feather, Arrow
- Databases: MySQL, Postgres, SQL Server, Sqlite, Redshift, Oracle
- Cloud storage: S3, Azure Blob, Azure File
1件のコメント
Hacker News の意見
このページは、すでに何を見ているのか分かっている人向けに書かれていることがあまりにも明らかです。最初の一文からツールの説明ではなく、「Polars is written from the ground up with performance in mind」のように品質の話から始まり、残りも同じ流れです
誰か、5歳児に説明するようにこれが何で、どんなニーズに対する良いソリューションなのかを教えてくれませんか？
追記: 結局、Pandas DataFrame の代替実装だと理解しました。Google で見つけた https://realpython.com/pandas-dataframe/ の説明によると、DataFrame は2次元データとラベルを保持する構造で、データサイエンス、機械学習、科学計算などのデータ集約型分野で広く使われ、SQL テーブルや Excel/Calc のスプレッドシートに似ています
私は Polars のターゲット読者で、数か月前から試そうとしていたのですが、ずっと先延ばしにしています。Pandas の作者である Wes McKinney が一般的な分析ツールを説明する有用な本 https://wesmckinney.com/book/ を書いてくれたおかげで、Pandas への忠誠心が残っています
pandas、modin、vaex というものと比較したグラフが出てきますが、それらもまったく知らないので、結局これは自分向けではないのだなと感じます。新しい技術やプロジェクトについて読んで学ぶのは好きですが、ここには自分が手がかりにできるものがありません
私が取るに足らない Web 開発の話をするときに、一般の人が経験していることはたぶんこういうことなのでしょう
Polars で興味深いのは、Pandas に似ているものの、より効率的な Rust バックエンドである Arrow を使い、演算の組み合わせをより効率化するクエリプランナーのようなものがある点です。通常、Polars は Pandas よりはるかに効率的なので、以前なら複雑なインフラが必要だった作業も、単一マシンでできることが多いです
Pandas の主要開発者が作った、とても友好的な競争関係で、見たところ皆が好意的に受け止めており、時間がたてば Pandas を置き換える可能性が高そうです
関連記事:
Detailed Comparison Between Polars, DuckDB, Pandas, Modin, Ponder, Fugue, Daft - https://news.ycombinator.com/item?id=37087279 - 2023年8月
Polars: Company Formation Announcement - https://news.ycombinator.com/item?id=36984611 - 2023年8月
Replacing Pandas with Polars - https://news.ycombinator.com/item?id=34452526 - 2023年1月
Fast DataFrames for Ruby - https://news.ycombinator.com/item?id=34423221 - 2023年1月
Modern Polars: A comparison of the Polars and Pandas dataframe libraries - https://news.ycombinator.com/item?id=34275818 - 2023年1月
Rust polars 0.26 is released - https://news.ycombinator.com/item?id=34092566 - 2022年12月
Polars: Fast DataFrame library for Rust and Python - https://news.ycombinator.com/item?id=29584698 - 2021年12月
Polars: Rust DataFrames Based on Apache Arrow - https://news.ycombinator.com/item?id=23768227 - 2020年7月
Pandasを何年も使ってきたが、いつもボールを丘の上へ転がしているような感覚だった。joinのような単純な作業でさえそうだし、インデックスのリセットも忘れてはいけない
Polarsはほぼあらゆる面でPandasより優れているように感じる。より高速で、マルチコアを使い、メモリ消費が少なく、APIがより直感的だ。まだ比較的若いライブラリなので欠点はあるが、新規プロジェクトなら少なくとも検討する価値はある
Rustエコシステムを簡単に活用できるのも素晴らしい。自分でプラグインを書いて関数を並列化し、一部の地理空間コードを100倍高速化できた
Pandasは初期にRの用語と利用パターンから強い影響を受けており、Rでは「merge」が「join」を意味する言葉としてすでに一般的だった。Pandasを学び始めた2015年頃にRをすでに知らなかったなら、素早く習得するのは難しかったと思う
クエリはPolarsやPandasだけでなく、DuckDB、ClickHouse、BigQuery、Redshift、Postgres、Trino/Presto、SQLiteなど、好みのSQL互換実行エンジンで動かせる
joinの構文とセマンティクスは最も難しい部分の一つなので、最近また議論している。関係代数の核心であり、PRQLのRにも当たる。PRQLの基本的な変換のほとんどはmap、filter、reduceのような単純なリスト操作だが、joinはモナド合成を保つには注意が必要だ。考えはここに残してある: https://github.com/PRQL/prql/issues/3782#issuecomment-1811312787
そのissueは閉じられているが、新しいissueを開くか、@snthでタグ付けして意見を聞かせてほしい。ちなみに私はPRQLのコントリビューターだ
評価してみたところ、最大の利点はAPIがPandasよりはるかに一貫していて理解しやすかったことだ。Pandasの20のメジャーバージョンを見ながら学んできたはずなので、当然の面もある
ただ、はるかに利用者が少ないため、CopilotがPolarsのコードをうまく書けなかった。なので今はPandasとCopilotを使い続けている。新しいライブラリ全般にこういう障壁があるのだと、今回初めて感じた
それでもCopilotはリポジトリ内で非常に速く学習する。私は作者本人も使っておらず推奨もしていないTypeScriptのフォークであるTS-Plusで構成した、極度にカスタムなスタックを使っているが、Copilotはかなり良いTS-Plusコードを出してくる
いくつか例を見た後なら、定型コードの段階でCopilotがかなりうまくなり得ることを過小評価しないほうがいい
ドキュメントを読めば済むので大きな問題ではなかったが、必要なものをCopilotがすぐに出してくれないのは面倒だった
私はPandas APIを長く使ってきたし、嫌っていた。学習、ツール、考え方、技術を継続的に改善することにはかなり積極的なほうだ
with_columnがwith_columnsに変わったといった最新情報を入れ、ドキュメント内容を追加すると、ChatGPTでかなり良い結果が得られたDenoがJupyterサポートをリリースしたとき、
nodejs-polarsはサポート対象のデータサイエンス中核ライブラリの一つだったhttps://blog.jupyter.org/bringing-modern-javascript-to-the-jupyter-notebook-fc998095081e
個人的にはデータサイエンス側の人間ではないが、JS/Jupyterエコシステムがまだ初期段階であることを考えると、TypeScriptでpola.rsベースの分析を立ち上げるのは驚くほど速かった
JSバインディングには確かに手を入れるべき部分があるが、アクセスしやすくなった分、反復的な改善が起きることを願っている
Polarsには本当に期待しているし速度性能も印象的だが、vaex、modin、daskをすべて同じベンチマークで比較しているのは気になる
これらのライブラリはいずれもアウトオブコアデータ処理、つまりデータが大きすぎて複数マシンにまたがって計算する用途を狙っている。単一マシンのデータフレームライブラリと比較するのは変だし、必然的にオーバーヘッドが大きいので遅くならざるを得ない
そうしたライブラリと同じ文脈でPolarsを使うことはあまりないのに、同格のようにベンチマークに示すのは少しおかしい。しかもPolarsと同じ文脈で使えて、多くの場合より高速なDuckDBはベンチマークに入っていない
Polarsのソフトウェアエンジニアリングは素晴らしい仕事であり、こうした誤解を招くベンチマークは必要ない
設定なしでPandas比2倍の性能向上が可能で、特定の演算では5倍まで見たことがある
Polarsを直接使っているわけではなく、DuckDBのワークフローで具現化形式として使っている
duckdb.query(sql).pl()はduckdb.query(sql).df()よりずっと速い。Polarsではゼロコピーなので即座に終わるが、PandasはDataFrameが大きいとかなり時間がかかる。そして構文が少し違うだけで、Pandas DataFrameのように操作できる大規模データセットを扱うのに非常に良い
Greenspunの第10法則（[https://en.wikipedia.org/wiki/Greenspun's_tenth_rule)](https://en.wikipedia.org/wiki/Greenspun's_tenth_rule)））に対する系がありそうだ。十分に複雑なデータ分析ライブラリは、SQLの半分を場当たり的で非公式仕様で、バグが多く遅い形で実装することになる、という感じだ
Pandasはたまに使うし、これもおそらく試すだろうが、作業中のデータをただPostgresに入れて始めればよかったといつも思う
私はデータベースの専門家でもないし、Pythonのほうがずっと楽なのに、表形式データの選択・並べ替え・フィルタ・結合の機能はSQLのほうがはるかに優れている
duckdb-prql拡張を見ることを勧めるDuckDBは、データのコピーや重複なしに、Polars、Pandas、そしてArrow形式のデータをSQLで直接扱えるようにしてくれる
duckdb-prqlはPRQL（prql-lang.org）を使えるようにしてくれ、個人的にはSQLの力と普遍性に、PolarsやPandasの使用感と開発者体験を組み合わせてくれるものだと思っている。ちなみに私はPRQLのコントリビューターだ代わりにDuckDBを見てみる価値がある。SQL実装は場当たり的でもないし、バグだらけでも遅くも不完全でもない。仕様の形式性はよく分からないが、Polarsと互換がある
こうしたエンジンで行う種類のクエリでは、PostgresはOLAPクエリエンジンより一桁倍は遅いはずだ
PythonのデータフレームとSQLを併用する、より良いアプローチだ
数か月前、大きなPandasコードベースをPolarsへ移行しようとした。Pythonで分析やデータパイプラインをやるのはあまり好きではないのだが、複雑な変換はPandasだとJuliaやR（dataframes.jl、dplyr使用）より2〜5倍時間がかかる
残念ながらPolarsも答えではなかった。標準的な演算にバグが多すぎ、Pandasとの相互運用性も不安定だった。多くのライブラリが入力としてPandas DataFrameを要求するので、これは問題だ。APIも現代的なデータフレームライブラリにしては非常に冗長だが、それでもPandasよりはましだ
時間とともに解決されることを願うが、今のところはPandasの上でDuckDBを使うのがいちばん良かった。Polars並みに速く、より安定していて相互運用性も良い
いつかPythonのデータフレームエコシステムも、Rのように直感的なAPIの分析志向データフレームライブラリ（dplyr）と高性能データフレームライブラリ（data.table）を一緒に簡単に使える地点に到達してほしい
探索的データ分析や研究にはたぶん使わないと思うが、より良い性能のために一部の本番スクリプトでは使い始めている
Rのdplyr + data.tableの組み合わせが、今でもいちばん気に入っているデータ操作体験だ。ただ、RにMatplotlibのようなものがあればよいのにと思う。ggplotは高水準すぎ、基本グラフィックスは低水準すぎる。Scikit-LearnもCaretよりずっとモジュール式なので、Caretが恋しいわけでもない
個人的には、dplyr、Polars、Pandasの開発者体験と、SQLの力と普遍性を組み合わせるものだと思っている。クエリはPolars、Pandasだけでなく、DuckDB、ClickHouse、BigQuery、Redshift、Postgres、Trino/Presto、SQLiteなど、好きなSQL互換実行エンジンで動かせる
考えをGitHub Discussions（https://github.com/PRQL/prql/discussions）やDiscord（https://discord.com/invite/XWxbCrWr）で聞きたい。ちなみに私はPRQLのコントリビューターだ
私たちのデータサイエンスチームが Polars を評価しましたが、結果はまちまちでした。性能が重要な箇所があるなら導入を検討しますが、それ以外では数十のプロジェクトで Pandas を置き換えるコストのため、やや否定的でした
API にはまだ予想される破壊的変更があり、複数のプロジェクトにまたがると保守負担になり得ます。それでも API はすでにより一貫しているように感じられ、全体として正しい方向に進んでいるようです
特に Pandas との相互運用コストは非常に低く、Arrow バックエンドを使えば Pandas への ゼロコピー変換もかなり簡単にできます