Нам необходимо охватить по крайней мере эти аспекты, чтобы дать исчерпывающий ответ / сравнение (без определенного порядка важности): Speed, Memory usage, Syntax и Features.

Я намерен максимально четко осветить каждый из них с точки зрения таблицы данных.

Примечание: если явно не указано иное, ссылаясь на dplyr, мы ссылаемся на интерфейс dplyr data.frame, внутреннее устройство которого находится на C ++ с использованием Rcpp.

Синтаксис data.table согласован по форме - DT[i, j, by]. Сохранять вместе i, j и by - это задумано. Сохраняя связанные операции вместе, он позволяет легко оптимизировать операции для скорости и, что более важно, использования памяти, а также предоставляет некоторые мощные функции при сохранении единообразия синтаксиса.

1. Скорость

К вопросу, уже показывающему, что data.table становится быстрее, чем dplyr, было добавлено довольно много тестов (хотя в основном по операциям группировки) по количеству групп и / или строк для группировки по увеличению, включая тесты Мэтта по группировке от 10 миллионов до 2 миллиардов строк (100 ГБ ОЗУ) для 100–10 миллионов групп и различных столбцов группировки, что также позволяет сравнить pandas. См. Также обновленные тесты производительности, которые также включают Spark и pydatatable.

Что касается тестов, было бы неплохо охватить и эти оставшиеся аспекты:

• Операции группирования, включающие подмножество строк, т. Е. Операции типа DT[x > val, sum(y), by = z].

• Сравните другие операции, такие как обновление и присоединение.

• Также проверьте объем памяти для каждой операции в дополнение к времени выполнения.

2. Использование памяти

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. Агрегировать при присоединении:

   Предположим, у вас есть две таблицы data.tables, как показано ниже:

    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
   

   И вы хотите получить sum(z) * mul для каждой строки в DT2 при объединении по столбцам x,y. Мы можем либо:

   • 1. агрегировать DT1, чтобы получить sum(z), 2) выполнить соединение и 3) умножить (или)

        data.table способ

        DT1 [,. (Z = sum (z)), keyby =. (X, y)] [DT2] [, z: = z * mul] []

        эквивалент dplyr

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

   • 2. сделайте все за один раз (используя функцию by = .EACHI):

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

   В чем преимущество?

   • Нам не нужно выделять память для промежуточного результата.

   • Нам не нужно дважды группировать / хешировать (один для агрегации, а другой для присоединения).

   • И что еще более важно, операция, которую мы хотели выполнить, становится понятной, если посмотреть на j в (2).

   Подробное описание by = .EACHI см. В этом сообщении. Никаких промежуточных результатов не материализуется, и объединение + агрегирование выполняется за один раз.

   Взгляните на this, this и this публикуют сообщения для реальных сценариев использования.

   В dplyr вам нужно будет сначала присоединиться и агрегировать или агрегировать, а затем присоединиться, ни одно из которых не является эффективен с точки зрения памяти (что, в свою очередь, означает скорость).

4. Обновление и присоединение:

   Рассмотрим код data.table, показанный ниже:

    DT1[DT2, col := i.mul]
   

   добавляет / обновляет столбец DT1 col на mul из DT2 в тех строках, где ключевой столбец DT2 совпадает с DT1. Я не думаю, что есть точный эквивалент этой операции в dplyr, т.е. без исключения *_join операции, которая должна была бы скопировать весь DT1 только для того, чтобы добавить к нему новый столбец, что не нужно.

   Проверьте этот пост, чтобы узнать о реальном сценарии использования.

Подводя итог, важно понимать, что каждый бит оптимизации имеет значение. Как сказала бы Грейс Хоппер, Не забывайте о наносекундах!

3. Синтаксис

Теперь посмотрим на синтаксис. Хэдли прокомментировал здесь:

Таблицы данных работают очень быстро, но я думаю, что из-за их краткости их труднее изучать, а код, который их использует, труднее читать после того, как вы его написали ...

Я считаю это замечание бессмысленным, потому что оно очень субъективно. Возможно, мы можем попробовать противопоставить согласованность синтаксиса. Мы сравним синтаксис data.table и dplyr бок о бок.

