Perché i panda si sono uniti in python più velocemente rispetto ai data.table si sono uniti in R nel 2012?

Recentemente ho trovato il panda libreria per Python, che secondo questo benchmark esegue molto veloce si fonde in memoria. È anche più veloce del pacchetto data.table in R (la mia lingua preferita per l'analisi).

Perché è pandasmolto più veloce di data.table? È a causa di un vantaggio di velocità intrinseco che Python ha su R o c'è qualche compromesso di cui non sono a conoscenza? C'è un modo per eseguire i join interni ed esterni data.tablesenza ricorrere a merge(X, Y, all=FALSE)e merge(X, Y, all=TRUE)?

Ecco il codice R e il codice Python utilizzati per confrontare i vari pacchetti.

Sembra che Wes abbia scoperto un problema noto in data.tablequando il numero di stringhe ( livelli ) uniche è grande: 10.000.

Non Rprof()rivelare la maggior parte del tempo speso nella chiamata sortedmatch(levels(i[[lc]]), levels(x[[rc]])? Questo non è in realtà il join stesso (l'algoritmo), ma un passaggio preliminare.

Recenti sforzi sono stati fatti per consentire le colonne di caratteri nelle chiavi, che dovrebbero risolvere il problema integrandosi più da vicino con la tabella hash della stringa globale di R. Alcuni risultati di benchmark sono già riportati da test.data.table()ma quel codice non è ancora collegato per sostituire i livelli con i livelli corrispondenti.

I panda si uniscono più velocemente rispetto data.tablealle normali colonne intere? Questo dovrebbe essere un modo per isolare l'algoritmo stesso rispetto ai problemi dei fattori.

Inoltre, data.tableha in mente le serie temporali . Due aspetti: i) chiavi ordinate su più colonne come (id, datetime) ii) join prevalente ( roll=TRUE) noto anche come ultima osservazione portata avanti.

Avrò bisogno di un po 'di tempo per confermare poiché è il primo che ho visto del confronto data.tablecome presentato.

AGGIORNAMENTO da data.table v1.8.0 rilasciato luglio 2012

• Funzione interna sortmatch () rimossa e sostituita con chmatch () quando si abbinano i livelli a livelli x per colonne di tipo 'fattore'. Questo passaggio preliminare stava causando un rallentamento (noto) significativo quando il numero di livelli di una colonna fattoriale era elevato (ad esempio> 10.000). Esacerbato nei test di unione di quattro di queste colonne, come dimostrato da Wes McKinney (autore del pacchetto Pandas di Python). Ad esempio 1 milione di stringhe di cui 600.000 uniche è ora ridotto da 16 a 0,5 secondi.

anche in quella versione c'era:

• le colonne di caratteri sono ora consentite nelle chiavi e sono da considerare come fattori. data.table () e setkey () non costringono più il carattere al fattore. I fattori sono ancora supportati. Implementa FR # 1493, FR # 1224 e (parzialmente) FR # 951.

• Nuove funzioni chmatch () e% chin%, versioni più veloci di match () e% in% per i vettori di caratteri. Viene utilizzata la cache di stringa interna di R (non viene creata alcuna tabella hash). Sono circa 4 volte più veloci di match () nell'esempio in? Chmatch.

A partire da settembre 2013 data.table è v1.8.10 su CRAN e stiamo lavorando su v1.9.0. NEWS è aggiornato in tempo reale.

Ma come ho scritto in origine, sopra:

data.tableha in mente le serie temporali . Due aspetti: i) chiavi ordinate su più colonne come (id, datetime) ii) join prevalente ( roll=TRUE) noto anche come ultima osservazione portata avanti.

Quindi il panda equi join di due colonne di caratteri è probabilmente ancora più veloce di data.table. Dal momento che sembra che hash le due colonne combinate. data.table non esegue l'hashing della chiave perché ha in mente i join ordinati prevalenti. Una "chiave" in data.table è letteralmente solo il tipo di ordinamento (simile a un indice cluster in SQL; ovvero, è così che i dati vengono ordinati nella RAM). Nell'elenco è necessario aggiungere chiavi secondarie, ad esempio.

In sintesi, la differenza di velocità evidente evidenziata da questo particolare test della colonna di due caratteri con oltre 10.000 stringhe uniche non dovrebbe essere così grave ora, poiché il problema noto è stato risolto.

Il motivo per cui i panda è più veloce è perché ho escogitato un algoritmo migliore, che viene implementato con molta attenzione usando un'implementazione veloce della tabella hash - klib e in C / Cython per evitare l'overhead dell'interprete Python per le parti non vettorizzabili. L'algoritmo è descritto in dettaglio nella mia presentazione: Uno sguardo al design e allo sviluppo dei panda .

