eindeutige Zeilen in dplyr : row_number() von tbl_dt inkonsistent, tbl_df

en bref:

Frage ich mich, wie man einzigartige Zeilen aus einer data.table im irgendwo entlang einer dplyr workflow. Seit v0.2, die ich verwenden kann row_number==1 (finden Sie unter: Entfernen Sie doppelte Zeilen mit dplyr)

ABER!

tbl_df(data) %>% group_by(Var1,Var2) %>% filter(row_number() == 1) funktioniert.

tbl_dt(data) %>% group_by(Var1,Var2) %>% filter(row_number() == 1) nicht. ist das ein bug?

setup:

library(dplyr)
library(data.table)
library(microbenchmark)

little <- expand.grid(rep(letters,121),rep(letters,121)) # my 10M row dataset.
tbl_dt(little) %>% group_by(Var1,Var2) %>% filter(row_number() == 1)

Ergebnis:

> Error in rank(x, ties.method = "first") : 
> argument "x" is missing, with no default

dies ist, wie ich eigentlich fand, dass es gebrochen. Ich wurde gefragt:

so oder so?

Ich kann die unique.data.table Methode:

 dt_u <- function() {
           tbl_dt(little) %>% 
           group_by(Var1,Var2) %>% 
           unique(.) %>% 
           tbl_dt(.) }

Kann ich verwenden summarise dann select Weg der neuen col:

dt_ss <- function() {
           tbl_dt(little) %>% 
           group_by(Var1,Var2) %>% 
           summarise( n = n() ) %>% 
           select( -(n) ) }

Kann ich verwenden row_number() == 1 # FUNKTIONIERT NICHT für tbl_dt!

 dt_rn <- function() {
           tbl_dt(little) %>% 
           group_by(Var1,Var2) %>% 
           filter( row_number() == 1 ) }

und so weiter mit der tbl_df() - äquivalente.

benchmarking die entsprechenden Daten.Tabelle /Daten.frame Methoden microbenchmark(...,times=20):

> Unit: milliseconds
>     expr       min        lq    median        uq       max neval
>  dt_ss()  579.0385  618.0002  661.9056  694.0705  764.2221    20
>  dt_u()   690.1284  729.8723  756.5505  783.7379  897.4799    20
>  df_ss()  419.7841  436.9871  448.1717  461.7023  523.2798    20
>  df_u()  3971.1699 4044.3663 4097.9848 4168.3468 4245.8346    20
>  df_rn()  646.1497  687.3472  711.3924  724.6235  754.3166    20
InformationsquelleAutor npjc | 2014-05-25
  1. 7

    Interessant. Deine benchmarks Spike mein Interesse. Ich finde es etwas merkwürdig, dass man Sie nicht vergleichen, gegen data.table's unique.data.table direkt. So, hier sind die Ergebnisse, indem Sie diese als gut auf meinem system. 

    # extra function with which the benchmark shown below was run
dt_direct <- function() unique(dt) # where dt = as.data.table(little)

# Unit: milliseconds
#         expr       min        lq    median        uq       max neval
#       dt_u() 1472.2460 1571.0871 1664.0476 1742.5184 2647.2118    20
#       df_u() 6084.2877 6303.9058 6490.1686 6844.8767 7370.3322    20
#      dt_ss() 1340.8479 1485.4064 1552.8756 1586.6706 1810.2979    20
#      df_ss()  799.5289  835.8599  884.6501  957.2208 1251.5994    20
#      df_rn() 1410.0145 1576.2033 1660.1124 1770.2645 2442.7578    20
#  dt_direct()  452.6010  463.6116  486.5015  568.0451  670.3673    20

    Es ist 1,8 x schneller als die Schnellste Lösung von allen Ihren Läufen.

    Nun vergrößern wir die Anzahl der eindeutigen Werte aus 676 bis etwa 10.000 und sehen, was passiert.

    val = paste0("V", 1:100)
little <- data.frame(Var1=sample(val, 1e7, TRUE), Var2=sample(val, 1e7, TRUE))
dt <- as.data.table(little)

