Trebuie să acoperim cel puțin aceste aspecte pentru a oferi un răspuns/comparație cuprinzătoare (fără o anumită ordine de importanță): Speed, Memory usage, Syntax și Features.

Intenția mea este să acopăr fiecare dintre acestea cât mai clar posibil din perspectiva tabelului de date.

Notă: dacă nu este menționat în mod explicit altfel, prin referire la dplyr, ne referim la interfața data.frame a dplyr ale cărei elemente interne sunt în C++ folosind Rcpp.

Sintaxa data.table este consecventă în forma sa - DT[i, j, by]. A menține i, j și by împreună este prin proiect. Păstrând împreună operațiunile conexe, permite optimizarea cu ușurință a operațiunilor pentru viteza și, mai important, utilizarea memoriei și, de asemenea, oferă câteva funcții puternice , toate menținând consistența în sintaxă.

1. Viteza

La întrebarea s-au adăugat destul de multe benchmark-uri (deși în principal despre operațiuni de grupare) care arată deja data.table devine mai rapid decât dplyr, deoarece numărul de grupuri și/sau rânduri de grupat în funcție de creștere, inclusiv benchmarks de Matt privind gruparea de la 10 milioane la 2 miliarde rânduri (100 GB în RAM) pe 100 - 10 milioane de grupuri și coloane de grupare diferite, care compară și pandas. Consultați și benchmark-uri actualizate, care includ și Spark și pydatatable.

În ceea ce privește reperele, ar fi grozav să acoperiți și aceste aspecte rămase:

• Operațiuni de grupare care implică un subset de rânduri - adică operații de tip DT[x > val, sum(y), by = z].

• Comparați alte operațiuni, cum ar fi actualizare și aderări.

• De asemenea, comparați amprenta de memorie pentru fiecare operațiune în plus față de timpul de execuție.

2. Utilizarea memoriei

1. #P10#

   #P11#

2. #P12#

    # sub-assign by reference, updates 'y' in-place
    DT[x >= 1L, y := NA]
   

   #P13#

    # copies the entire 'y' column
    ans <- DF %>% mutate(y = replace(y, which(x >= 1L), NA))
   

   #P14# #P15#

    foo <- function(DT) {
        DT = shallow(DT)          ## shallow copy DT
        DT[, newcol := 1L]        ## does not affect the original DT 
        DT[x > 2L, newcol := 2L]  ## no need to copy (internally), as this column exists only in shallow copied DT
        DT[x > 2L, x := 3L]       ## have to copy (like base R / dplyr does always); otherwise original DT will 
                                  ## also get modified.
    }
   

   #P16#

    bar <- function(DT) {
        DT[, newcol := 1L]        ## old behaviour, original DT gets updated by reference
        DT[x > 2L, x := 3L]       ## old behaviour, update column x in original DT.
    }
   

   #P17#

   #P18#

   #P19#

3. Agregați în timp ce vă alăturați:

   Să presupunem că aveți două date.tables, după cum urmează:

    DT1 = data.table(x=c(1,1,1,1,2,2,2,2), y=c("a", "a", "b", "b"), z=1:8, key=c("x", "y"))
    #    x y z
    # 1: 1 a 1
    # 2: 1 a 2
    # 3: 1 b 3
    # 4: 1 b 4
    # 5: 2 a 5
    # 6: 2 a 6
    # 7: 2 b 7
    # 8: 2 b 8
    DT2 = data.table(x=1:2, y=c("a", "b"), mul=4:3, key=c("x", "y"))
    #    x y mul
    # 1: 1 a   4
    # 2: 2 b   3
   

   Și ați dori să obțineți sum(z) * mul pentru fiecare rând din DT2 în timp ce vă alăturați prin coloanele x,y. Putem fie:

   • 1. agregați DT1 pentru a obține sum(z), 2) efectuați o îmbinare și 3) înmulțiți (sau)

        date.mod tabel

        DT1[, .(z = suma(z)), keyby = .(x,y)][DT2][, z := z*mul][]

        dplyr echivalent

        DF1 %›% group_by(x, y) %›% rezumat(z = sum(z)) %›% right_join(DF2) %›% mutate(z = z * mul)

   • 2. faceți totul dintr-o singură mișcare (folosind caracteristica by = .EACHI):

        DT1[DT2, list(z=sum(z) * mul), by = .EACHI]

   Care este avantajul?

   • Nu trebuie să alocăm memorie pentru rezultatul intermediar.

   • Nu trebuie să grupăm/hash de două ori (una pentru agregare și alta pentru alăturare).

   • Și, mai important, operațiunea pe care am vrut să o realizăm este clară privind j în (2).

   Consultați această postare pentru o explicație detaliată a by = .EACHI. Nu se materializează rezultate intermediare, iar îmbinarea+agregarea se realizează dintr-o singură mișcare.

   Aruncă o privire la acesta, aceasta și acest postează pentru scenarii reale de utilizare.

   În dplyr ar trebui să să vă alăturați și să agregați sau să agregați mai întâi și apoi să vă alăturați, niciunul dintre acestea nu este la fel de eficient, din punct de vedere al memoriei (care se traduce la rândul său prin viteză).

