Les pandas sont-ils désormais plus rapides que data.table?

16

https://github.com/Rdatatable/data.table/wiki/Benchmarks-%3A-Grouping

Les benchmarks data.table n'ont pas été mis à jour depuis 2014. J'ai entendu quelque part qui Pandasest maintenant plus rapide que data.table. Est-ce vrai? Quelqu'un a-t-il fait des repères? Je n'ai jamais utilisé Python auparavant mais envisagerais de changer si je pandaspeux battre data.table?

— xiaodai
source

7

C'est une très mauvaise raison de passer en python.

— Matthew Drury

2

@MatthewDrury comment ça? Les données et leur manipulation représentent 80% de mon travail. Seulement 20% sont destinés à l'ajustement des modèles et de la présentation. Pourquoi ne devrais-je pas choisir celui qui me donne les résultats le plus rapidement?

— xiaodai

2

Python et R sont des langages établis avec d'énormes écosystèmes et communautés. Réduire le choix à une seule bibliothèque, c'est adorer un seul arbre dans une vaste forêt. Même ainsi, l'efficacité n'est qu'une préoccupation parmi beaucoup d'autres, même pour une seule bibliothèque (à quel point l'interface est expressive, comment se connecte-t-elle à une autre bibliothèque, à quel point la base de code est-elle extensible, à quel point ses développeurs sont ouverts). Je dirais que le choix lui-même est une fausse dichotomie; les deux communautés ont un objectif différent, ce qui confère aux langues différentes forces.

— Matthew Drury

3

vous avez une immense forêt qui est bonne pour 20% du travail? alors ne faites pas un choix qui affecte 80% de votre travail? rien ne m'empêche d'utiliser panda pour faire la préparation des données, puis modéliser en R python ou Julia. je pense que ma pensée est saine. si panda est plus rapide que je devrais le choisir comme mon outil principal.

— xiaodai

1

Vous pourriez trouver le package réticulé dans R d'intérêt / d'utilisation. De plus, de plus en plus d'efforts ont été déployés pour que R fonctionne / joue avec les bases de données (voir les efforts tels que dbplyr ).

— slackline

15

Quelqu'un a-t-il fait des repères?

Oui, la référence que vous avez liée dans votre question a été récemment mise à jour pour la version récente de data.table et pandas. De plus, d'autres logiciels ont été ajoutés. Vous pouvez trouver un benchmark mis à jour sur https://h2oai.github.io/db-benchmark
Malheureusement, il est prévu sur une machine à mémoire de 125 Go (pas 244 Go comme l'original). Par conséquent, les pandas et les utilisateurs ne peuvent pas essayer de données groupbysur 1e9 lignes (50 Go csv) car ils manquent de mémoire lors de la lecture des données. Donc, pour les pandas vs data.table, vous devez regarder les données de 1e8 lignes (5 Go).

Pour ne pas simplement lier le contenu que vous demandez, je colle des timings récents pour ces solutions.

veuillez noter que ces horaires sont obsolètes,
visitez https://h2oai.github.io/db-benchmark pour les horaires mis à jour

| 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|

Dans 4 questions sur 5, data.table est plus rapide et nous pouvons le voir évoluer mieux.
Notez juste cette timings sont d'ores et déjà , où id1, id2et id3sont des champs de caractère. ~~Ceux - ci seront bientôt changé catégorique~~ DONE . En outre, il existe d'autres facteurs qui sont susceptibles d'avoir un impact sur ces délais dans un avenir proche (comme le ~~regroupement en parallèle~~ FAIT ). Nous allons également ajouter des références distinctes pour les données ayant des NA et ~~diverses cardinalités~~ FAITES .

D' autres tâches arrivent à ce projet continu d'analyse comparative , donc si vous êtes intéressé par join, sort, readet d' autres assurez - vous de le vérifier plus tard.
Et bien sûr, vous êtes invités à fournir des commentaires dans le repo du projet!

— jangorecki
source

1

Et JuliaDB?

— skan

1

@skan, vous pouvez suivre l'état de celui-ci dans github.com/h2oai/db-benchmark/issues/63

— jangorecki

1

Bonne réponse - AFAICT les benchmarks que vous liez ont tous été exécutés sur la même VM? Autrement dit, dans les mêmes conditions, les pandas et les dask ont besoin de plus de 128 Go de RAM pour la table de 50 Go, tandis que les autres peuvent fonctionner sous cette contrainte? Si c'est le cas, cela reflète également mes expériences avec les pandas étant très inefficaces en RAM pour beaucoup de choses quotidiennes normales sur des tables modérées (~ 10 Go), et c'est un problème beaucoup plus important la plupart du temps que la vitesse d'exécution. (qui est beaucoup plus proche et se

— transforme de

@jkf oui, exactement. La machine a une mémoire de 128 Go car nous prévoyons de tester le traitement mem sur un ensemble de données de 500 Go (10e9 lignes). Actuellement, seuls spark et pydatatable prendront en charge cela, qui sera bientôt ajouté.

— jangorecki

@jangorecki qui est une référence extrêmement utile. Un grand merci pour l'effort. Je suis un peu perplexe à propos de ne pas devoir digérer l'ensemble de données de 50 Go. Dask a la taille de la partition comme l'un des paramètres (par exemple blocksizedans read_csv). Avez-vous essayé d'éviter d'appeler compute()et de vider la sortie sur le disque pour éviter d'assembler la table de sortie entière en mémoire?

— Mischa Lisovyi

13

Un collègue et moi avons effectué quelques études préliminaires sur les différences de performance entre les pandas et le tableau de données. Vous pouvez trouver l'étude (qui a été divisée en deux parties) sur notre blog (vous pouvez trouver la deuxième partie ici ).

Nous avons pensé qu'il y a des tâches où les pandas surpassent clairement data.table, mais aussi des cas où data.table est beaucoup plus rapide. Vous pouvez le vérifier vous-même et nous faire savoir ce que vous pensez des résultats.

EDIT:
Si vous ne voulez pas lire les blogs en détail, voici un bref résumé de notre configuration et de nos résultats:

Installer

Nous avons comparé pandaset data.tablesur 12 ensembles de données simulés différents sur les opérations suivantes (jusqu'à présent), que nous avons appelées scénarios.

Récupération de données avec une opération de type sélection
Filtrage des données avec une opération de sélection conditionnelle
Opérations de tri des données
Opérations d'agrégation de données

Les calculs ont été effectués sur une machine avec un Intel i7 2,2 GHz avec 4 cœurs physiques, 16 Go de RAM et un disque dur SSD. Les versions du logiciel étaient OS X 10.13.3, Python 3.6.4 et R 3.4.2. Les versions de bibliothèques respectives utilisées étaient 0,22 pour les pandas et 1.10.4-3 pour data.table

Les résultats en bref

data.tablesemble être plus rapide lors de la sélection des colonnes (cela pandasprend en moyenne 50% de temps en plus)
pandas est plus rapide pour filtrer les lignes (environ 50% en moyenne)
data.tablesemble être beaucoup plus rapide au tri ( pandasétait parfois 100 fois plus lent)
l'ajout d'une nouvelle colonne apparaît plus rapidement avec pandas
les résultats d'agrégation sont complètement mitigés

Veuillez noter que j'ai essayé de simplifier les résultats autant que possible pour ne pas vous ennuyer à mort. Pour une visualisation plus complète, lisez les études. Si vous ne pouvez pas accéder à notre page Web, veuillez m'envoyer un message et je vous ferai parvenir notre contenu. Vous pouvez trouver le code de l'étude complète sur GitHub . Si vous avez des idées pour améliorer notre étude, veuillez nous envoyer un e-mail. Vous pouvez retrouver nos contacts sur GitHub.

— Tobias Krabel
source

1

Comme vous l'avez peut-être lu dans ma réponse, je dis déjà que les résultats sont mitigés. Veuillez préciser si je serai plus précis dans ma réponse, en développant éventuellement certains chiffres.

— Tobias Krabel

1

"Votre accès à ce site a été limité." Je n'arrive pas à accéder au site sur mon téléphone ni sur mon ordinateur de travail.

— xiaodai

1

Je suis désolé de lire ça. Je l'ai vérifié moi-même sur mon téléphone et je n'ai eu aucun problème. Cela pourrait-il avoir quelque chose à voir avec le pays à partir duquel vous essayez de vous connecter?

— Tobias Krabel

1

"4 cœurs physiques" = 8 cœurs logiques. Il est également utile de dire quel processeur Intel i7 2,2 GHz (quelle génération? Quelle variante? -HQ?) Et quelle taille de cache. Et pour le SSD, quelles vitesses de lecture et d'écriture?

— smci

Comment se comparent-ils aux cadres de données Julia et JuliaDB?

— skan

3

Non, en fait, si la taille de l'ensemble de données est si grande que les pandas se bloquent, vous êtes essentiellement coincé avec des tâches, ce qui est nul et vous ne pouvez même pas faire une simple somme de groupe. dplyr n'est peut-être pas rapide, mais il ne gâche pas.

Je travaille actuellement sur un petit ensemble de données 2G et un simple print(df.groupby(['INCLEVEL1'])["r"].sum())bloque la tâche.

N'a pas rencontré cette erreur avec dplyr.

Donc, si les pandas peuvent gérer l'ensemble de données, j'utilise des pandas, sinon, respectez le tableau de données R.

Et oui, vous pouvez reconvertir dask en une trame de données pandas avec un simple df.compute() mais cela prend un temps assez long, donc vous pourriez aussi bien attendre patiemment que les pandas se chargent ou que les données puissent être lues.

— Chenying Gao
source

1

Je ne savais pas que Dask était si mauvais. Peut-être que vous voulez essayer disk.frame de R? github.com/xiaodaigh/disk.frame Je suis l'auteur

— xiaodai

1

Je sais que c'est un article plus ancien, mais je pense qu'il vaut la peine de le mentionner - l'utilisation de feather (en R et en Python) permet de travailler sur des trames de données / tableaux de données et de partager ces résultats via feather.

Voir la page du github de plumes

— Don Quichotte
source

Segfaults pour les moyennes et grandes séries de données

— jangorecki