# Unit: milliseconds
#         expr      min        lq    median        uq       max neval
#       dt_u() 1709.458 1776.3510 1892.7761 1991.6339 2562.9171    20
#       df_u() 7541.364 7735.4725 7981.3483 8462.9093 9552.8629    20
#      dt_ss() 1555.110 1627.6519 1791.5219 1911.3594 2299.2864    20
#      df_ss() 1436.355 1500.1043 1528.1319 1649.3043 1961.9945    20
#      df_rn() 2001.396 2189.5164 2393.8861 2550.2198 3047.7019    20
#  dt_direct()  508.596  525.7299  577.6982  674.2288  893.2116    20

    - Und hier, es ist 2,6 x schneller.

    Hinweis: ich habe nicht mal die Schaffung dt weil hier, im realen Einsatz Fällen, können Sie entweder fread zu bekommen Daten.Tabelle direkt, oder verwenden Sie setDT konvertieren data.table per Referenz oder direkt verwenden data.table(.) statt data.fame(.) - die ist nicht zeitlich als auch.

    Aber warum sind beide dt_u und dt_ss langsamer dann?

    Suchen Sie in der Datei grouped-dt.r und manip-grouped-dt.r dies geschieht, weil der 1) kopiert und 2) einstelltasten. (1) ist im Grunde, weil der mit zu tun (2). Wenn Sie eine zusammenfassen Betrieb mit dplyr, es ist äquivalent zu:

    DT <- copy(DT);
