La version sans aucune nouvelle fonctionnalité
Polars 2.0 ne propose aucune nouvelle fonctionnalité, positionnant cette version comme un nettoyage crucial et une refonte architecturale. Les développeurs la décrivent non pas comme une mise à jour de fonctionnalités, mais comme un effort fondamental pour améliorer la cohérence interne et la robustesse. Cette mise à jour vise la stabilité à long terme, modifiant fondamentalement le fonctionnement du code existant malgré l'absence de nouvelles fonctionnalités destinées aux utilisateurs.
Le changement le plus marquant introduit un nouveau streaming engine par défaut pour toutes les requêtes LazyFrame. Ce moteur traite les données par petits blocs parallèles, appelés morsels, pour des gains massifs de performance et d'efficacité mémoire. Les évaluations initiales prévoient que l'exécution globale des requêtes sera « facilement 5 fois plus rapide » avec ce nouveau paradigme, réduisant considérablement l'empreinte mémoire en évitant de charger des jeux de données entiers dans la RAM simultanément.
Cette mise à jour fondamentale est essentielle pour l'avenir ambitieux de Polars. Le nouveau streaming engine pose les bases critiques pour atteindre un véritable traitement out-of-core, permettant à la bibliothèque de gérer efficacement des jeux de données plus volumineux que la mémoire système disponible. Il ouvre également la voie à un optimiseur de requêtes plus puissant et sophistiqué, améliorant encore les capacités analytiques et l'évolutivité de Polars.
Votre code est cassé : explications sur les changements d'API
Polars 2.0 introduit des changements d'API explicites qui cassent directement le code existant. Cette mise à jour n'est pas une version de fonctionnalités ; elle privilégie la cohérence architecturale à long terme plutôt que la rétrocompatibilité pour certaines fonctions. Les développeurs rencontreront des erreurs immédiates là où les méthodes précédentes ne fonctionnent plus sous leur ancien nom.
Plusieurs fonctions principales ont été renommées ou supprimées. La méthode melt est désormais unpivot, un nom jugé plus intuitif pour transformer des données du format large au format long. join_nulls a été renommé nulls_equal pour plus de clarté dans les opérations de jointure. De plus, LazyFrame.profile n'est plus disponible.
Les changements reflètent une transition vers une exécution paresseuse (lazy) optimisée et une gestion plus stricte des données. Par exemple, read_csv exploite désormais en interne scan_csv().collect(), offrant une optimisation paresseuse automatique. La combinaison d'entiers 64 bits signés et non signés produit désormais un type Int128, évitant la perte de précision silencieuse précédemment causée par la conversion en float.
La migration est facilitée par une meilleure gestion des erreurs. Les fonctions supprimées génèrent désormais une AttributeRemovedError, qui détaille explicitement la méthode de remplacement. Cette approche conviviale pour les développeurs garantit qu'un appel à melt suggérera directement l'utilisation de unpivot, permettant des correctifs ciblés et minimisant les temps d'arrêt.
Le piège silencieux : l'ordre des lignes n'est pas garanti
Polars 2.0 introduit un streaming engine par défaut pour toutes les requêtes LazyFrame, qui ne garantit pas l'ordre des lignes pour des opérations incluant join, group_by et unpivot. Ce changement architectural fondamental, conçu pour obtenir des gains significatifs de performance et d'efficacité mémoire, traite les données par petits blocs parallèles. Cela peut subtilement modifier la séquence des lignes dans la sortie, représentant un changement cassant silencieux pour le code existant.
Ce changement comporte un risque critique : les données de sortie peuvent être numériquement correctes tout en étant silencieusement attachées aux mauvaises lignes. De telles divergences conduisent à une corruption subtile des données, extrêmement difficile à détecter et à déboguer, pouvant compromettre les analyses en aval. Contrairement aux changements d'API explicites, ce problème ne déclenche pas immédiatement d'erreur, ce qui en fait un piège dangereux.
Les utilisateurs ayant besoin d'un ordre de lignes spécifique doivent désormais définir explicitement maintain_order=True sur les opérations concernées. Ce mandat est qualifié de « bonne rupture » (good breaking change) par les développeurs de Polars, obligeant les utilisateurs à définir la correction des données plutôt que de compter sur la préservation fortuite des lignes de l'ancien moteur. Pour des détails complets sur les modifications de Polars 2.0, lisez le Version 2.0-rc - Polars user guide.
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
Pourquoi cette mise à jour « ennuyeuse » est importante pour l'IA
Polars 2.0 renforce sa position en tant qu'alternative haute performance basée sur Rust à Pandas, spécifiquement conçue pour les charges de travail de données à grande échelle sur une seule machine. Cette version, dépourvue de nouvelles fonctionnalités destinées aux utilisateurs, est une refonte architecturale critique axée sur la stabilité à long terme, l'efficacité de la mémoire et les performances. Elle traite les mécanismes sous-jacents du moteur et la cohérence de l'API, qui sont essentiels pour les applications exigeantes de science des données et d'IA où la vitesse de traitement et la gestion des ressources sont primordiales.
Le nettoyage interne ouvre directement la voie à des capacités avancées cruciales pour le traitement futur des données et l'entraînement des modèles d'IA. Les développements à venir incluent un cost-based planner, conçu pour optimiser intelligemment les plans d'exécution de requêtes complexes, et des algorithmes de join reordering améliorés qui augmentent les performances pour les fusions de données complexes. Ces améliorations architecturales, couplées à une expansion significative de la couverture SQL, permettront à Polars de relever des défis analytiques sophistiqués avec une plus grande efficacité et fiabilité, réduisant les goulots d'étranglement dans la préparation des données.
Les développeurs considèrent cette mise à jour « ennuyeuse » comme un investissement stratégique dans la solidité fondamentale, privilégiant la robustesse aux fonctionnalités tape-à-l'œil immédiates. Le nouveau streaming engine par défaut, qui traite les données en petits morceaux parallèles (morsels), devrait rendre la plupart des requêtes « facilement 5 fois plus rapides » dans l'ensemble. Polars 2.0 représente une décision délibérée de consolider son architecture de base, garantissant un avenir de traitement des données plus rapide et plus robuste, capable de soutenir les besoins évolutifs des pipelines d'IA et de machine learning qui exigent une manipulation de données cohérente et à haut débit.
Foire aux questions
Pourquoi Polars 2.0 est-il une version « avec rupture » sans nouvelles fonctionnalités ?
Polars 2.0 est une version de « nettoyage » axée sur l'architecture interne et la cohérence de l'API. Elle introduit un nouveau moteur de requête par défaut et renomme plusieurs méthodes, ce qui peut casser le code existant, mais ces changements posent une base plus solide pour le développement futur.
Quel est le changement le plus important dans Polars 2.0 ?
Le changement le plus critique est que le nouveau 'streaming engine' par défaut ne garantit pas l'ordre des lignes pour des opérations comme les jointures (joins) et les regroupements (group-bys). Les utilisateurs doivent désormais définir explicitement maintain_order=True pour éviter des problèmes d'intégrité des données silencieux.
Comment corriger mon code après la mise à niveau vers Polars 2.0 ?
La plupart des changements avec rupture déclencheront une AttributeRemovedError qui vous indique exactement quoi utiliser à la place (par exemple, remplacez melt par unpivot). Pour les erreurs silencieuses potentielles, passez en revue tout code où l'ordre des lignes est critique et ajoutez maintain_order=True.
Polars 2.0 est-il plus rapide que les versions précédentes ?
Oui. Grâce au nouveau streaming engine par défaut qui traite les données en morceaux parallèles, la plupart des requêtes devraient être nettement plus rapides, avec un gain de performance global estimé à environ 5x.
Polars 2.0 prend-il en charge les jeux de données plus volumineux que la RAM ?
Pas encore totalement. Bien que le streaming engine soit une étape fondamentale vers un véritable traitement out-of-core, l'implémentation actuelle nécessite toujours que le jeu de données tienne en mémoire. Une prise en charge complète du traitement out-of-core est prévue pour une version ultérieure.