Polars 2.0 llega con el motor de streaming activado por defecto: hasta 5 veces más rápido
Pre-Release of Polars 2.0
Polars ha publicado la primera release candidate de su versión 2.0, que no busca añadir funciones llamativas, sino corregir decisiones de diseño del pasado y cambiar los valores por defecto a opciones más sensatas. El cambio más destacado es que todas las consultas LazyFrame ahora se ejecutarán con el motor de streaming, lo que promete mejoras sustanciales en memoria y rendimiento, con una velocidad media cinco veces superior. Además, Polars se vuelve más estricto: operaciones como is_in o concat ahora lanzan errores ante incompatibilidades de tipos o longitudes, en lugar de realizar conversiones silenciosas. La guía de migración completa está disponible en la documentación oficial.
Esperamos que esta versión sea aburrida; no reservamos las nuevas funciones para los cambios de versión principal, las lanzamos en cuanto están listas.
- benrutter
> No pretendemos hacer un gran lanzamiento de funciones en Polars 2.0. De hecho, esperamos que sea una experiencia aburrida para ti. La razón por la que subimos esta versión principal es que podemos deshacernos de decisiones de diseño tomadas en el pasado que actualmente nos bloquean y luego queremos cambiar los valores predeterminados a configuraciones más sensatas que beneficien a una audiencia más amplia.
Sé que esta opinión me revela como una persona muy aburrida, pero ¡me encanta ver proyectos que se toman el semver en serio así! Los cambios de versión deberían tratar de eliminar la complejidad obsoleta en lugar de añadir funciones brillantes.
He usado polars durante un tiempo, y su enfoque en la estabilidad fue una gran parte para convencerme de dar el salto inicialmente.
- perrygeo
Para mí, el superpoder de polars es la estabilidad en producción.
Pandas tiende a empujar todos los problemas al tiempo de ejecución, con todo tipo de heurísticas ocultas. Particularmente en torno a los tipos de columna y los valores faltantes. Es muy difícil saber si has probado todos los casos límite. La única forma de probar tu código es lanzarle todas las variaciones de datos. Está bien si estás sentado frente a un notebook y tienes la paciencia de validar y "limpiar" los datos en su nombre. No tan bien si te llaman a las 3 a.m. porque tu pipeline de datos falló cuando esperaba una columna int pero recibió float.
Polars es más estricto por defecto y adelanta los costos a través de su planificador. Las aplicaciones resultantes son notablemente más estables en producción. Puedes probar el código y tener una seguridad razonable de que funcionará con datos en el mundo real.
No me interesan realmente la ergonomía de la API ni la sintaxis: ambas están bien. Se trata de cómo manejan la variación de datos en tiempo de ejecución. ¿Puedes escribir código general que no se rompa con variantes? Pandas, ni de lejos. ¡Polars, absolutamente!
Ronda extra: polars también tiene una API de Rust, el compilador puede demostrar efectivamente que tu programa maneja cada caso límite. Es común escribir aplicaciones de polars en Rust que funcionan sin supervisión durante años.
- trombonechamp
¿Hay alguna razón aparte del rendimiento para que maintain_order=False sea el valor predeterminado? Lo pregunto porque polars se usa en muchos pipelines de análisis de datos científicos, y el comportamiento no determinista es una fuente bien documentada de errores en la computación científica (por ejemplo, https://pmc.ncbi.nlm.nih.gov/articles/PMC6919963/). El nuevo valor predeterminado requiere que los usuarios mantengan los detalles de implementación de la API en su cabeza mientras determinan si el código es correcto o no. Esto es complicado en la computación científica porque la respuesta correcta no se conoce de antemano, por lo que los errores pueden pasar desapercibidos y dar resultados incorrectos silenciosamente.
- bbstats
¡Me molesta muchísimo que "Use instead: .cat.to(dtype) para int → categorical, .cat.physical() para categorical → int." no incluya el ejemplo de código necesario!
- lmeyerov
Avanzar hacia el streaming y, en general, el procesamiento fuera de núcleo es genial.
Recientemente añadimos un backend de Polars a GFQL (consultas de grafos Cypher sobre dataframes, sin necesidad de base de datos), tanto en modo CPU como GPU, y es súper impresionante. Mejoras notables en comparación con pandas/cudf, y permitió que GFQL superara a sistemas populares en más categorías, como baja latencia, no solo en grandes conjuntos de datos: https://www.graphistry.com/blog/cypher-on-polars-cpu-gpu-gra...
- bobson_dugnutt5
Me encanta polars. Hice mucho evangelismo en el trabajo para que la gente abandonara pandas en favor de él.
- Kydlaw
Me alegra ver actividad en torno a Polars. Ha sido mi biblioteca de referencia para el procesamiento de datos debido a la ergonomía mejorada en comparación con Pandas y SQL.
Pero han estado un poco callados últimamente, y empecé a mirar cada vez más DuckDB recientemente... hasta la reciente adquisición de DuckLab por AWS.
- arn3n
La decisión de usar el motor de streaming por defecto es realmente interesante. Mi intuición es que esto sería más lento que otras operaciones de dataframe que son más paralelizables con procesamiento por lotes, porque los motores de streaming procesan filas secuencialmente. ¿Está mi intuición equivocada o estoy sobreestimando cuánta auto-paralelización hace polars?