Il confronto con data.tableè in realtà un po 'interessante perché l'intero punto di R data.tableè che contiene indici precalcolati per varie colonne per accelerare operazioni come la selezione e l'unione dei dati. In questo caso (Data Database Join), DataFrame di Panda non contiene informazioni pre-calcolate che vengono utilizzate per l'unione, per così dire è un'unione "fredda". Se avessi memorizzato le versioni fattorizzate delle chiavi del join, il join sarebbe significativamente più veloce, poiché la fattorizzazione è il maggiore collo di bottiglia per questo algoritmo.

Vorrei anche aggiungere che il design interno del DataFrame di Panda è molto più suscettibile a questo tipo di operazioni rispetto al data.frame di R (che è solo un elenco di array internamente).

Questo argomento ha due anni ma sembra un luogo probabile in cui le persone possano atterrare quando cercano confronti tra Panda e data.table

Dal momento che entrambi questi si sono evoluti nel tempo, voglio pubblicare un confronto relativamente più recente (dal 2014) qui per gli utenti interessati: https://github.com/Rdatatable/data.table/wiki/Benchmarks-:-Grouping

Sarebbe interessante sapere se Wes e / o Matt (che, a proposito, sono rispettivamente creatori di Panda e data.table e hanno entrambi commentato sopra) hanno qualche notizia da aggiungere anche qui.

-- AGGIORNARE --

Un commento pubblicato di seguito da jangorecki contiene un link che ritengo molto utile: https://github.com/szilard/benchm-database

Questo grafico mostra i tempi medi di aggregazione e le operazioni di join per diverse tecnologie ( inferiore = più veloce ; confronto aggiornato per ultimo a settembre 2016). È stato davvero educativo per me.

Tornando alla domanda, R DT keye R DTfare riferimento alle calettati / sapori non codificate di R data.table e capita di essere più veloce in questo benchmark di Pandas di Python ( Py pandas).

Ci sono grandi risposte, fatte in particolare dagli autori di entrambi gli strumenti di cui fa domanda. La risposta di Matt spiega il caso riportato nella domanda, che è stato causato da un bug e non da un algoritmo di fusione. Il bug è stato corretto il giorno successivo, più di 7 anni fa.

Nella mia risposta fornirò alcuni tempi aggiornati per l'operazione di fusione di data.table e panda. Si noti che la fusione plyr e base R non sono incluse.

I tempi che sto presentando provengono dal progetto db-benchmark , un benchmark riproducibile in esecuzione continua. Aggiorna gli strumenti alle versioni recenti e riesegue gli script di benchmark. Funziona con molte altre soluzioni software. Se sei interessato a Spark, Dask e pochi altri, assicurati di controllare il link.

A partire da ora ... (ancora da implementare: ancora una dimensione dei dati e altre 5 domande)

Testiamo 2 diverse dimensioni di dati della tabella LHS.
Per ognuna di quelle dimensioni di dati eseguiamo 5 domande di unione diverse.

q1: raccordo interno LHS RHS- piccolo su intero
q2: raccordo interno LHS medio RHS su intero
q3: raccordo esterno LHS medio RHS su intero
q4: raccordo interno LHS medio RHS su fattore (categoriale)
q5: raccordo interno LHS RHS- grande su intero

La tabella RHS è di 3 diverse dimensioni

• piccolo si traduce in dimensioni di LHS / 1e6
• il mezzo si traduce in dimensioni di LHS / 1e3
• grande si traduce in dimensioni di LHS

In tutti i casi esiste circa il 90% delle righe corrispondenti tra LHS e RHS e nessun duplicato nella colonna di giunzione RHS (nessun prodotto cartesiano).

A partire da ora (in esecuzione il 2 novembre 2019)

Panda 0.25.3 rilasciato il 1 novembre 2019
data.table 0.12.7 (92abb70) rilasciato il 2 novembre 2019

I tempi seguenti sono espressi in secondi, per due diverse dimensioni di dati di LHS. La colonna pd2dtviene aggiunta al rapporto di memorizzazione dei campi di quante volte i panda sono più lenti di data.table.

• 0,5 GB di dati LHS

+-----------+--------------+----------+--------+
| question  |  data.table  |  pandas  |  pd2dt |
+-----------+--------------+----------+--------+
| q1        |        0.51  |    3.60  |      7 |
| q2        |        0.50  |    7.37  |     14 |
| q3        |        0.90  |    4.82  |      5 |
| q4        |        0.47  |    5.86  |     12 |
| q5        |        2.55  |   54.10  |     21 |
+-----------+--------------+----------+--------+

• 5 GB di dati LHS

+-----------+--------------+----------+--------+
| question  |  data.table  |  pandas  |  pd2dt |
+-----------+--------------+----------+--------+
| q1        |        6.32  |    89.0  |     14 |
| q2        |        5.72  |   108.0  |     18 |
| q3        |       11.00  |    56.9  |      5 |
| q4        |        5.57  |    90.1  |     16 |
| q5        |       30.70  |   731.0  |     23 |
+-----------+--------------+----------+--------+