setkey(DT, <group_cols>  ## these two are in grouped_dt
DT[, j, by=<group_cols>] ## this is in summarise.grouped_dt
DT <- copy(DT)           ## because it calls grouped_dt AGAIN!
## and sets key again - which is O(n) now as DT checked if sorted first..

    Ich bin mir nicht sicher, warum ad-hoc - Gruppierung wurde nicht umgesetzt, nachdem diese Diskussion unter Hadey Antwort. 

    ## equivalent ad-hoc by
DT[, j, by=<group_cols] ## no copy, no setkey

    Vermeidet es sowohl Kopien als auch setting-Taste.

    Ist es sogar noch schlimmer, wenn Sie mutieren. Es ist effektiv zu tun:

    DT <- copy(DT)
setkey(DT, <group_cols>) ## these two are in grouped_dt
DT <- copy(DT)           ## mutate.grouped_dt copies copied data again
DT[, `:=`(...), by=<group_cols>] ## this is in mutate.grouped_dt
DT = copy(DT) ## because of another call to grouped_dt!!!
## and sets key again - which is O(n) now as DT is checked if sorted first..

    Hier nochmal die ad-hoc-Lösung ist einfach:

    DT   = copy(DT)
DT[, `:=`(...), by=group_cols]

    Vermeidet es 2 Kopien und das festlegen der Schlüssel.. Die nur kopieren gibt es zu Genüge dplyr-Philosophie nicht ändern von Objekten im Ort. So, das wird immer langsamer + unter bis zweimal die Speicher in dplyr.

    Ebenso Kopien auf einige joins können vermieden werden wie ich schon hier kommentiert.

    Die NACHRICHT aus dplyr v0.2 sagt:

    • dplyr vorsichtiger bei der Einstellung der Tasten von Daten-Tabellen, so dass es nicht versehentlich ein Objekt ändert, die es nicht besitzen. Es vermeidet auch unnötige key Einstellung die performance negativ beeinflusst. (#193, #255).

    Aber klar geraumer diskutierten Fällen nicht gemacht haben, es.

    Bisher schrieb ich über die performance-tag unter Ihrer Frage. Das ist, wenn Sie für die Leistung, die Sie sollten vermeiden, alle Fälle, die macht (überflüssige) Kopien (und-Einstellung-Tasten), bis es behoben ist.

    In diesem Wesen, in diesem speziellen Fall die beste Antwort, die ich konnte, ist einfach nur rufen Sie unique.data.table direkt in dplyrish Weg:

    tbl_dt(little) %>% unique(.)
    • angenommen, die Antwort b/c es wird auf meine zugrunde liegende Dilemma: dplyr ' s tbl_dt Geschmack lässt data.table Methoden safe + es ist code lesbar für nicht-erfahrene / breiteste Publikum, das ist mir wichtig. Das sagte ich auch wollen, um sicherzustellen, ich bin mit diesen tools richtig/effizient auf meine mem-data-size.
    • vergessen zu erwähnen: ich habe nicht den direkten Aufruf unique.data.table gerade weil ich versuche zu verstehen, die Auswirkungen der group_by() "Einstellung acitons" und tbl_dt() "Nötigung " Aktionen". Das ist genau das, was Sie erklärt haben und damit das Häkchen, danke.
    • Ich bin froh, das zu akzeptieren, pull-requests...
    InformationsquelleAutor Arun
  2. 0

    Ich lief in dieses problem, und eine neue Lösung gefunden hier, die slice.

    Ich lief einige zusätzliche benchmarks, die auf Ihrem dataset, einschließlich die neue slice-Funktion und ändern dt_rn so dass es zwingt zu einer data.frame erste:

    little <- expand.grid(rep(letters,121),rep(letters,121)) # my 10M row dataset.

dt_u <- function() {
    tbl_dt(little) %>% 
        group_by(Var1,Var2) %>% 
        unique(.) %>% 
        tbl_dt(.) }

dt_rn_df <- function() {
    tbl_dt(little) %>% 
        data.frame() %>%
        group_by(Var1,Var2) %>% 
        filter( row_number() == 1 ) }

dt_slice <- function() {
    tbl_dt(little) %>% 
        group_by(Var1,Var2) %>% 
        slice(1) }
dt_direct <- function() {
    unique(tbl_dt(little), by = c('Var1', 'Var2'))
}

    Benchmarking gibt:

    > microbenchmark(dt_u(), dt_rn_df(), dt_slice(), dt_direct())
Unit: milliseconds
        expr      min       lq     mean   median       uq      max neval
      dt_u() 167.4490 173.1940 204.5868 194.1807 212.0271 459.0929   100
  dt_rn_df() 639.9241 648.6655 683.3479 683.9603 702.5198 810.2335   100
  dt_slice() 163.1873 167.5379 190.2340 195.3807 201.0327 314.0943   100
 dt_direct() 156.9491 159.8089 184.3647 184.4096 188.6268 326.4955   100

    Auf Ihre Daten legen-ich finde, dass alle Funktionen, außer für die Nötigung zu einer data.frame dauert ungefähr die gleiche Zeit. Insbesondere habe ich nicht die deutliche Steigerungen in der Geschwindigkeit, wie die von Arun bei der Verwendung dt_direct dem Hinweis, dass meine version von diese Funktion ruft unique(..., by = ...).

    Jedoch auf einem anderen Daten-Tabelle mit 1,6 Millionen Zeilen und 28 Spalten, ich finde, dass die Nötigung zu einer data.frame ist tatsächlich schneller, siehe (keine Daten vorhanden):

    > microbenchmark(df2_processed_f <-
+     df2_processed %>%
+     data.frame() %>%
+     dplyr::group_by(v21, v23, v26) %>%
+     filter(row_number() == 1),
+ 
+ 
+ df2_processed_dt <-
+   df2_processed %>%
+   dplyr::group_by(v21, v23, v26) %>%
+   dplyr::slice(1))
Unit: milliseconds
                                                                                                                    expr
 df2_processed_f <- df2_processed %>% data.frame() %>% dplyr::group_by(v21,      v23, v26) %>% filter(row_number() == 1)
                           df2_processed_dt <- df2_processed %>% dplyr::group_by(v21, v23,      v26) %>% dplyr::slice(1)
      min       lq     mean   median       uq      max neval
 411.7717 428.4515 491.9315 462.4099 515.8156 702.2607   100
 663.5383 676.7824 699.3258 683.2407 693.7743 933.8118   100
    InformationsquelleAutor Alex
Schreibe einen Kommentar