4. Actualizare și se alătură:

   Luați în considerare codul data.table prezentat mai jos:

    DT1[DT2, col := i.mul]
   

   adaugă/actualizează coloana lui DT1 col cu mul din DT2 pe acele rânduri în care coloana cheie a lui DT2 se potrivește cu DT1. Nu cred că există un echivalent exact al acestei operații în dplyr, adică fără a evita o operație *_join, care ar trebui să copieze întregul DT1 doar pentru a adăuga o nouă coloană la ea, ceea ce este inutil.

   Verificați această postare pentru un scenariu real de utilizare.

Pentru a rezuma, este important să ne dăm seama că fiecare parte de optimizare contează. După cum ar spune Grace Hopper, Ai grijă la nanosecunde!

3. Sintaxă

Să ne uităm acum la sintaxă. Hadley a comentat aici:

Tabelele de date sunt extrem de rapide, dar cred că concizia lor face mai greu de învățat și codul care îl folosește este mai greu de citit după ce l-ați scris...

Mi se pare lipsită de sens această remarcă pentru că este foarte subiectivă. Ceea ce putem încerca este să contrastăm coerența în sintaxă. Vom compara data.table și sintaxa dplyr una lângă alta.

Vom lucra cu datele fictive prezentate mai jos:

DT = data.table(x=1:10, y=11:20, z=rep(1:2, each=5))
DF = as.data.frame(DT)

1. Operațiuni de bază de agregare/actualizare.

    # case (a)
    DT[, sum(y), by = z]                       ## data.table syntax
    DF %>% group_by(z) %>% summarise(sum(y)) ## dplyr syntax
    DT[, y := cumsum(y), by = z]
    ans <- DF %>% group_by(z) %>% mutate(y = cumsum(y))
   
    # case (b)
    DT[x > 2, sum(y), by = z]
    DF %>% filter(x>2) %>% group_by(z) %>% summarise(sum(y))
    DT[x > 2, y := cumsum(y), by = z]
    ans <- DF %>% group_by(z) %>% mutate(y = replace(y, which(x > 2), cumsum(y)))
   
    # case (c)
    DT[, if(any(x > 5L)) y[1L]-y[2L] else y[2L], by = z]
    DF %>% group_by(z) %>% summarise(if (any(x > 5L)) y[1L] - y[2L] else y[2L])
    DT[, if(any(x > 5L)) y[1L] - y[2L], by = z]
    DF %>% group_by(z) %>% filter(any(x > 5L)) %>% summarise(y[1L] - y[2L])
   

   • Sintaxa data.table este compactă și dplyr este destul de pronunțată. Lucrurile sunt mai mult sau mai puțin echivalente în cazul (a).

   • În cazul (b), a trebuit să folosim filter() în dplyr în timp ce sumăm. Dar în timpul actualizării, a trebuit să mutăm logica în mutate(). În data.table totuși, exprimăm ambele operații cu aceeași logică - operați pe rândurile unde x > 2, dar în primul caz, obțineți sum(y), în timp ce în al doilea caz actualizați acele rânduri pentru y cu suma sa cumulativă.

     La asta ne referim când spunem că forma DT[i, j, by] este consecventă.

   • În mod similar, în cazul (c), când avem condiția if-else, suntem capabili să exprimăm logica așa cum este atât în ​​data.table cât și în dplyr. Cu toate acestea, dacă dorim să returnăm doar acele rânduri în care condiția if satisface și să omitem altfel, nu putem folosi summarise() direct (AFAICT). Mai întâi trebuie să filter() și apoi să rezumam, deoarece summarise() se așteaptă întotdeauna la o valoare unică.

     În timp ce returnează același rezultat, folosirea filter() aici face ca operația reală să fie mai puțin evidentă.

     S-ar putea foarte bine să fie posibil să folosim filter() și în primul caz (nu mi se pare evident), dar ideea este că nu ar trebui să o facem.