Мы будем работать с фиктивными данными, показанными ниже:

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

1. Основные операции агрегирования / обновления.

    # 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])
   

   • Синтаксис data.table компактен и довольно многословен в dplyr. В случае (а) все более или менее эквивалентно.

   • В случае (b) нам пришлось использовать filter() в dplyr при подведении итогов. Но при обновлении нам пришлось переместить логику внутрь mutate(). Однако в data.table мы выражаем обе операции с одинаковой логикой - работаем со строками, где x > 2, но в первом случае получаем sum(y), тогда как во втором случае обновляем эти строки для y с его совокупной суммой.

     Это то, что мы имеем в виду, когда говорим, что форма DT[i, j, by] согласована.

   • Точно так же в случае (c), когда у нас есть if-else условие, мы можем выразить логику как есть как в data.table, так и в dplyr. Однако, если мы хотим вернуть только те строки, которым удовлетворяет условие if, и пропустить в противном случае, мы не можем использовать summarise() напрямую (AFAICT). Мы должны сначала filter(), а затем подвести итоги, потому что summarise() всегда ожидает единственного значения.

     Хотя он возвращает тот же результат, использование здесь filter() делает фактическую операцию менее очевидной.

     Вполне возможно использовать filter() и в первом случае (мне это не кажется очевидным), но я считаю, что мы не должны этого делать.

2. Агрегация / обновление по нескольким столбцам

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

   • В случае (а) коды более или менее эквивалентны. data.table использует знакомую базовую функцию lapply(), тогда как dplyr вводит *_each() вместе с набором функций для funs().

   • := для data.table требует, чтобы имена столбцов были указаны, тогда как dplyr генерирует их автоматически.

   • В случае (b) синтаксис dplyr относительно прост. Улучшение агрегирования / обновления для нескольких функций находится в списке data.table.

   • Однако в случае (c) dplyr вернет n() столько столбцов, а не только один раз. В data.table все, что нам нужно сделать, это вернуть список в j. Каждый элемент списка станет столбцом в результате. Итак, мы можем снова использовать знакомую базовую функцию c() для объединения .N в list, который возвращает list.

   Примечание. Еще раз, в data.table все, что нам нужно сделать, это вернуть список в j. В результате каждый элемент списка станет столбцом. Для этого вы можете использовать базовые функции c(), as.list(), lapply(), list() и т. Д., Без необходимости изучать какие-либо новые функции.

   Вам нужно будет изучить только специальные переменные - по крайней мере, .N и .SD. Эквивалентными в dplyr являются n() и .

3. Присоединяется

   dplyr предоставляет отдельные функции для каждого типа соединения, в то время как data.table позволяет объединять с использованием того же синтаксиса DT[i, j, by] (и с обоснованием). В качестве альтернативы он также предоставляет эквивалентную функцию merge.data.table().

    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"]
    ??
   

• Некоторые могут найти более удобную отдельную функцию для каждого соединения (левое, правое, внутреннее, анти, полу и т. Д.), В то время как другим может понравиться DT[i, j, by] или merge() data.table, который похож на базовый R.

• Однако присоединения dplyr именно так и делают. Больше ничего. Не меньше.

• data.tables может выбирать столбцы при объединении (2), и в dplyr вам нужно сначала select() на обоих data.frames, прежде чем присоединяться, как показано выше. В противном случае вы материализуете соединение с ненужными столбцами только для того, чтобы удалить их позже, а это неэффективно.

• data.tables могут объединяться при объединении с помощью функции by = .EACHI (3), а также обновляться при объединении (4). Зачем материализовать весь результат соединения, чтобы добавить / обновить всего несколько столбцов?

• data.table поддерживает скользящие соединения (5) - прокрутите вперед, LOCF, откат назад, NOCB, ближайший .

• data.table также имеет аргумент mult =, который выбирает первое, последнее или все совпадения (6).

• data.table имеет аргумент allow.cartesian = TRUE для защиты от случайных недопустимых объединений.

И снова синтаксис соответствует DT[i, j, by] с дополнительными аргументами, позволяющими дополнительно контролировать вывод.

