tutorial - ¿Por qué los pandas se fusionan en python más rápido que data.table combina en R?

recorrer data frame pandas

Question

Hace poco encontré la biblioteca de pandas para python, que según este punto de referencia realiza fusiones en memoria muy rápidas. Es incluso más rápido que el paquete data.table en R (mi lenguaje de elección para el análisis).

¿Por qué los pandas son mucho más rápidos que data.table ? ¿Es por una ventaja de velocidad inherente que python tiene sobre R, o hay alguna compensación de la que no tengo conocimiento? ¿Hay alguna forma de realizar uniones internas y externas en data.table sin recurrir a merge(X, Y, all=FALSE) y merge(X, Y, all=TRUE) ?

Aquí está el código R y el código Python utilizado para comparar los diversos paquetes.

Answer 1

Este tema tiene dos años pero parece un lugar probable para que las personas aterricen cuando buscan comparaciones de Pandas y data.table

Dado que ambos han evolucionado con el tiempo, deseo publicar aquí una comparación relativamente nueva (desde 2014) para los usuarios interesados: github.com/Rdatatable/data.table/wiki/Benchmarks-:-Grouping

Sería interesante saber si Wes y / o Matt (que, dicho sea de paso, son creadores de Pandas y datatable, respectivamente y han comentado anteriormente) tienen alguna noticia para agregar aquí también.

- ACTUALIZACIÓN -

Un comentario publicado a continuación por jangorecki contiene un enlace que creo que es muy útil: https://github.com/szilard/benchm-databases

Este gráfico muestra los tiempos promedio de agregación y operaciones de combinación para diferentes tecnologías ( más bajo = más rápido ; la comparación se actualizó por última vez en septiembre de 2016). Fue realmente educativo para mí.

Volviendo a la pregunta, la R DT key y R DT refieren a los sabores codificados / no leídos de la tabla de datos de R y resultan ser más rápidos en este punto de referencia que los pandas de Python ( Py pandas ).

Answer 2

La razón por la que los pandas son más rápidos es porque se me ocurrió un algoritmo mejor, que se implementa muy cuidadosamente utilizando una implementación rápida de la tabla hash - klib y en C / Cython para evitar la sobrecarga del intérprete Python para las partes no vectorizables. El algoritmo se describe con cierto detalle en mi presentación: una mirada al diseño y desarrollo de los pandas .

La comparación con data.table es en realidad un poco interesante porque el objetivo de la data.table de data.table de R es que contiene índices data.table para varias columnas para acelerar operaciones como la selección y fusión de datos. En este caso (las uniones de base de datos) panda DataFrame no contiene información pre-calculada que se está utilizando para la fusión, por así decirlo, es una combinación "fría". Si hubiera almacenado las versiones factorizadas de las claves de combinación, la unión sería significativamente más rápida, ya que la factorización es el mayor cuello de botella para este algoritmo.

También debo agregar que el diseño interno del DataFrame de los pandas es mucho más adecuado para este tipo de operaciones que el data.frame de R (que es solo una lista de arreglos internos).

Answer 3

Parece que Wes pudo haber descubierto un problema conocido en data.table cuando la cantidad de strings ( levels ) únicos es grande: 10,000.

¿ Rprof() revela la mayor parte del tiempo pasado en la llamada sortedmatch(levels(i[[lc]]), levels(x[[rc]]) ? Esto no es realmente la unión en sí misma (el algoritmo), sino una paso preliminar

Se han realizado esfuerzos recientes para permitir columnas de caracteres en las claves, lo que debería resolver ese problema al integrarse más estrechamente con la tabla de hash de cadenas global propia de R. Algunos resultados de referencia ya han sido informados por test.data.table() pero ese código aún no está conectado para reemplazar los niveles por la coincidencia de niveles.

¿Los pandas se data.table más rápido que data.table para columnas enteras regulares? Esa debería ser una forma de aislar el algoritmo en sí mismo frente a los problemas de los factores.

Además, data.table tiene en cuenta las series de tiempo . Dos aspectos para eso: i) claves ordenadas de varias columnas como (id, datetime) ii) unión predominantemente rápida ( roll=TRUE ) también conocida como la última observación realizada.

Necesitaré algo de tiempo para confirmar, ya que es la primera vez que veo la comparación con data.table como se presentó.

ACTUALIZACIÓN de data.table v1.8.0 publicado en julio de 2012

• La función interna sortedmatch () se elimina y se reemplaza por chmatch () cuando se combinan i niveles a x niveles para columnas de tipo ''factor''. Este paso preliminar estaba causando una desaceleración significativa (conocida) cuando el número de niveles de una columna de factores era grande (p. Ej.> 10,000). Exacerbado en las pruebas de unir cuatro de tales columnas, como lo demostró Wes McKinney (autor del paquete de Python Pandas). La combinación de 1 millón de cadenas de las cuales 600,000 son únicas ahora se reduce de 16 a 0.5 s, por ejemplo.

también en ese lanzamiento fue:

• las columnas de caracteres ahora están permitidas en las claves y se prefieren al factor. data.table () y setkey () ya no fuerzan el carácter al factor. Los factores aún son compatibles. Implementa FR # 1493, FR # 1224 y (parcialmente) FR # 951.

• Nuevas funciones chmatch () y% chin%, versiones más rápidas de match () y% en% para vectores de caracteres. Se utiliza el caché de cadenas interno de R (no se construye una tabla hash). Son aproximadamente 4 veces más rápido que match () en el ejemplo de? Chmatch.

A partir de septiembre de 2013 data.table es v1.8.10 en CRAN y estamos trabajando en v1.9.0. NEWS se actualiza en vivo.

Pero como escribí originalmente, arriba:

data.table tiene una combinación de series de tiempo en mente. Dos aspectos para eso: i) claves ordenadas de varias columnas como (id, datetime) ii) unión predominantemente rápida ( roll=TRUE ) también conocida como la última observación realizada.

Por lo tanto, la combinación de Pandas equi de dos columnas de caracteres probablemente sea aún más rápida que data.table. Ya que suena como hash las dos columnas combinadas. data.table no copia la clave porque tiene en cuenta las combinaciones ordenadas predominantes. Una "clave" en data.table es literalmente solo el orden de clasificación (similar a un índice agrupado en SQL, es decir, así es como se ordenan los datos en la RAM). En la lista está agregar claves secundarias, por ejemplo.

En resumen, la evidente diferencia de velocidad destacada por esta prueba particular de columna de dos caracteres con más de 10 000 cadenas únicas no debería ser tan mala ahora, ya que el problema conocido se ha solucionado.