2. Agregare/actualizare pe mai multe coloane

    # case (a)
    DT[, lapply(.SD, sum), by = z]                     ## data.table syntax
    DF %>% group_by(z) %>% summarise_each(funs(sum)) ## dplyr syntax
    DT[, (cols) := lapply(.SD, sum), by = z]
    ans <- DF %>% group_by(z) %>% mutate_each(funs(sum))
   
    # case (b)
    DT[, c(lapply(.SD, sum), lapply(.SD, mean)), by = z]
    DF %>% group_by(z) %>% summarise_each(funs(sum, mean))
   
    # case (c)
    DT[, c(.N, lapply(.SD, sum)), by = z]     
    DF %>% group_by(z) %>% summarise_each(funs(n(), mean))
   

   • În cazul (a), codurile sunt mai mult sau mai puțin echivalente. data.table folosește funcția de bază familiară lapply(), în timp ce dplyr introduce *_each() împreună cu o grămadă de funcții la funs().

   • := din data.table necesită ca numele coloanelor să fie furnizate, în timp ce dplyr le generează automat.

   • În cazul (b), sintaxa lui dplyr este relativ simplă. Îmbunătățirea agregărilor/actualizărilor pe mai multe funcții se află pe lista data.table.

   • În cazul (c), totuși, dplyr ar returna n() de câte ori mai multe coloane, în loc de doar o dată. În data.table, tot ce trebuie să facem este să returnăm o listă în j. Fiecare element al listei va deveni o coloană în rezultat. Deci, putem folosi, încă o dată, funcția de bază familiară c() pentru a concatena .N la un list care returnează un list.

   Notă: Încă o dată, în data.table, tot ce trebuie să facem este să returnăm o listă în j. Fiecare element al listei va deveni o coloană în rezultat. Puteți utiliza funcțiile de bază c(), as.list(), lapply(), list() etc... pentru a realiza acest lucru, fără a fi nevoie să învățați funcții noi.

   Va trebui să înveți doar variabilele speciale - .N și .SD cel puțin. Echivalentul în dplyr sunt n() și .

3. Se alătură

   dplyr oferă funcții separate pentru fiecare tip de unire, în cazul în care data.table permite îmbinări folosind aceeași sintaxă DT[i, j, by] (și cu motiv). De asemenea, oferă o funcție echivalentă merge.data.table() ca alternativă.

    setkey(DT1, x, y)
   
    # 1. normal join
    DT1[DT2]            ## data.table syntax
    left_join(DT2, DT1) ## dplyr syntax
   
    # 2. select columns while join    
    DT1[DT2, .(z, i.mul)]
    left_join(select(DT2, x, y, mul), select(DT1, x, y, z))
   
    # 3. aggregate while join
    DT1[DT2, .(sum(z) * i.mul), by = .EACHI]
    DF1 %>% group_by(x, y) %>% summarise(z = sum(z)) %>% 
        inner_join(DF2) %>% mutate(z = z*mul) %>% select(-mul)
   
    # 4. update while join
    DT1[DT2, z := cumsum(z) * i.mul, by = .EACHI]
    ??
   
    # 5. rolling join
    DT1[DT2, roll = -Inf]
    ??
   
    # 6. other arguments to control output
    DT1[DT2, mult = "first"]
    ??
   

