data.table vs dplyr: ¿puede uno hacer algo bien y el otro no puede o lo hace mal?

Este es mi intento de obtener una respuesta integral desde la perspectiva de dplyr, siguiendo el esquema general de la respuesta de Arun (pero algo reorganizado en función de las diferentes prioridades).

Sintaxis

Hay cierta subjetividad en la sintaxis, pero mantengo mi afirmación de que la concisión de data.table hace que sea más difícil de aprender y más difícil de leer. ¡Esto es en parte porque dplyr está resolviendo un problema mucho más fácil!

Una cosa realmente importante que dplyr hace por usted es que limita sus opciones. Afirmo que la mayoría de los problemas de una sola tabla se pueden resolver con solo cinco verbos clave que filtran, seleccionan, mutan, organizan y resumen, junto con un adverbio "por grupo". Esa restricción es de gran ayuda cuando está aprendiendo manipulación de datos, porque ayuda a ordenar su pensamiento sobre el problema. En dplyr, cada uno de estos verbos se asigna a una sola función. Cada función hace un trabajo y es fácil de entender de forma aislada.

Usted crea complejidad al canalizar estas operaciones simples junto con %>% . Aquí hay un ejemplo de una de las publicaciones a las que Arun ha vinculado :

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

Incluso si nunca antes has visto dplyr (¡o incluso R!), Puedes entender lo que está sucediendo porque las funciones son verbos en inglés. La desventaja de los verbos en inglés es que requieren más mecanografía que [ , pero creo que eso se puede mitigar en gran medida con un autocompletado mejor.

Aquí está el código equivalente data.table:

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

Es más difícil seguir este código a menos que ya esté familiarizado con data.table. (Tampoco pude averiguar cómo sangrar lo repetido [ de una manera que se vea bien a mis ojos). Personalmente, cuando miro el código que escribí hace 6 meses, es como mirar un código escrito por un extraño, por lo que prefiero el código directo, aunque detallado.

Otros dos factores menores que creo que disminuyen ligeramente la legibilidad:

• Dado que casi todas las operaciones de la tabla de datos utilizan [ se necesita un contexto adicional para descubrir qué está sucediendo. Por ejemplo, ¿ x[y] une dos tablas de datos o extrae columnas de un marco de datos? Esto es solo un pequeño problema, porque en un código bien escrito los nombres de las variables deberían sugerir lo que está sucediendo.

• Me gusta que group_by() es una operación separada en dplyr. Cambia fundamentalmente el cálculo, por lo que creo que debería ser obvio cuando se hojea el código, y es más fácil detectar group_by() que el argumento by a [.data.table .

También me gusta que la tubería no se limite a un solo paquete. Puede comenzar por ordenar sus datos con tidyr y terminar con un gráfico en ggvis . Y no está limitado a los paquetes que escribo, cualquiera puede escribir una función que forme una parte perfecta de una tubería de manipulación de datos. De hecho, prefiero el código anterior de data.table reescrito con %>% :

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

Y la idea de canalizar con %>% no se limita solo a marcos de datos y se generaliza fácilmente a otros contextos: gráficos web interactivos , raspado web , gists , contratos de tiempo de ejecución , ...)

Memoria y rendimiento

Los he agrupado juntos porque, para mí, no son tan importantes. La mayoría de los usuarios de R trabajan con menos de 1 millón de filas de datos, y dplyr es lo suficientemente rápido para ese tamaño de datos que no conoce el tiempo de procesamiento. Optimizamos dplyr para expresividad en datos medianos; siéntase libre de usar data.table para velocidad sin procesar en datos más grandes.

La flexibilidad de dplyr también significa que puede modificar fácilmente las características de rendimiento utilizando la misma sintaxis. Si el rendimiento de dplyr con el backend del marco de datos no es lo suficientemente bueno para usted, puede usar el backend data.table (aunque con un conjunto de funciones algo restringido). Si los datos con los que está trabajando no caben en la memoria, entonces puede usar una base de datos backend.

Dicho todo esto, el rendimiento de dplyr mejorará a largo plazo. Definitivamente implementaremos algunas de las grandes ideas de data.table como el ordenamiento de radix y el uso del mismo índice para uniones y filtros. También estamos trabajando en la paralelización para poder aprovechar los múltiples núcleos.

Caracteristicas

Algunas cosas en las que planeamos trabajar en 2015:

• el paquete de readr , para facilitar la obtención de archivos del disco y en la memoria, de forma análoga a fread() .

• Uniones más flexibles, incluido el soporte para uniones no equitativas.

• Agrupación más flexible como muestras de bootstrap, rollups y más

También estoy invirtiendo tiempo en mejorar los conectores de la base de datos de R, la capacidad de hablar con las API web y facilitar el raspado de páginas HTML .