+− THE DAILY DIFFdev & AI news
NEEDS REVIEW

Polars 2.0: por qué las uniones ya no mantienen el orden de las filas

Polars 2.0 ejecuta collect en un motor de streaming por defecto.

Polars 2.0 ejecuta collect en un motor de streaming por defecto. Para join, group_by y unpivot, la versión ya no garantiza el orden de las filas de entrada a menos que se establezca maintain_order o sort explícitamente. En nuestra ejecución en Polars 2.0.0, un inner join de 2.000.000 de filas devolvió las filas desordenadas por defecto y mantuvo el orden con maintain_order establecido. La versión también activa el desbordamiento fuera del núcleo (out-of-core spilling) y hace suyas las afirmaciones de rendimiento del proveedor.

Leer la edición escrita (inglés) ↗

Qué cubre este vídeo

  • Llamar a collect() en una consulta lazy ahora usa el motor de streaming por defecto, lo que no garantiza el orden de las filas para join, group_by y unpivot.
  • La guía de migración dice que el orden ya no es el orden pre-2.0 y no está garantizado; recomienda una ordenación explícita si se depende de ello.
  • En nuestra ejecución, un inner join por defecto devolvió input order False; maintain_order="left_right" en el join devolvió True. Una máquina, una ejecución, una forma de join.
  • El desbordamiento fuera del núcleo está activado por defecto: comienza aproximadamente al 80 % de la RAM, con un presupuesto de disco predeterminado de 64 GB. Los joins y group_by fuera del núcleo están en la hoja de ruta.
  • collect_schema() detecta una columna faltante antes de que se lea cualquier dato, pero un cast que falla en un solo valor solo falla en collect().
  • La comparación TPC-H y TPC-DS es una ejecución propia del proveedor sobre datos derivados, y su nota a pie de página dice que los resultados no son comparables con los benchmarks oficiales.

Transcripción traducida

Traducido de la narración original en inglés. El audio y los subtítulos disponibles están controlados por YouTube.

¿Por qué cambió el orden predeterminado?

0:00 Crees que un join te devuelve las filas en el orden en que las escribiste. Polars 2.0 dejó de prometer eso, por defecto, a propósito. En este video: ¿por qué cambió el valor predeterminado? ¿Qué ganó? ¿Y cuál de tus scripts falla primero? Esto es The Daily Diff, bajo el capó. Polars es una biblioteca de DataFrames de código abierto: un motor de tablas al que llamas desde Python,

0:20 con su núcleo escrito en Rust. Es gratuito bajo la licencia MIT, y lo instalas con pip install polars. Un detalle primero. El interruptor que devuelve el orden antiguo es un argumento del propio join. Volveré a ello al final. Desde 2.0, collect ejecuta el motor de streaming por defecto. El streaming divide la consulta en trozos que se ejecutan en paralelo, y los trozos terminan cuando terminan.

0:42 Para join, group by y unpivot, la versión no promete un orden. ¿Quién es el primero en verse afectado? Quien compare la salida con un archivo guardado, fila por fila. Esa prueba puede pasar en tu portátil y fallar en una máquina diferente. A continuación, la guía de migración.

¿Qué promete la guía de migración?

0:57 Dice que el orden exacto de las filas que se muestra arriba no está garantizado. Así que si dependes del orden, ordena explícitamente. Out-of-core también está activado por defecto. Empieza a desbordarse al disco aproximadamente al ochenta por ciento de la RAM, con un presupuesto de sesenta y cuatro gigabytes. Ahora, sort, las funciones de ventana y muchas expresiones pueden desbordarse. Los joins y group-bys están en camino.

¿Es el benchmark una lucha justa?

1:17 Polars dice que supera a DataFusion y DuckDB en los benchmarks TPC-H y TPC-DS. Los números provienen de sus propias ejecuciones, sobre datos derivados, y su nota a pie de página dice que no son comparables con los resultados oficiales. Sus propios números dicen que Polars es aproximadamente tres coma ocho veces más rápido desde dieciséis núcleos hasta ciento noventa y dos, en TPC-H. También dicen que los hilos extra de la máquina grande ralentizan las consultas pequeñas.

¿Qué vemos cuando lo ejecutamos?

1:41 Ejecutamos el mismo join dos veces en Polars 2.0.0. La ejecución predeterminada mezcla las filas. Con la bandera, el orden de entrada se mantiene. Encuentra los joins que alimentan una prueba. Cualquier join sin una ordenación posterior es una decisión de orden de filas que nunca tomaste. Polars 2.0 es más estricto con los tipos.

¿Más estricto significa antes?

1:58 La comprobación de esquema detecta una columna faltante antes de que se lea cualquier dato. No puede detectar una conversión que falla en una fila, porque ese error espera a los datos. Ahora el bucle que abrí.

¿Cómo recupero el orden antiguo?

2:08 El interruptor reside en el join. Establece maintain order en el join, o añade una ordenación después de él. La guía sugiere la ordenación. La bandera del join mantuvo el orden en nuestra ejecución, manteniendo el orden del lado izquierdo como izquierda, derecha. Veredicto, bajo el capó: NEEDS REVIEW.

¿Cuál es el veredicto?

2:22 Revisaría cada join antes de actualizar. ¿Tienes alguna pregunta sobre esto? Ponla en los comentarios. Y esa es la diferencia de hoy. Soy Niko de Axrisi. Fusiona responsablemente.

Fuentes

  1. Release of Polars 2.0Polars (pola.rs)
  2. Polars 2.0 upgrade guidePolars documentation
  3. Polars homepagePolars (pola.rs)
  4. polars-2.0-benchmark repositoryPolars on GitHub
  5. Release of Polars 2.0 (Hacker News discussion)Hacker News

Vídeos relacionados