4. do()...

   Summarize dplyr специально разработан для функций, возвращающих одно значение. Если ваша функция возвращает несколько / неравных значений, вам придется прибегнуть к do(). Вы должны заранее знать обо всех возвращаемых вами значениях функций.

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

• .SD эквивалент .

• В data.table вы можете бросить почти все что угодно в j - единственное, что нужно помнить, - это возвращать список, чтобы каждый элемент списка преобразовывался в столбец.

• В dplyr этого сделать нельзя. Придется прибегать к do() в зависимости от того, насколько вы уверены в том, всегда ли ваша функция будет возвращать одно значение. И это довольно медленно.

И снова синтаксис data.table соответствует DT[i, j, by]. Мы можем просто добавлять выражения в j, не беспокоясь об этих вещах.

Взгляните на этот вопрос SO и этот. Интересно, можно ли было бы выразить ответ настолько просто, используя синтаксис dplyr ...

Подводя итог, я особо выделил несколько случаев, когда синтаксис dplyr либо неэффективен, либо ограничен, либо не может упростить операции. Это особенно связано с тем, что data.table получает довольно много негативной реакции из-за того, что синтаксис сложнее читать / изучать (например, тот, который вставлен / связан выше). В большинстве постов, посвященных dplyr, говорится о самых простых операциях. И это здорово. Но также важно понимать его синтаксис и ограничения функций, и я еще не видел сообщения об этом.

data.table также имеет свои причуды (некоторые из которых, как я уже отмечал, мы пытаемся исправить). Мы также пытаемся улучшить соединения data.table, как я выделил здесь.

Но следует также учитывать количество функций, которых не хватает dplyr по сравнению с data.table.

4. Особенности

Я указал на большинство функций здесь, а также в этом сообщении. Кроме того:

• fread - быстрая программа для чтения файлов доступна уже давно.

• fwrite - теперь доступна распараллеленная быстрая запись файлов. См. этот пост для подробного объяснения реализации. и # 1664 для отслеживания дальнейших разработок.

• Автоматическое индексирование - еще одна удобная функция для внутренней оптимизации базового синтаксиса R.

• Специальная группировка: dplyr автоматически сортирует результаты, группируя переменные в течение summarise(), что может быть не всегда желательно.

• Упомянутые выше многочисленные преимущества объединений data.table (для скорости / эффективности использования памяти и синтаксиса).

• Неэквивалентные соединения: разрешает соединения с использованием других операторов <=, <, >, >= наряду со всеми другими преимуществами соединений data.table.

• Объединение перекрывающихся диапазонов было недавно реализовано в data.table. Ознакомьтесь с этим сообщением для обзора тестов.

• setorder() функция в data.table, которая позволяет очень быстро переупорядочивать data.tables по ссылке.

• dplyr предоставляет интерфейс для баз данных с использованием того же синтаксиса, что и data.table на данный момент отсутствует.

• data.table обеспечивает более быстрые эквиваленты операций с множеством (написано Яном Горецки) - fsetdiff, fintersect, funion и fsetequal с дополнительным аргументом all (как в SQL).

