Le moteur sous votre code vient d'être remplacé
Polars 2.0 met en œuvre un changement fondamental, souvent invisible : le moteur de requête par défaut a été remplacé. Sans aucune modification de code, les requêtes existantes s'exécutent désormais sur un nouveau streaming engine, s'éloignant du système en mémoire précédent. Ce changement architectural majeur impacte chaque utilisateur de Polars dès la mise à jour.
Auparavant, le moteur en mémoire fonctionnait comme un entrepôt, nécessitant le chargement de l'intégralité du jeu de données dans la RAM avant que tout traitement ne puisse commencer. Les étapes de la requête s'exécutaient ensuite sur ces données entièrement chargées. Cette méthode ne s'avérait rapide que lorsque le jeu de données complet tenait dans la mémoire disponible, limitant ainsi l'évolutivité pour les opérations plus importantes.
Le nouveau streaming engine adopte un paradigme différent, semblable à une chaîne de montage. Il décompose les données en petits morsels optimisés, spécifiquement dimensionnés pour tenir dans le cache d'un processeur. Ces morsels sont ensuite transmis séquentiellement à travers le plan de requête, mais avec une différence cruciale.
Cette approche en pipeline basée sur des blocs est la source directe de gains de vitesse significatifs. Différentes parties d'une requête peuvent désormais s'exécuter simultanément sur des morsels distincts, éliminant les goulots d'étranglement précédents où une étape devait attendre que l'ensemble du jeu de données soit traité. Cette concurrency rationalise le flux de données, rendant les opérations complexes considérablement plus rapides en permettant une ligne de traitement efficace et continue. Le changement de moteur vise à maximiser l'utilisation du CPU en gardant les données localisées et en mouvement.
Le prix de la vitesse : vos données ne sont plus dans l'ordre
Le parallélisme dans le nouveau streaming engine comporte un coût significatif : l'ordre des lignes n'est plus garanti. Les opérations incluant des jointures, des group-bys et des unpivots peuvent renvoyer des lignes dans une séquence différente de celle de leur entrée. Ce comportement reflète le traitement parallèle des « morsels » de données par le moteur, où plusieurs tâches se terminent indépendamment, à l'instar d'ouvriers sur une chaîne de montage.
Ce changement représente l'altération la plus dangereuse de Polars 2.0 en raison de son potentiel de défaillances silencieuses. Votre code ne plantera pas et les nombres calculés peuvent rester arithmétiquement corrects. Cependant, si les processus en aval reposent implicitement sur l'ordre des lignes en entrée, les données peuvent être associées à des entités incorrectes, corrompant l'analyse sans générer d'erreur. De tels problèmes sont bien plus difficiles à détecter que des exceptions explicites.
L'intention explicite devient désormais obligatoire pour le tri. Si une opération nécessite une séquence de lignes spécifique, vous devez en informer Polars directement. Par exemple, une opération de jointure accepte désormais maintain_order='left' pour préserver l'ordre du côté gauche. Cette conception troque la commodité implicite contre une exactitude explicite, obligeant les développeurs à déclarer leurs exigences en matière d'ordre.
Polars 2.0 impose une approche déclarative de l'ordre des données, empêchant les hypothèses qui pourraient conduire à une corruption de données non détectée. Bien que la fonction explain() puisse révéler le comportement sous-jacent d'une requête, les développeurs doivent examiner de manière proactive les implications sur l'ordre. Ce changement souligne un engagement envers la performance et l'intégrité robuste des données plutôt que les garanties implicites historiques, poussant vers une plus grande clarté dans les pipelines de données.
Une version « ennuyeuse » qui casse intentionnellement des choses
Polars 2.0 ne propose aucune nouvelle fonctionnalité majeure. Au lieu de cela, elle sert de version de nettoyage, renforçant la fondation interne de la bibliothèque. Cette version introduit intentionnellement des changements cassants, privilégiant la cohérence à long terme et la robustesse architecturale par rapport à la rétrocompatibilité pour les mises à jour mineures.
Des dizaines de méthodes ont été renommées ou supprimées. Celles-ci incluent :
meltest désormaisunpivotread_csvdevientscan_csv().collect()LazyFrame.profile()a été suppriméjoin_nullsest désormaisnulls_equal- La conversion directe d'un entier en catégoriel nécessite
cat.to() concatrefuse désormais les hauteurs incompatibles, au lieu de tenter de deviner l'intention de l'utilisateur
Polars émet une AttributeRemovedError utile pour ces changements. Cette erreur détaille explicitement la nouvelle fonction ou méthode à utiliser, guidant les utilisateurs tout au long de la migration.
Cette philosophie contraste fortement avec l'approche de Pandas, qui repousse souvent l'ambiguïté et les problèmes potentiels au moment de l'exécution. Polars vise à détecter les erreurs tôt, rendant le code plus prévisible et robuste avant l'exécution. Ces changements cassants, associés à des messages d'erreur hautement descriptifs, sont au cœur de la stratégie de conception préventive de Polars.
Cet article vous plaît ? Recevez-en un comme celui-ci chaque matin.
un e-mail par jour · désinscription en deux clics · aucun traqueur tiers
Le verdict : mettre à jour maintenant, attendre ou auditer ?
L'affirmation de Polars concernant des performances 5 fois plus rapides avec le nouveau streaming engine est une attente, pas un benchmark universel. Ce moteur, bien que fondamental, n'offre pas encore de véritable traitement out-of-core ; les données doivent toujours tenir dans la RAM. La version 2.0 prépare la bibliothèque à de futures capacités qui géreront des jeux de données plus volumineux que la mémoire.
Actuellement, Polars 2.0 est une release candidate, nécessitant une installation avec le flag --pre. Cette version n'est pas encore stable, présentant des bugs tels qu'un problème de haute priorité où group_by_dynamic produit des erreurs de type datetime hors plage sur le streaming engine. De plus, str.to_datetime peut désormais renvoyer des valeurs nulles au lieu de lever des exceptions, et la méthode limit ne s'arrête pas prématurément après une jointure.
Les nouveaux projets devraient envisager de commencer avec Polars 2.0 pour adopter la nouvelle API dès le départ. Pour les bases de code existantes, une mise à jour aveugle est déconseillée. Les développeurs doivent auditer leur code pour les opérations comme les jointures ou les group-bys qui dépendent implicitement de l'ordre des lignes. Ajoutez explicitement un tri ou utilisez les flags maintain_order pour garantir la cohérence des données, évitant ainsi des problèmes d'intégrité silencieux.
Foire aux questions
Quel est le changement le plus important dans Polars 2.0 ?
Le moteur de requête par défaut a été remplacé par le nouveau moteur 'streaming'. Ce moteur traite les données en petits morceaux parallèles pour des gains de performance significatifs mais, en contrepartie, ne garantit plus l'ordre original des lignes par défaut.
Pourquoi Polars 2.0 change-t-il l'ordre de mes lignes ?
Le nouveau streaming engine parallélise les opérations sur des morceaux de données ('morsels'). Pour maximiser la vitesse, il n'attend pas de réassembler ces morceaux dans leur ordre original. Vous devez désormais demander explicitement la préservation de l'ordre en utilisant des paramètres comme maintain_order=True.
Polars 2.0 est-il vraiment 5 fois plus rapide ?
Le chiffre '5 fois plus rapide' est une attente de l'équipe Polars, pas un benchmark garanti. Bien que le nouveau moteur soit sensiblement plus rapide, les gains de performance réels varient en fonction de votre matériel, de votre jeu de données et des opérations spécifiques que vous exécutez.
Que signifie 'streaming' dans Polars 2.0 ?
Actuellement, 'streaming' fait référence à un modèle d'exécution par morceaux et en pipeline qui traite les données en segments dimensionnés pour le cache de votre CPU. Cela ne signifie pas encore un véritable traitement out-of-core où les jeux de données peuvent être plus volumineux que la RAM de votre machine.
Polars 2.0 est-il sûr à utiliser en production ?
La version initiale 2.0 est une release candidate. Compte tenu des changements comportementaux significatifs (comme l'ordre des lignes) et de certains bugs connus, il est sage d'auditer minutieusement les bases de code existantes et d'attendre la version stable avant de déployer dans des environnements de production critiques.