¿Los pandas ahora son más rápidos que data.table?

16

https://github.com/Rdatatable/data.table/wiki/Benchmarks-%3A-Grouping

Los puntos de referencia data.table no se han actualizado desde 2014. Escuché en algún lugar que Pandasahora es más rápido que data.table. ¿Es esto cierto? ¿Alguien ha hecho alguna referencia? ¿Nunca he usado Python antes pero consideraría cambiar si pandaspuede vencer data.table?

— xiaodai
fuente

77

Esa es una muy mala razón para cambiar a Python.

— Matthew Drury el

2

@MatthewDrury ¿cómo es eso? Los datos y su manipulación son el 80% de mi trabajo. Solo el 20% corresponde a modelos y presentación adecuados. ¿Por qué no debería elegir el que me da los resultados más rápido?

— xiaodai

2

Python y R son lenguajes establecidos con enormes ecosistemas y comunidades. Reducir la elección a una sola biblioteca es adorar a un solo árbol en un vasto bosque. Aun así, la eficiencia es solo una preocupación entre muchos, incluso para una sola biblioteca (cuán expresiva es la interfaz, cómo se conecta a otra biblioteca, cuán extensible es la base de código, qué tan abiertos son sus desarrolladores). Yo diría que la elección en sí es una falsa dicotomía; ambas comunidades tienen un enfoque diferente, lo que le da a los idiomas diferentes fortalezas.

— Matthew Drury el

3

Tienes un bosque enorme que es bueno para el 20% del trabajo? entonces, ¿no eliges el 80% de tu trabajo? nada me impide usar panda para hacer la preparación de datos y luego modelar en R python o Julia. Creo que mi pensamiento es sólido. si panda es más rápido de lo que debería elegirlo como mi herramienta principal.

— xiaodai

1

Puede encontrar el paquete reticulado en R de interés / uso. Además, cada vez se ha hecho un gran esfuerzo para que R trabaje / juegue con bases de datos (ver esfuerzos como dbplyr ).

— slackline

15

¿Alguien ha hecho alguna referencia?

Sí, el punto de referencia que ha vinculado en su pregunta se ha actualizado recientemente para la versión reciente de data.table y pandas. Además se ha agregado otro software. Puede encontrar un punto de referencia actualizado en https://h2oai.github.io/db-benchmark
Lamentablemente, está programado en una máquina de memoria de 125 GB (no 244 GB como el original). Como resultado, los pandas y dask no pueden intentar datos de groupby1e9 filas (50GB csv) porque se quedan sin memoria al leer los datos. Entonces, para pandas vs data.table, debe mirar datos de 1e8 filas (5GB).

Para no solo vincular el contenido que está solicitando, pego los tiempos recientes para esas soluciones.

tenga en cuenta que esos horarios están desactualizados,
visite https://h2oai.github.io/db-benchmark para ver los horarios actualizados

| in_rows|question              | data.table| pandas|
|-------:|:---------------------|----------:|------:|
|   1e+07|sum v1 by id1         |      0.140|  0.414|
|   1e+07|sum v1 by id1:id2     |      0.411|  1.171|
|   1e+07|sum v1 mean v3 by id3 |      0.574|  1.327|
|   1e+07|mean v1:v3 by id4     |      0.252|  0.189|
|   1e+07|sum v1:v3 by id6      |      0.595|  0.893|
|   1e+08|sum v1 by id1         |      1.551|  4.091|
|   1e+08|sum v1 by id1:id2     |      4.200| 11.557|
|   1e+08|sum v1 mean v3 by id3 |     10.634| 24.590|
|   1e+08|mean v1:v3 by id4     |      2.683|  2.133|
|   1e+08|sum v1:v3 by id6      |      6.963| 16.451|
|   1e+09|sum v1 by id1         |     15.063|     NA|
|   1e+09|sum v1 by id1:id2     |     44.240|     NA|
|   1e+09|sum v1 mean v3 by id3 |    157.430|     NA|
|   1e+09|mean v1:v3 by id4     |     26.855|     NA|
|   1e+09|sum v1:v3 by id6      |    120.376|     NA|

En 4 de las 5 preguntas, data.table es más rápido y podemos ver que se escala mejor.
Ten en cuenta esta horarios son a partir de ahora , donde id1, id2y id3son campos de caracteres. ~~Esos se cambiarán pronto a~~ HECHO ~~categórico~~ . Además, hay otros factores que pueden afectar esos tiempos en un futuro próximo (como la ~~agrupación en paralelo~~ HECHO ). También vamos a agregar puntos de referencia separados para los datos que tienen NA y ~~varias cardinalidades~~ HECHO .

Otras tareas están llegando a este proyecto de evaluación comparativa continua por lo que si usted está interesado en join, sort, ready otros, asegúrese de comprobar más tarde.
¡Y, por supuesto, puede enviar comentarios en el repositorio de proyectos!

— jangorecki
fuente

1

¿Qué hay de JuliaDB?

— skan

1

@skan puedes rastrear el estado de eso en github.com/h2oai/db-benchmark/issues/63

— jangorecki

1

Buena respuesta: ¿AFACIO de que los puntos de referencia que enlace se ejecuten en la misma máquina virtual? Es decir, en las mismas condiciones, los pandas y los dask necesitan más de 128 GB de RAM para la tabla de 50 GB, mientras que los demás pueden funcionar bajo esta restricción. Si es así, también refleja mis experiencias con los pandas que son muy ineficientes en RAM para muchas cosas cotidianas normales en tablas moderadas (~ 10GB), y es un problema mucho mayor la mayor parte del tiempo que la velocidad de ejecución. (que está mucho más cerca y se intercambia de un lado a otro en cualquier caso, dependiendo de la carga de trabajo específica).