• data.table загружается чисто, без предупреждений о маскировании и имеет механизм, описанный здесь для [.data.frame совместимости при передаче в любой пакет R. dplyr изменяет базовые функции filter, lag и [, что может вызвать проблемы; например здесь и здесь.

Наконец-то:

• В базах данных - нет причин, по которым data.table не может предоставить аналогичный интерфейс, но сейчас это не является приоритетом. Это могло бы быть увеличено, если бы пользователям очень понравилась эта функция ... не уверен.

• О параллелизме - Все сложно, пока кто-то не пойдет вперед и не сделает. Конечно, это потребует усилий (потокобезопасность).

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

Вот моя попытка дать исчерпывающий ответ с точки зрения dplyr, следуя общей схеме ответа Аруна (но несколько перестроенной на основе разных приоритетов).

Синтаксис

В синтаксисе есть некоторая субъективность, но я придерживаюсь своего утверждения о том, что краткость data.table затрудняет изучение и затрудняет чтение. Отчасти это потому, что dplyr решает гораздо более простую задачу!

Одна действительно важная вещь, которую делает для вас dplyr, - это то, что он ограничивает ваши возможности. Я утверждаю, что большинство задач с одной таблицей можно решить с помощью всего лишь пяти ключевых глаголов: фильтра, выбора, изменения, упорядочивания и суммирования, а также наречия «по группе». Это ограничение очень помогает, когда вы изучаете манипулирование данными, потому что оно помогает упорядочить ваши размышления о проблеме. В dplyr каждый из этих глаголов отображается на одну функцию. Каждая функция выполняет одну работу, и ее легко понять по отдельности.

Вы создаете сложность, объединяя эти простые операции вместе с %>%. Вот пример из одного из сообщений Аруна, связанных с:

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

Даже если вы никогда раньше не видели dplyr (или даже R!), Вы все равно можете понять суть происходящего, потому что все функции - это английские глаголы. Недостаток английских глаголов состоит в том, что они требуют большего набора текста, чем [, но я думаю, что это можно в значительной степени смягчить за счет лучшего автозаполнения.

Вот эквивалентный код data.table:

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

Сложнее следовать этому коду, если вы еще не знакомы с data.table. (Я также не мог понять, как сделать отступ повторяющегося [ таким образом, чтобы он выглядел хорошо для моего глаза). Лично я смотрю на код, который написал 6 месяцев назад, это все равно что смотреть на код, написанный незнакомцем, поэтому я предпочел простой, хотя и подробный, код.

Два других незначительных фактора, которые, как мне кажется, немного ухудшают читаемость:

• Поскольку почти каждая операция с таблицей данных использует [, вам нужен дополнительный контекст, чтобы понять, что происходит. Например, x[y] объединение двух таблиц данных или извлечение столбцов из фрейма данных? Это небольшая проблема, потому что в хорошо написанном коде имена переменных должны подсказывать, что происходит.

• Мне нравится, что group_by() - это отдельная операция в dplyr. Это коренным образом меняет вычисления, поэтому я думаю, что это должно быть очевидно при просмотре кода, и легче заметить group_by(), чем аргумент by для [.data.table.

Мне также нравится, что канал не ограничен только одним пакетом. Вы можете начать с очистки данных с помощью tidyr, а закончить с сюжет в ggvis. И вы не ограничены пакетами, которые я пишу - любой может написать функцию, которая образует бесшовную часть конвейера обработки данных. Фактически, я предпочитаю предыдущий код data.table, переписанный с %>%:

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

Идея соединения с %>% не ограничивается только фреймами данных и легко обобщается на другие контексты: интерактивная веб-графика, веб-скрапинг, gists, контракты времени выполнения, ...)

Память и производительность

Я собрал их вместе, потому что для меня они не так важны. Большинство пользователей R работают с менее чем 1 миллионом строк данных, и dplyr достаточно быстр для такого размера данных, время обработки которого вы не знаете. Оптимизируем dplyr для выразительности на средних данных; не стесняйтесь использовать data.table для получения чистой скорости на больших данных.

Гибкость dplyr также означает, что вы можете легко настроить характеристики производительности, используя тот же синтаксис. Если производительность dplyr с бэкэндом фрейма данных для вас недостаточна, вы можете использовать бэкэнд data.table (хотя и с несколько ограниченным набором функций). Если данные, с которыми вы работаете, не помещаются в памяти, вы можете использовать серверную часть базы данных.

При этом производительность dplyr в долгосрочной перспективе улучшится. Мы обязательно реализуем некоторые из замечательных идей data.table, такие как порядок оснований счисления и использование того же индекса для объединений и фильтров. Мы также работаем над распараллеливанием, чтобы использовать преимущества нескольких ядер.

Функции

Несколько вещей, над которыми мы планируем работать в 2015 году:

• пакет readr, чтобы упростить перенос файлов с диска в память, аналогично fread().

• Более гибкие соединения, включая поддержку неэквивалентных соединений.

• Более гибкая группировка, например образцы начальной загрузки, накопительные пакеты и т. Д.

Я также трачу время на улучшение коннекторов баз данных в R, возможности общения с API-интерфейсы и упрощение очистить HTML-страницы.