• Unii ar putea găsi o funcție separată pentru fiecare unire mult mai plăcută (stânga, dreapta, interioară, anti, semi etc), în timp ce altora le-ar plăcea data.table DT[i, j, by] sau merge() care este similar cu baza R.

• Cu toate acestea, uniunile dplyr fac exact asta. Nimic mai mult. Nimic mai putin.

• data.tables poate selecta coloane în timp ce vă alăturați (2), iar în dplyr va trebui să select() mai întâi pe ambele data.frames înainte de a vă alătura, așa cum se arată mai sus. În caz contrar, ați materializa îmbinarea cu coloane inutile doar pentru a le elimina mai târziu și asta este ineficient.

• data.tables se pot agrega în timp ce se alătură utilizând caracteristica by = .EACHI (3) și, de asemenea, să se actualizeze în timp ce se alătură (4). De ce să materializați întregul rezultat al unirii pentru a adăuga/actualiza doar câteva coloane?

• data.table este capabil să rulează alăturari (5) - rulați înainte, LOCF, rulați înapoi, NOCB, cea mai apropiată.

• data.table are, de asemenea, argumentul mult = care selectează primul, ultimul sau toate potrivirile (6).

• data.table are argumentul allow.cartesian = TRUE pentru a fi protejat de alinările accidentale nevalide.

Încă o dată, sintaxa este în concordanță cu DT[i, j, by] cu argumente suplimentare care permit controlarea în continuare a ieșirii.

4. do()...

   Rezumatul dplyr este special conceput pentru funcții care returnează o singură valoare. Dacă funcția dvs. returnează valori multiple/inegale, va trebui să recurgeți la do(). Trebuie să știți în prealabil despre valoarea returnată a tuturor funcțiilor.

    DT[, list(x[1], y[1]), by = z]                 ## data.table syntax
    DF %>% group_by(z) %>% summarise(x[1], y[1]) ## dplyr syntax
    DT[, list(x[1:2], y[1]), by = z]
    DF %>% group_by(z) %>% do(data.frame(.$x[1:2], .$y[1]))
   
    DT[, quantile(x, 0.25), by = z]
    DF %>% group_by(z) %>% summarise(quantile(x, 0.25))
    DT[, quantile(x, c(0.25, 0.75)), by = z]
    DF %>% group_by(z) %>% do(data.frame(quantile(.$x, c(0.25, 0.75))))
   
    DT[, as.list(summary(x)), by = z]
    DF %>% group_by(z) %>% do(data.frame(as.list(summary(.$x))))
   

• Echivalentul lui .SD este .

• În data.table, puteți arunca aproape orice în j - singurul lucru de reținut este ca acesta să returneze o listă, astfel încât fiecare element al listei să fie convertit într-o coloană.

• În dplyr, nu pot face asta. Trebuie să recurgeți la do() în funcție de cât de sigur sunteți dacă funcția dvs. va returna întotdeauna o singură valoare. Și este destul de lent.

Încă o dată, sintaxa data.table este în concordanță cu DT[i, j, by]. Putem continua să aruncăm expresii în j fără să ne facem griji pentru aceste lucruri.

Aruncă o privire la această întrebare SO și la acesta. Mă întreb dacă ar fi posibil să exprim răspunsul la fel de simplu folosind sintaxa lui dplyr...

Pentru a rezuma, am evidențiat în special mai multe cazuri în care sintaxa lui dplyr este fie ineficientă, fie limitată sau nu reușește să facă operațiunile simple. Acest lucru se datorează în special pentru că data.table primește o reacție destul de mare în ceea ce privește sintaxa mai greu de citit/învățat (cum ar fi cea lipită/legată mai sus). Majoritatea postărilor care acoperă dplyr vorbesc despre cele mai simple operațiuni. Și asta este grozav. Dar este important să-și conștientizeze și limitările de sintaxă și caracteristici și încă nu am văzut o postare despre el.

data.table are și ciudateniile sale (unele dintre ele am subliniat că încercăm să le remediam). De asemenea, încercăm să îmbunătățim conexiunile data.table, deoarece am evidențiat aici.

Dar ar trebui să ia în considerare și numărul de caracteristici de care dplyr îi lipsește în comparație cu data.table.

