Panda è ora più veloce di data.table?

16

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

I benchmark data.table non sono stati aggiornati dal 2014. Ho sentito da qualche parte che Pandasora è più veloce di data.table. È vero? Qualcuno ha fatto dei benchmark? Non ho mai usato Python prima, ma prenderei in considerazione il passaggio se pandasposso battere data.table?

— xiaodai
fonte

7

Questa è una brutta ragione per passare a Python.

— Matthew Drury,

2

@MatthewDrury come? I dati e la loro manipolazione rappresentano l'80% del mio lavoro. Solo il 20% è adatto ai modelli e alla presentazione. Perché non dovrei scegliere quello che mi dà i risultati il più veloce?

— xiaodai,

2

Sia Python che R sono linguaggi consolidati con enormi ecosistemi e comunità. Ridurre la scelta a una singola biblioteca è adorare un singolo albero in una vasta foresta. Tuttavia, l'efficienza è solo una delle preoccupazioni di molti anche per una singola libreria (quanto espressiva è l'interfaccia, come si collega ad altre librerie, quanto estensibile è la base di codice, quanto sono aperti i suoi sviluppatori). Direi che la scelta stessa è una falsa dicotomia; entrambe le comunità hanno un focus diverso, che conferisce alle lingue diversi punti di forza.

— Matthew Drury,

3

hai una foresta enorme che è buona per il 20% del lavoro? quindi non fare una scelta per l'80% del tuo lavoro? nulla mi impedisce di usare Panda per preparare i dati e poi modellare in R python o Julia. penso che il mio pensiero sia sano. se il panda è più veloce di quanto dovrei sceglierlo come il mio strumento principale.

— xiaodai,

1

È possibile trovare il pacchetto reticolare in R di interesse / utilizzo. Inoltre, sempre più sforzi sono stati fatti per far funzionare R / lavorare con i database (vedi sforzi come dbplyr ).

— slackline

15

Qualcuno ha fatto dei benchmark?

Sì, il benchmark che hai collegato alla tua domanda è stato recentemente aggiornato per la versione recente di data.table e panda. Inoltre è stato aggiunto altro software. Puoi trovare il benchmark aggiornato su https://h2oai.github.io/db-benchmark
Purtroppo è programmato su una memoria da 125 GB (non 244 GB come quella originale). Di conseguenza, i panda e il dask non sono in grado di tentare dati groupbysu 1e9 righe (50 GB csv) perché esauriscono la memoria durante la lettura dei dati. Quindi, per Panda vs data.table devi guardare i dati di 1e8 righe (5 GB).

Per non solo collegare il contenuto che stai chiedendo, sto incollando i tempi recenti per quelle soluzioni.

si prega di notare che tali orari sono obsoleti
visitare https://h2oai.github.io/db-benchmark per gli orari aggiornati

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

In 4 domande su 5 data.table è più veloce e possiamo vedere che si ridimensiona meglio.
Basta notare che questo tempi sono fin d'ora , dove id1, id2e id3sono i campi di carattere. ~~Questi saranno presto cambiati in~~ DONE ~~categorico~~ . Inoltre ci sono altri fattori che possono avere un impatto su questi tempi nel prossimo futuro (come il ~~raggruppamento in parallelo~~ FATTO ). Aggiungeremo anche benchmark separati per i dati con NA e ~~varie cardinalità~~ FATTE .

Altri compiti sono venuta a questo progetto di benchmarking continuo quindi se siete interessati a join, sort, reade altri essere sicuri di controllare in un secondo momento.
E, naturalmente, siete invitati a fornire feedback nel repository del progetto!

— jangorecki
fonte

1

Che dire di JuliaDB?

— skan

1

@skan puoi monitorare lo stato di questo in github.com/h2oai/db-benchmark/issues/63

— jangorecki

1

Buona risposta - AFAICT i benchmark collegati sono stati eseguiti tutti sulla stessa macchina virtuale? Cioè, nelle stesse condizioni, i panda e il dask hanno bisogno di oltre 128 GB di RAM per il tavolo da 50 GB, mentre gli altri possono funzionare con questo vincolo? In tal caso, riflette anche le mie esperienze con i panda che sono molto inefficienti nella RAM per molte cose normali di tutti i giorni su tavoli moderati (~ 10 GB), ed è un problema molto più grande della velocità di esecuzione. (che è molto più vicino e scambia avanti e indietro in ogni caso a seconda del carico di lavoro specifico.)

— jkf

@jkf sì, esattamente. La macchina ha 128 GB di memoria perché stiamo pianificando di testare l'elaborazione mem su un set di dati da 500 GB (10e9 righe). Attualmente solo Spark e Pydatatable lo supporteranno, anche presto per essere aggiunti clickhouse.

— jangorecki,

