https://github.com/Rdatatable/data.table/wiki/Benchmarks-%3A-Grouping
data.tableベンチマークは2014年以降更新されていません。それがどこPandas
よりも速いと聞いたことがありdata.table
ます。これは本当ですか?誰もベンチマークをしましたか?Pythonを使ったことがありませんpandas
が、勝てるなら切り替えを検討しdata.table
ますか?
https://github.com/Rdatatable/data.table/wiki/Benchmarks-%3A-Grouping
data.tableベンチマークは2014年以降更新されていません。それがどこPandas
よりも速いと聞いたことがありdata.table
ます。これは本当ですか?誰もベンチマークをしましたか?Pythonを使ったことがありませんpandas
が、勝てるなら切り替えを検討しdata.table
ますか?
回答:
同僚と私は、pandasとdata.tableのパフォーマンスの違いについていくつかの予備調査を実施しました。私たちのブログで研究(2つの部分に分割されています)を見つけることができます(ここでパート2を見つけることができます)。
パンダがdata.tableより明らかに優れているタスクもあるが、data.tableの方がずっと速い場合もあると考えました。あなたはそれを自分でチェックして、結果についてどう思うかを私たちに知らせることができます。
編集:
ブログを詳細に読みたくない場合は、セットアップと調査結果の概要を以下に示します。
セットアップ
シナリオと呼ばれる次の操作(これまで)で、12の異なるシミュレーションデータセットを比較pandas
しdata.table
ました。
計算は、4つの物理コア、16GB RAM、SSDハードドライブを搭載したIntel i7 2.2GHzを搭載したマシンで実行されました。ソフトウェアバージョンは、OS X 10.13.3、Python 3.6.4およびR 3.4.2でした。使用されたそれぞれのライブラリバージョンは、パンダでは0.22、data.tableでは1.10.4-3でした。
一言で言えば
data.table
列を選択するときの方が速いようです(pandas
平均で50%時間がかかります)pandas
行のフィルタリングが高速です(平均で約50%)data.table
ソート時にかなり高速であるようです(pandas
時には100倍遅くなりました)pandas
結果をできるだけ単純化して、あなたを飽きさせないようにしたことに注意してください。より完全な視覚化については、研究をお読みください。ウェブページにアクセスできない場合は、メッセージを送信してください。コンテンツを転送します。GitHubで完全な調査のコードを見つけることができます。私たちの研究を改善するためのアイデアがあれば、私たちにメールを送ってください。GitHubで連絡先を見つけることができます。
誰もベンチマークをしましたか?
はい。質問でリンクしたベンチマークは、data.tableとpandasの最新バージョン用に最近更新されました。さらに、他のソフトウェアが追加されました。更新されたベンチマークはhttps://h2oai.github.io/db-benchmarkにあります。
残念ながら、125GBのメモリマシンでスケジュールされています(元の244GBではありません)。その結果、パンダとダスクは次のことを試みることができません。groupby
データの読み取り時にメモリが不足するため、1e9行(50GB csv)のデータを。したがって、pandasとdata.tableの場合、1e8行(5GB)のデータを調べる必要があります。
あなたが求めているコンテンツをリンクするだけでなく、これらのソリューションの最近のタイミングを貼り付けています。
これらのタイミングは古くなっていることに注意してください。更新されたタイミングについては、https://h2oai.github.io/db-benchmarkに
アクセスしてください。
| in_rows|question | data.table| pandas|
|-------:|:---------------------|----------:|------:|
| 1e+07|sum v1 by id1 | 0.140| 0.414|
| 1e+07|sum v1 by id1:id2 | 0.411| 1.171|
| 1e+07|sum v1 mean v3 by id3 | 0.574| 1.327|
| 1e+07|mean v1:v3 by id4 | 0.252| 0.189|
| 1e+07|sum v1:v3 by id6 | 0.595| 0.893|
| 1e+08|sum v1 by id1 | 1.551| 4.091|
| 1e+08|sum v1 by id1:id2 | 4.200| 11.557|
| 1e+08|sum v1 mean v3 by id3 | 10.634| 24.590|
| 1e+08|mean v1:v3 by id4 | 2.683| 2.133|
| 1e+08|sum v1:v3 by id6 | 6.963| 16.451|
| 1e+09|sum v1 by id1 | 15.063| NA|
| 1e+09|sum v1 by id1:id2 | 44.240| NA|
| 1e+09|sum v1 mean v3 by id3 | 157.430| NA|
| 1e+09|mean v1:v3 by id4 | 26.855| NA|
| 1e+09|sum v1:v3 by id6 | 120.376| NA|
5つの質問のうち4つで、data.tableの方が高速であり、スケーリングが向上していることがわかります。
このタイミングは今の時点であることに注意してください。ここでid1
、id2
およびid3
は文字フィールドです。それらはまもなくカテゴリカル DONEに変更されます。さらに、近い将来それらのタイミングに影響を与える可能性のある他の要因があります(並列 DONEでのグループ化など)。また、NAとさまざまなカーディナリティ DONEを持つデータの個別のベンチマークも追加します。
あなたがに興味があるので、もし他のタスクは、この連続ベンチマークプロジェクトに来ているjoin
、sort
、read
そして他の人が後でそれを確認してください。
そしてもちろん、プロジェクトリポジトリでフィードバックを提供することを歓迎します!
blocksize
でread_csv
)。呼び出しを避けcompute()
、出力をディスクにダンプして、出力テーブル全体をメモリにアセンブルしないようにしましたか?
いや、実際、データセットのサイズが大きすぎてパンダがクラッシュする場合、基本的には暗闇で立ち往生します。これはひどくて、単純なグループバイサムもできません。dplyrは高速ではないかもしれませんが、混乱することはありません。
私は現在、いくつかの小さな2Gデータセットに取り組んでいますが、簡単にprint(df.groupby(['INCLEVEL1'])["r"].sum())
クラッシュします。
dplyrではこのエラーは発生しませんでした。
したがって、パンダがデータセットを処理できる場合はパンダを使用し、そうでない場合はRデータテーブルに固執します。
そして、はい、あなたはシンプルでダスクをパンダのデータフレームに戻すことができますがdf.compute()
、かなり長い時間がかかりますので、パンダが読み込まれるか、データテーブルを読み込むのを辛抱強く待つだけです。
私はこれが古い投稿であることを知っていますが、言及する価値があると考えられます-フェザーを使用すると(RおよびPythonで)データフレーム/データテーブルで操作し、フェザーを介してそれらの結果を共有できます