4. Caracteristici

Am subliniat majoritatea funcțiilor aici și, de asemenea, în această postare. În plus:

• refă - cititorul rapid de fișiere este disponibil de mult timp.

• fwrite - un scriitor de fișiere rapid paralelizat este acum disponibil. Consultați această postare pentru o explicație detaliată a implementării și #1664 pentru a urmări evoluțiile ulterioare.

• Indexare automată - o altă caracteristică la îndemână pentru a optimiza sintaxa R de bază ca atare, pe plan intern.

• Gruparea ad-hoc: dplyr sortează automat rezultatele prin gruparea variabilelor în timpul summarise(), ceea ce poate să nu fie întotdeauna de dorit.

• Numeroase avantaje în îmbinările data.table (pentru viteză/eficiența memoriei și sintaxă) menționate mai sus.

• Asocieri non-equi: permite îmbinări folosind alți operatori <=, <, >, >= împreună cu toate celelalte avantaje ale îmbinărilor data.table.

• Întreunări de interval suprapuse a fost implementată recent în data.table. Consultați această postare pentru o prezentare generală cu benchmark-uri.

• setorder() în data.table care permite reordonarea rapidă a tabelelor de date prin referință.

• dplyr oferă interfață cu bazele de date folosind aceeași sintaxă, care data.table nu are momentan.

• data.table oferă echivalente mai rapide ale operațiunilor set (scrise de Jan Gorecki) - fsetdiff, fintersect, funion și fsetequal cu argument suplimentar all (ca în SQL).