@jangorecki è un punto di riferimento estremamente utile. Grazie mille per lo sforzo. Sono un po 'perplesso sul fatto che Dask non digerisca il set di dati da 50 GB. Dask ha le dimensioni della partizione come uno dei parametri (ad esempio blocksizein read_csv). Hai provato a evitare di chiamare compute()e scaricare l'output su disco per evitare di assemblare l'intera tabella di output in memoria?

— Mischa Lisovyi,

13

Un collega e io abbiamo condotto alcuni studi preliminari sulle differenze di prestazioni tra i panda e data.table. Puoi trovare lo studio (che è stato diviso in due parti) sul nostro Blog (Puoi trovare la seconda parte qui ).

Abbiamo pensato che ci sono alcune attività in cui i panda superano chiaramente i dati.table, ma anche i casi in cui data.table è molto più veloce. Puoi verificarlo tu stesso e farci sapere cosa ne pensi dei risultati.

EDIT:
se non vuoi leggere i blog in dettaglio, ecco un breve riassunto della nostra configurazione e dei nostri risultati:

Impostare

Abbiamo confrontato pandase data.tablesu 12 diversi set di dati simulati sulle seguenti operazioni (finora), che abbiamo chiamato scenari.

Recupero dei dati con un'operazione di tipo selettivo
Filtro dati con un'operazione di selezione condizionale
Operazioni di ordinamento dei dati
Operazioni di aggregazione dei dati

I calcoli sono stati eseguiti su una macchina con un Intel i7 2,2 GHz con 4 core fisici, 16 GB di RAM e un disco rigido SSD. Le versioni del software erano OS X 10.13.3, Python 3.6.4 e R 3.4.2. Le rispettive versioni di libreria utilizzate erano 0,22 per i panda e 1,10,4-3 per data.table

Risultati in breve

data.tablesembra essere più veloce quando si selezionano le colonne ( pandasin media richiede il 50% di tempo in più)
pandas è più veloce nel filtrare le file (circa il 50% in media)
data.tablesembra essere notevolmente più veloce all'ordinamento (a pandasvolte 100 volte più lento)
l'aggiunta di una nuova colonna appare più velocemente con pandas
i risultati di aggregazione sono completamente misti

Si prega di notare che ho cercato di semplificare il più possibile i risultati per non annoiarvi a morte. Per una visualizzazione più completa leggi gli studi. Se non riesci ad accedere alla nostra pagina web, ti prego di inviarmi un messaggio e ti inoltrerò i nostri contenuti. Puoi trovare il codice per lo studio completo su GitHub . Se hai idee su come migliorare il nostro studio, ti preghiamo di inviarci un'e-mail. Puoi trovare i nostri contatti su GitHub.

— Tobias Krabel
fonte

1

Come avrete letto dalla mia risposta, dico già che i risultati sono contrastanti. Si prega di chiarire se sarò più specifico nella mia risposta, potenzialmente elaborando alcuni numeri.

— Tobias Krabel,

1

"Il tuo accesso a questo sito è stato limitato." Non riesco ad accedere al sito sul mio telefono né sul mio computer di lavoro.

— xiaodai,

1

Mi dispiace leggerlo. L'ho controllato da solo sul mio telefono e non ho avuto problemi. Potrebbe avere qualcosa a che fare con il paese dal quale provi a connetterti?

— Tobias Krabel,

1

"4 core fisici" = 8 core logici. Inoltre aiuta a dire quale specifico Intel i7 2.2GHz (quale generazione? Quale variante? -HQ?) E quale dimensione della cache. E per l'SSD, che velocità di lettura e scrittura?

— smci

Come si confrontano con i frame di dati Julia e JuliaDB?

— skan

3

No, infatti se la dimensione del set di dati è talmente grande che il panda si blocca, sei praticamente bloccato con Dask, il che fa schifo e non puoi nemmeno fare una semplice somma di gruppo. dplyr potrebbe non essere veloce, ma non sbaglia.

Attualmente sto lavorando su un piccolo set di dati 2G e un semplice print(df.groupby(['INCLEVEL1'])["r"].sum())blocco del Dask.

Non ho riscontrato questo errore con dplyr.

Quindi, se i panda sono in grado di gestire il set di dati, uso i panda, in caso contrario, attenersi alla tabella dei dati R.

E sì, puoi convertire dask in panda dataframe con un semplice df.compute() ma ci vuole un tempo abbastanza lungo, quindi potresti anche aspettare pazientemente che i panda vengano caricati o leggibili.

— Chenying Gao
fonte

1

Non sapevo che Dask fosse così cattivo. Forse vuoi provare disk.frame di R? github.com/xiaodaigh/disk.frame I am the author

— xiaodai

1

So che questo è un post più vecchio, ma ho pensato che valga la pena menzionarlo: l'uso di feather (in R e in Python) consente di operare su frame di dati / tabelle di dati e condividere tali risultati tramite feather.

Vedi la pagina di github di piuma

— Don Chisciotte
fonte

Segfault per set di dati medi e grandi

— jangorecki