Polars vs. pandas: ¿en qué se diferencian?
Si está al tanto de los avances en los marcos de datos de Python del último año, seguramente haya oído hablar de Polars, la potente biblioteca de marcos de datos diseñada para trabajar con grandes conjuntos de datos.
A diferencia de otras bibliotecas para trabajar con grandes conjuntos de datos, como Spark, Dask y Ray, Polars está diseñada para ser utilizada en una sola máquina, lo que provoca muchas comparaciones con pandas. Sin embargo, Polars difiere de pandas en varios aspectos importantes, como la forma en que trabaja con los datos y cuáles son sus aplicaciones óptimas. En el siguiente artículo, exploraremos los detalles técnicos que diferencian a estas dos bibliotecas de marcos de datos y echaremos un vistazo a los puntos fuertes y las limitaciones de cada una.
Si desea saber más sobre este tema de boca del creador de Polars, Ritchie Vink, puede ver también nuestra entrevista con él a continuación.
¿Por qué utilizar Polars en lugar de pandas?
En una palabra: rendimiento. Polars se creó desde cero para ser rapidísimo y puede realizar operaciones comunes unas 5-10 veces más rápido que pandas. Además, las operaciones de Polars requieren significativamente menos memoria que las de pandas: pandas requiere alrededor de 5 a 10 veces más RAM que el tamaño del conjunto de datos para realizar las operaciones, frente a las 2 a 4 veces necesarias para Polars.
Puede hacerse una idea de cómo funciona Polars en comparación con otras bibliotecas de marcos de datos aquí. Como ve, Polars es entre 10 y 100 veces más rápida que pandas para las operaciones comunes y, de hecho, es una de las bibliotecas DataFrame más rápidas en general. Además, puede manejar conjuntos de datos más grandes que pandas antes de sufrir errores de falta de memoria.
¿Por qué Polars es tan rápido?
Estos resultados son muy impresionantes, por lo que se estará preguntando: ¿cómo puede Polars obtener este tipo de rendimiento ejecutándose solo en una máquina? La biblioteca se diseñó teniendo en cuenta el rendimiento desde el principio, y esto se consigue gracias a varios factores.
Escrita en Rust
Uno de los datos más conocidos de Polars es que está escrito en Rust, un lenguaje de bajo nivel que es casi tan rápido como C y C++. En cambio, pandas se basa en bibliotecas de Python, una de las cuales es NumPy. Aunque el núcleo de NumPy está escrito en C, sigue lastrado por problemas inherentes a la forma en que Python maneja ciertos tipos en memoria, como las cadenas para datos categóricos, lo que provoca un rendimiento deficiente al manejar estos tipos (para conocer más detalles, consulte este fantástico artículo del blog de Wes McKinney).
Otra de las ventajas de utilizar Rust es que permite una concurrencia segura; es decir, está diseñado para que el paralelismo sea lo más predecible posible. Esto significa que Polars puede utilizar con seguridad todos los núcleos de su máquina incluso para consultas complejas que impliquen varias columnas, lo que llevó a Ritchie Vink a describir el rendimiento de Polar como «vergonzosamente paralelo». Esto proporciona a Polars un enorme aumento del rendimiento con respecto a pandas, que solo utiliza un núcleo para realizar las operaciones. Eche un vistazo a esta excelente charla de Nico Kreiling de la PyCon DE de este año, que entra en más detalle sobre cómo consigue esto Polars.
Basada en Arrow
Otro factor que contribuye al impresionante rendimiento de Polars es Apache Arrow, un formato de memoria independiente del lenguaje. Arrow fue en realidad cocreado por Wes McKinney en respuesta a muchos de los problemas que detectó en pandas a medida que el tamaño de los datos se disparaba. También es el backend de pandas 2.0, una versión de pandas con más rendimiento lanzada en 2023. Sin embargo, los backends de Arrow de las bibliotecas difieren ligeramente: mientras que pandas 2.0 se ha creado sobre PyArrow, el equipo de Polars creó su propia implementación de Arrow.
Una de las principales ventajas de crear una biblioteca de datos en Arrow es la interoperabilidad. Arrow se ha diseñado para estandarizar el formato de datos en memoria utilizado en todas las bibliotecas, y ya lo utilizan varias bibliotecas y bases de datos importantes, como puede ver a continuación.
Esta interoperabilidad acelera el rendimiento, ya que evita la necesidad de convertir los datos a un formato diferente para pasarlos entre los distintos pasos del proceso de datos (en otras palabras, evita la necesidad de serializar y deserializar los datos). También es más eficiente desde el punto de vista de la memoria, ya que dos procesos pueden compartir los mismos datos sin necesidad de hacer una copia. Dado que se estima que la serialización/deserialización representa el 80-90 % de los costes de computación en los flujos de trabajo de datos, el formato común de datos de Arrow proporciona a Polars importantes ganancias de rendimiento.
Arrow también integra compatibilidad con una gama más amplia de tipos de datos que pandas. Como pandas está basado en NumPy, es excelente en el manejo de columnas de enteros y flotantes, pero tiene dificultades con otros tipos de datos. Por el contrario, Arrow cuenta con una sofisticada compatibilidad con tipos de columnas datetime, boolean, binary e incluso complejas, como las que contienen listas. Además, Arrow es capaz de manejar de forma nativa los datos que faltan, lo que requiere una solución en NumPy.
Por último, Arrow utiliza el almacenamiento de datos en columnas, lo que significa que, independientemente del tipo de datos, todas las columnas se almacenan en un bloque continuo de memoria. Esto no solo facilita el paralelismo, sino que también agiliza la recuperación de datos.
Optimización de consultas
Otro de los núcleos del rendimiento de Polars es cómo evalúa el código. Pandas, por defecto, utiliza la ejecución inmediata, que consiste en ejecutar las operaciones en el orden en que usted las ha escrito. Por el contrario, Polars tiene la capacidad de realizar tanto una ejecución inmediata como una ejecución pospuesta, en la que un optimizador de consultas evaluará todas las operaciones necesarias y trazará la forma más eficiente de ejecutar el código. Esto puede incluir, entre otras cosas, reescribir el orden de ejecución de las operaciones o eliminar cálculos redundantes. Tomemos, por ejemplo, la siguiente expresión para obtener la media de la columna Number1 para cada una de las categorías «A» y «B» en Category.
(
df
.groupby(by = "Category").agg(pl.col("Number1").mean())
.filter(pl.col("Category").is_in(["A", "B"]))
)
Si esta expresión se ejecuta inmediatamente, la operación groupby se realizará innecesariamente para todo el DataFrame, y después se filtrará por Category. Con la ejecución pospuesta, se puede filtrar el DataFrame y realizar groupby solo con los datos necesarios.
API expresiva
Por último, Polars tiene una API extremadamente expresiva, lo que significa que básicamente cualquier operación que desee realizar puede expresarse como un método Polars. En cambio, las operaciones más complejas en pandas a menudo deben pasarse al método apply como una expresión lambda. El problema del método apply es que realiza un bucle sobre las filas del DataFrame y ejecuta secuencialmente la operación en cada una de ellas. La posibilidad de utilizar métodos integrados le permite trabajar a nivel de columnas y aprovechar otra forma de paralelismo denominada SIMD.
¿Cuándo debe quedarse con pandas?
Todo esto suena tan estupendo que probablemente se esté preguntando por qué molestarse en seguir con pandas. ¡Pues no tan rápido! Aunque Polars es magnífico para transformar datos de forma extremadamente eficiente, actualmente no es la elección óptima para la exploración de datos o para su uso como parte de los procesos de aprendizaje automático. Estas son áreas en las que pandas sigue brillando.
Una de las razones es que, aunque Polars tiene una gran interoperabilidad con otros paquetes que utilizan Arrow, aún no es compatible con la mayoría de los paquetes de visualización de datos de Python ni con bibliotecas de aprendizaje automático como scikit-learn o PyTorch. La única excepción es Plotly, que le permite crear gráficos directamente a partir de DataFrames de Polars.
Una solución que se está debatiendo es utilizar el protocolo de intercambio de DataFrames de Python en estos paquetes para que sean compatibles con una serie de bibliotecas de DataFrames, lo que significaría que los flujos de trabajo de ciencia de datos y aprendizaje automático ya no se verían obstaculizados por pandas. Sin embargo, se trata de una idea relativamente nueva y llevará tiempo poner en marcha estos proyectos.
Herramientas para Polars y pandas
Después de todo esto, ¡seguro que está deseando probar Polars! Tanto DataSpell como PyCharm Professional 2023.2 ofrecen excelentes herramientas para trabajar tanto con pandas como con Polars en notebooks de Jupyter. En particular, los DataFrames de pandas y Polars se muestran con una funcionalidad interactiva, lo que hace que explorar sus datos sea mucho más rápido y cómodo.
Algunas de mis funcionalidades favoritas son la posibilidad de desplazarse por todas las filas y columnas del DataFrame sin truncarlo, obtener agregaciones de valores del DataFrame con un solo clic y exportar el DataFrame en una enorme variedad de formatos (¡incluido Markdown!).
Si aún no utiliza DataSpell, puede hacer clic en el siguiente enlace y probarlo durante de 30 días.
Artículo original en inglés de:
Subscribe to PyCharm Blog updates