• data.table se încarcă curat, fără avertismente de mascare și are un mecanism descris aici pentru compatibilitatea [.data.frame atunci când este transmis oricărui pachet R. dplyr modifică funcțiile de bază filter, lag și [ care pot cauza probleme; de exemplu. aici și aici.

In cele din urma:

• Pe baze de date - nu există niciun motiv pentru care data.table nu poate oferi o interfață similară, dar aceasta nu este o prioritate acum. S-ar putea crește dacă utilizatorii ar dori foarte mult această funcție... nu sunt sigur.

• Despre paralelism - Totul este dificil, până când cineva merge înainte și o face. Desigur, va fi nevoie de efort (fiind sigur pentru fire).

  • Progress is being made currently (in v1.9.7 devel) towards parallelising known time consuming parts for incremental performance gains using OpenMP.

Iată încercarea mea de a obține un răspuns cuprinzător din perspectiva dplyr, urmând schița generală a răspunsului lui Arun (dar oarecum rearanjat pe baza unor priorități diferite).

Sintaxă

Există o oarecare subiectivitate în ceea ce privește sintaxa, dar susțin afirmația mea că concizia data.table face mai greu de învățat și mai greu de citit. Acest lucru se datorează parțial pentru că dplyr rezolvă o problemă mult mai ușoară!

Un lucru cu adevărat important pe care dplyr îl face pentru dvs. este că vă constrânge opțiunile. Susțin că majoritatea problemelor unui singur tabel pot fi rezolvate cu doar cinci verbe cheie filtrare, selectare, mutare, aranjare și rezumare, împreună cu un adverb „după grup”. Această constrângere este de mare ajutor atunci când învățați manipularea datelor, deoarece vă ajută să vă ordonați gândirea despre problemă. În dplyr, fiecare dintre aceste verbe este mapat la o singură funcție. Fiecare funcție îndeplinește o singură funcție și este ușor de înțeles în mod izolat.

Creați complexitate prin conectarea acestor operații simple cu %>%. Iată un exemplu dintr-una dintre postările la care Arun a legat:

diamonds %>%
  filter(cut != "Fair") %>%
  group_by(cut) %>%
  summarize(
    AvgPrice = mean(price),
    MedianPrice = as.numeric(median(price)),
    Count = n()
  ) %>%
  arrange(desc(Count))

Chiar dacă nu ați mai văzut niciodată dplyr (sau chiar R!), puteți încă să înțelegeți esenta a ceea ce se întâmplă, deoarece funcțiile sunt toate verbe în limba engleză. Dezavantajul verbelor engleze este că necesită mai multă tastare decât [, dar cred că acest lucru poate fi atenuat în mare măsură printr-o completare automată mai bună.

Iată codul echivalent data.table:

diamondsDT <- data.table(diamonds)
diamondsDT[
  cut != "Fair", 
  .(AvgPrice = mean(price),
    MedianPrice = as.numeric(median(price)),
    Count = .N
  ), 
  by = cut
][ 
  order(-Count) 
]

Este mai greu să urmărești acest cod decât dacă ești deja familiarizat cu data.table. (De asemenea, nu mi-am putut da seama cum să indentează [ repetat într-un mod care să arate bine pentru ochiul meu). Personal, când mă uit la codul pe care l-am scris acum 6 luni, este ca și cum mă uit la un cod scris de un străin, așa că am ajuns să prefer un cod simplu, chiar dacă pronunțat.

Alți doi factori minori care cred că scad ușor lizibilitatea:

• Deoarece aproape fiecare operațiune de tabel de date utilizează [, aveți nevoie de context suplimentar pentru a afla ce se întâmplă. De exemplu, x[y] unește două tabele de date sau extrage coloane dintr-un cadru de date? Aceasta este doar o mică problemă, deoarece în codul bine scris numele variabilelor ar trebui să sugereze ce se întâmplă.

• Îmi place că group_by() este o operațiune separată în dplyr. Schimbă în mod fundamental calculul, așa că cred că ar trebui să fie evident la trecerea la trecere a codului și este mai ușor de observat group_by() decât argumentul by la [.data.table.

De asemenea, îmi place că teava nu se limitează doar la un singur pachet. Puteți începe prin a vă ordona datele cu tidyr și puteți termina cu o parcelă în ggvis. Și nu vă limitați la pachetele pe care le scriu - oricine poate scrie o funcție care formează o parte fără întreruperi a unei conducte de manipulare a datelor. De fapt, prefer mai degrabă codul data.table anterior rescris cu %>%:

diamonds %>% 
  data.table() %>% 
  .[cut != "Fair", 
    .(AvgPrice = mean(price),
      MedianPrice = as.numeric(median(price)),
      Count = .N
    ), 
    by = cut
  ] %>% 
  .[order(-Count)]

Iar ideea de canalizare cu %>% nu se limitează doar la cadre de date și este ușor de generalizat în alte contexte: grafică web interactivă, web scraping, ghists, contracte de funcționare, ...)

Memorie și performanță

Le-am adunat împreună, pentru că, pentru mine, nu sunt atât de importante. Majoritatea utilizatorilor R lucrează cu mai puțin de 1 milion de rânduri de date, iar dplyr este suficient de rapid pentru acea dimensiune de date pe care nu știi despre timpul de procesare. Optimizam dplyr pentru expresivitate pe date medii; nu ezitați să utilizați data.table pentru viteza brută pe date mai mari.

Flexibilitatea dplyr înseamnă, de asemenea, că puteți modifica cu ușurință caracteristicile de performanță folosind aceeași sintaxă. Dacă performanța dplyr cu backend-ul cadru de date nu este suficient de bună pentru dvs., puteți utiliza backend-ul data.table (deși cu un set oarecum restrâns de funcționalități). Dacă datele cu care lucrați nu se potrivesc în memorie, atunci puteți utiliza un backend de bază de date.

Toate acestea fiind spuse, performanța dplyr se va îmbunătăți pe termen lung. Cu siguranță vom implementa unele dintre ideile grozave ale data.table, cum ar fi ordonarea radix și utilizarea aceluiași index pentru îmbinări și filtre. De asemenea, lucrăm la paralelizare, astfel încât să putem profita de mai multe nuclee.

Caracteristici

Câteva lucruri la care intenționăm să lucrăm în 2015:

• pachetul readr, pentru a facilita preluarea fișierelor de pe disc și în memorie, similar cu fread().

• Uniri mai flexibile, inclusiv suport pentru uniuni non-equi.

• Grupare mai flexibilă, cum ar fi mostre bootstrap, pachete și multe altele

De asemenea, investesc timp în îmbunătățirea conectorii bazei de date ai lui R, abilitatea de a vorbi cu api-uri web și facilitează răzuire pagini html.