El motor bajo tu código acaba de ser reemplazado
Polars 2.0 implementa un cambio fundamental, a menudo invisible: el motor de consultas predeterminado ha sido reemplazado. Sin realizar modificaciones en el código, las consultas existentes ahora se ejecutan en un nuevo streaming engine, alejándose del sistema anterior en memoria. Este cambio arquitectónico central afecta a todos los usuarios de Polars inmediatamente después de la actualización.
Anteriormente, el motor en memoria funcionaba como un almacén, requiriendo que todo el conjunto de datos se cargara en la RAM antes de que pudiera comenzar cualquier procesamiento. Los pasos de la consulta se ejecutaban entonces sobre estos datos completamente cargados. Este método demostró ser rápido solo cuando el conjunto de datos completo cabía en la memoria disponible, limitando la escalabilidad para operaciones más grandes.
El nuevo streaming engine adopta un paradigma diferente, similar a una línea de ensamblaje. Descompone los datos en pequeños morsels optimizados, dimensionados específicamente para caber dentro de la caché de una CPU. Estos morsels se envían a través del plan de consulta de forma secuencial, pero con una diferencia crítica.
Este enfoque basado en fragmentos y canalizado es la fuente directa de importantes ganancias de velocidad. Diferentes partes de una consulta ahora pueden ejecutarse simultáneamente en morsels separados, eliminando los cuellos de botella anteriores donde un paso tenía que esperar a que se procesara todo el conjunto de datos. Esta concurrency agiliza el flujo de datos, haciendo que las operaciones complejas sean considerablemente más rápidas al permitir una línea de procesamiento eficiente y continua. El cambio del motor tiene como objetivo maximizar la utilización de la CPU manteniendo los datos localizados y en movimiento.
El precio de la velocidad: tus datos están fuera de orden
El paralelismo en el nuevo streaming engine conlleva un costo significativo: el row order ya no está garantizado. Las operaciones que incluyen joins, group-bys y unpivots pueden devolver filas en una secuencia diferente a la de su entrada. Este comportamiento refleja el procesamiento paralelo de los "morsels" de datos del motor, donde múltiples tareas se completan de forma independiente, similar a los trabajadores en una línea de ensamblaje.
Este cambio representa la alteración más peligrosa de Polars 2.0 debido a su potencial para generar silent failures. Tu código no fallará y los números calculados pueden seguir siendo aritméticamente correctos. Sin embargo, si los procesos posteriores dependen implícitamente del orden de las filas de entrada, los datos pueden asignarse a entidades incorrectas, corrompiendo el análisis sin generar un error. Estos problemas son mucho más difíciles de detectar que las excepciones explícitas.
La intención explícita ahora se vuelve obligatoria para el ordenamiento. Si una operación requiere una secuencia de filas específica, debes informárselo directamente a Polars. Por ejemplo, una operación de join ahora acepta maintain_order='left' para preservar el orden del lado izquierdo. Este diseño cambia la conveniencia implícita por la explicit correctness, obligando a los desarrolladores a declarar los requisitos de ordenamiento.
Polars 2.0 fuerza un enfoque declarativo para el orden de los datos, evitando suposiciones que podrían conducir a una corrupción de datos no detectada. Si bien la función explain() puede revelar el comportamiento subyacente de una consulta, los desarrolladores deben examinar proactivamente las implicaciones de ordenamiento. Este cambio subraya un compromiso con el rendimiento y la integridad robusta de los datos por encima de las garantías implícitas históricas, impulsando una mayor claridad en los pipelines de datos.
Una versión 'aburrida' que rompe cosas intencionalmente
Polars 2.0 no ofrece ninguna característica nueva importante. En cambio, sirve como una cleanup release, fortaleciendo la base interna de la biblioteca. Esta versión introduce intencionalmente cambios disruptivos (breaking changes), priorizando la consistencia a largo plazo y la robustez arquitectónica sobre la compatibilidad con versiones anteriores para actualizaciones menores.
Se han renombrado o eliminado docenas de métodos. Estos incluyen:
meltahora esunpivotread_csvse convierte enscan_csv().collect()LazyFrame.profile()ha sido eliminadojoin_nullsahora esnulls_equal- Convertir un entero directamente a categórico requiere
cat.to() concatahora rechaza alturas que no coinciden, en lugar de intentar inferir la intención del usuario
Polars emite un útil AttributeRemovedError para estos cambios. Este error detalla explícitamente la nueva función o método a utilizar, guiando a los usuarios a través de la migración.
Esta filosofía contrasta marcadamente con el enfoque de Pandas, que a menudo traslada la ambigüedad y los posibles problemas al tiempo de ejecución. Polars tiene como objetivo detectar errores tempranamente, haciendo que el código sea más predecible y robusto antes de su ejecución. Estos cambios disruptivos, junto con mensajes de error altamente descriptivos, son una parte fundamental de la estrategia de diseño preventivo de Polars.
¿Te está gustando? Recibe uno así en tu bandeja cada mañana.
un correo al día · date de baja en dos clics · sin rastreadores de terceros
El veredicto: ¿Actualizar ahora, esperar o auditar?
La afirmación de Polars de un rendimiento 5 veces más rápido con el nuevo streaming engine es una expectativa, no un punto de referencia universal. Este motor, aunque fundamental, aún no ofrece un procesamiento real fuera del núcleo (out-of-core); los datos aún deben caber dentro de la RAM. La versión 2.0 prepara la biblioteca para capacidades futuras que manejarán conjuntos de datos más grandes que la memoria.
Actualmente, Polars 2.0 es un release candidate, que requiere instalación con el flag --pre. Esta versión aún no es estable, presentando errores como un problema de alta prioridad donde group_by_dynamic produce errores de fecha y hora fuera de rango en el streaming engine. Además, str.to_datetime ahora puede devolver nulos en lugar de lanzar excepciones, y el método limit no sale prematuramente después de un join.
Los nuevos proyectos deberían considerar comenzar con Polars 2.0 para adoptar la API actualizada desde el inicio. Para las bases de código existentes, una actualización a ciegas no es recomendable. Los desarrolladores deben auditar su código en busca de operaciones como joins o group-bys que dependan implícitamente del orden de las filas. Agregue explícitamente la ordenación o utilice flags de maintain_order para garantizar la consistencia de los datos, evitando problemas silenciosos de integridad de datos.
Preguntas frecuentes
¿Cuál es el mayor cambio en Polars 2.0?
El motor de consulta predeterminado se ha cambiado al nuevo motor de 'streaming'. Este motor procesa los datos en fragmentos más pequeños y paralelos para obtener ganancias de rendimiento significativas pero, como contrapartida, ya no garantiza el orden original de las filas de forma predeterminada.
¿Por qué Polars 2.0 cambia el orden de mis filas?
El nuevo streaming engine paraleliza las operaciones en fragmentos de datos ('morsels'). Para maximizar la velocidad, no espera a volver a ensamblar estos fragmentos en su orden original. Ahora debe solicitar explícitamente la preservación del orden utilizando parámetros como maintain_order=True.
¿Es Polars 2.0 realmente 5 veces más rápido?
La cifra de '5 veces más rápido' es una expectativa del equipo de Polars, no un punto de referencia garantizado. Si bien el nuevo motor es notablemente más rápido, las ganancias de rendimiento reales varían según su hardware, el conjunto de datos y las operaciones específicas que esté ejecutando.
¿Qué significa 'streaming' en Polars 2.0?
Actualmente, 'streaming' se refiere a un modelo de ejecución fragmentado y canalizado que procesa los datos en piezas dimensionadas para la caché de su CPU. Todavía no significa un procesamiento real fuera del núcleo (out-of-core) donde los conjuntos de datos pueden ser más grandes que la RAM de su máquina.
¿Es seguro usar Polars 2.0 en producción?
La versión inicial 2.0 es un release candidate. Dados los cambios significativos de comportamiento (como el orden de las filas) y algunos errores conocidos, es prudente auditar minuciosamente las bases de código existentes y esperar la versión estable antes de implementar en entornos de producción críticos.