— jkf

@jkf sí, exactamente. La máquina tiene 128 GB de memoria porque estamos planeando probar el procesamiento de memoria en un conjunto de datos de 500 GB (10e9 filas). Actualmente, solo spark y pydatatable lo admitirán, y pronto se agregarán clickhouse.

— Jangorecki

@jangorecki es un punto de referencia extremadamente útil. Muchas gracias por el esfuerzo. Estoy un poco desconcertado acerca de que dask no pueda digerir el conjunto de datos de 50 GB. Dask tiene el tamaño de partición como uno de los parámetros (por ejemplo, blocksizeen read_csv). ¿Intentó evitar llamar compute()y volcar la salida al disco para evitar ensamblar toda la tabla de salida en la memoria?

— Mischa Lisovyi

13

Un colega y yo hemos realizado algunos estudios preliminares sobre las diferencias de rendimiento entre pandas y data.table. Puede encontrar el estudio (que se dividió en dos partes) en nuestro Blog (Puede encontrar la segunda parte aquí ).

Pensamos que hay algunas tareas donde los pandas claramente superan a data.table, pero también casos en los que data.table es mucho más rápido. Puede verificarlo usted mismo y decirnos qué piensa de los resultados.

EDITAR:
si no desea leer los blogs en detalle, aquí hay un breve resumen de nuestra configuración y nuestros hallazgos:

Preparar

Comparamos pandasy data.tableen 12 conjuntos de datos simulados diferentes en las siguientes operaciones (hasta ahora), que llamamos escenarios.

Recuperación de datos con una operación de selección
Filtrado de datos con una operación de selección condicional.
Operaciones de clasificación de datos
Operaciones de agregación de datos

Los cálculos se realizaron en una máquina con un Intel i7 2.2GHz con 4 núcleos físicos, 16 GB de RAM y un disco duro SSD. Las versiones de software fueron OS X 10.13.3, Python 3.6.4 y R 3.4.2. Las respectivas versiones de la biblioteca utilizadas fueron 0.22 para pandas y 1.10.4-3 para data.table

Resultados en pocas palabras

data.tableparece ser más rápido al seleccionar columnas ( pandasen promedio toma un 50% más de tiempo)
pandas es más rápido al filtrar filas (aproximadamente 50% en promedio)
data.tableparece ser considerablemente más rápido en la clasificación (a pandasveces era 100 veces más lento)
agregar una nueva columna aparece más rápido con pandas
los resultados agregados son completamente mixtos

Tenga en cuenta que intenté simplificar los resultados lo más posible para no aburrirlo hasta la muerte. Para una visualización más completa, lea los estudios. Si no puede acceder a nuestra página web, envíeme un mensaje y le enviaré nuestro contenido. Puede encontrar el código para el estudio completo en GitHub . Si tiene ideas sobre cómo mejorar nuestro estudio, envíenos un correo electrónico. Puede encontrar nuestros contactos en GitHub.

— Tobias Krabel
fuente

1

Como habrás leído en mi respuesta, ya digo que los resultados son mixtos. Por favor aclare si seré más específico en mi respuesta, potencialmente elaborando algunos números.

— Tobias Krabel

1

"Su acceso a este sitio ha sido limitado". Parece que no puedo acceder al sitio desde mi teléfono ni desde mi computadora de trabajo.

— xiaodai

1

Lamento leer eso. Lo revisé yo mismo en mi teléfono y no tuve problemas. ¿Podría tener algo que ver con el país desde el que intenta conectarse?

— Tobias Krabel

1

"4 núcleos físicos" = 8 núcleos lógicos. También ayuda decir qué Intel i7 2.2GHz específico (¿qué generación, qué variante, -HQ?) Y qué tamaño de caché. Y para el SSD, ¿qué velocidades de lectura y escritura?

— smci

¿Cómo se comparan con los marcos de datos de Julia y JuliaDB?

— skan

3

No, de hecho, si el tamaño del conjunto de datos es tan grande que los pandas se bloquean, básicamente estás atascado con dask, lo que apesta y ni siquiera puedes hacer un simple groupby-sum. Puede que dplyr no sea rápido, pero no daña.

Actualmente estoy trabajando en un pequeño conjunto de datos 2G y un simple print(df.groupby(['INCLEVEL1'])["r"].sum())bloquea el dask.

No experimenté este error con dplyr.

Entonces, si los pandas pueden manejar el conjunto de datos, los uso, si no, me quedo con la tabla de datos R.

Y sí, puede convertir dask de nuevo a un marco de datos de pandas con un simple df.compute() Pero lleva bastante tiempo, por lo que podría esperar pacientemente a que se carguen los pandas o la tabla de datos para leer.

— Chenying Gao
fuente

1

No sabía que Dask era tan malo. ¿Quizás quieras probar el disk.frame de R? github.com/xiaodaigh/disk.frame Soy el autor

— xiaodai

1

Sé que esta es una publicación anterior, pero pensé que vale la pena mencionarla: usar feather (en R y en Python) permite operar en marcos de datos / tablas de datos y compartir esos resultados a través de feather.

Ver la página de github de la pluma

— Don Quijote
fuente

Segfaults para conjuntos de datos medianos y grandes

— jangorecki