Polars 2.0 : pourquoi les jointures ne conservent plus l'ordre des lignes
Polars 2.0 exécute collect sur un moteur de streaming par défaut.
Polars 2.0 exécute collect sur un moteur de streaming par défaut. Pour join, group_by et unpivot, la version ne garantit plus l'ordre des lignes d'entrée, sauf si vous définissez explicitement maintain_order ou sort. Lors de notre exécution sur Polars 2.0.0, une jointure interne de 2 000 000 de lignes a renvoyé les lignes hors de l'ordre d'entrée par défaut et a conservé l'ordre avec maintain_order défini. La version active également le déversement hors cœur de mémoire et attribue les revendications de référence au fournisseur lui-même.
Lire l'édition écrite (anglais) ↗
Ce que couvre cette vidéo
- L'appel de collect() sur une requête paresseuse utilise désormais le moteur de streaming par défaut, qui ne garantit pas l'ordre des lignes pour join, group_by et unpivot.
- Le guide de migration indique que l'ordre n'est plus l'ordre d'avant la version 2.0 et n'est pas garanti ; il recommande un tri explicite si vous en dépendez.
- Dans notre exécution, une jointure interne par défaut a renvoyé l'ordre d'entrée False ; maintain_order="left_right" sur la jointure a renvoyé True. Une machine, une exécution, une forme de jointure.
- Le déversement hors cœur de mémoire est activé par défaut : il commence à environ 80 % de la RAM, avec un budget disque par défaut de 64 Go. Les jointures et group_by hors cœur de mémoire sont sur la feuille de route.
- collect_schema() détecte une colonne manquante avant la lecture des données, mais un cast qui échoue sur une seule valeur ne échoue qu'au moment de collect().
- La comparaison TPC-H et TPC-DS est l'exécution propre du fournisseur sur des données dérivées, et sa note de bas de page indique que les résultats ne sont pas comparables aux benchmarks officiels.
Transcription traduite
Traduit de la narration originale en anglais. L'audio et les sous-titres disponibles sont gérés par YouTube.
Pourquoi l'ordre par défaut a-t-il changé ?
0:00 Vous pensez qu'une jointure vous rend vos lignes dans l'ordre où vous les avez écrites. Polars 2.0 a cessé de promettre cela, par défaut, délibérément. Dans cette vidéo : pourquoi le défaut a-t-il changé ? Qu'est-ce que cela a apporté ? Et lequel de vos scripts se casse en premier ? Ceci est The Daily Diff, sous le capot. Polars est une bibliothèque DataFrame open-source : un moteur de table que vous appelez depuis Python,
0:20 avec son cœur écrit en Rust. Il est gratuit sous licence MIT, et vous l'installez avec pip install polars. Un détail d'abord. Le commutateur qui ramène l'ancien ordre est un argument de la jointure elle-même. J'y reviendrai à la fin. Depuis la version 2.0, collect exécute le moteur de streaming par défaut. Le streaming divise la requête en morceaux qui s'exécutent en parallèle, et les morceaux se terminent quand ils se terminent.
0:42 Pour join, group by et unpivot, la version ne promet pas d'ordre. Qui est touché en premier ? Quiconque compare la sortie à un fichier enregistré, ligne par ligne. Ce test peut réussir sur votre ordinateur portable et échouer sur une machine différente. Ensuite, le guide de migration.
Que promet le guide de migration ?
0:57 Il indique que l'ordre exact des lignes affiché ci-dessus n'est pas garanti. Donc, si vous dépendez de l'ordre, triez explicitement. Le déversement hors cœur de mémoire est également activé par défaut. Il commence à déverser sur le disque à environ quatre-vingts pour cent de la RAM, avec un budget de soixante-quatre gigaoctets. Le tri, les fonctions de fenêtre et de nombreuses expressions peuvent maintenant déverser. Les jointures et les group-by sont à venir.
Le benchmark est-il équitable ?
1:17 Polars affirme qu'il surpasse DataFusion et DuckDB sur les benchmarks TPC-H et TPC-DS. Les chiffres proviennent de leurs propres exécutions, sur des données dérivées, et leur note de bas de page indique qu'ils ne sont pas comparables aux résultats officiels. Leurs propres chiffres indiquent que Polars est environ trois virgule huit fois plus rapide de seize cœurs à cent quatre-vingt-douze, sur TPC-H. Ils disent également que les threads supplémentaires de la grande machine ralentissent les petites requêtes.
Que voyons-nous lorsque nous l'exécutons ?
1:41 Nous avons exécuté la même jointure deux fois sur Polars 2.0.0. L'exécution par défaut mélange les lignes. Avec le drapeau, l'ordre d'entrée survit. Trouvez les jointures qui alimentent un test. Toute jointure sans tri après elle est une décision d'ordre des lignes que vous n'avez jamais prise. Polars 2.0 est plus strict sur les types.
Plus strict signifie-t-il plus tôt ?
1:58 La vérification du schéma détecte une colonne manquante avant la lecture des données. Elle ne peut pas détecter un cast qui échoue sur une ligne, car cette erreur attend le données. Maintenant, la boucle que j'ai ouverte.
Comment puis-je retrouver l'ancien ordre ?
2:08 Le commutateur se trouve sur la jointure. Définissez maintain order sur la jointure, ou ajoutez un tri après elle. Le guide suggère le tri. Le drapeau de jointure a conservé l'ordre dans notre exécution, avec l'ordre du côté gauche conservé comme gauche, droite. Verdict, sous le capot : NEEDS REVIEW.
Quel est le verdict ?
2:22 Je réviserais chaque jointure avant de mettre à niveau. Vous avez une question à ce sujet ? Mettez-la dans les commentaires. Et c'est la différence pour aujourd'hui. Je suis Niko d'Axrisi. Fusionnez de manière responsable.
Sources
- Release of Polars 2.0Polars (pola.rs)
- Polars 2.0 upgrade guidePolars documentation
- Polars homepagePolars (pola.rs)
- polars-2.0-benchmark repositoryPolars on GitHub
- Release of Polars 2.0 (Hacker News discussion)Hacker News



