Polars vs. pandas : quelles sont les principales différences ?

Si vous avez suivi les avancées des dataframes en Python, vous avez sans doute entendu parler de Polars, la puissante bibliothèque de dataframes conçue pour travailler avec de grands jeux de données.

Contrairement aux autres bibliothèques pour les grands jeux de données tels que Spark, Dask et Ray, Polars est conçue pour être utilisée sur une seule machine, ce qui peut amener à la comparer à pandas. Toutefois, Polars présente de nombreuses différences significatives avec pandas, notamment en ce qui concerne la façon dont elle gère les données et les cas dans lesquels son utilisation est optimale. Dans cet article, nous allons examiner les détails techniques qui différencient ces deux bibliothèques de dataframes, ainsi que les points forts et les limites de chacune.

Si vous souhaitez aller plus loin, vous pouvez écouter notre entretien avec Ritchie Vink, le créateur de Polars, disponible ci-dessous !

Pourquoi utiliser Polars plutôt que pandas ?

La réponse se résume en un mot : performances. Polars a été construit dès le départ pour offrir une vitesse incomparable et peut exécuter des opérations courantes de 5 à 10 fois plus rapidement que pandas. De plus, les besoins en mémoire pour les opérations avec Polars sont nettement inférieurs à ceux des pandas : pandas requiert de 5 à 10 fois plus de RAM que la taille du jeu de données, contre 2 à 4 fois avec Polars.

Vous pouvez consulter une comparaison des performances de Polars avec celle des autres bibliothèques de dataframes ici. Comme vous pouvez le constater, Polars est de 10 à 100 fois plus rapide que pandas pour les opérations courantes et se distingue de manière générale comme étant l’une des bibliothèques de dataframes les plus rapides. De plus, par rapport à pandas, elle peut gérer des jeux de données plus grands avant que des erreurs dues à l’insuffisance de mémoire ne se produisent.

Pourquoi Polars est-elle si rapide ?

Ces résultats sont très impressionnants et vous vous demandez peut-être : comment Polars peut atteindre ces performances sur une seule machine ? La bibliothèque a été conçue dès le départ dans un souci de performance et plusieurs facteurs expliquent son efficacité.

Une bibliothèque écrite en Rust

L’un des faits les plus connus concernant Polars est qu’elle a été écrite en Rust, qui est un langage de bas niveau quasiment aussi rapide que C et C++. Pandas s’appuie quant à elle sur des bibliothèques Python, parmi lesquelles NumPy. Bien que le cœur de NumPy soit écrit en C, il reste limité par des problèmes inhérents à la manière dont Python gère certains types en mémoire, tels que les chaînes pour les données catégorielles, ce qui résulte en de mauvaises performances lors du traitement de ces types (vous pouvez lire ce très bon article de blog de Wes McKinney pour plus de détails à ce sujet).

L’un des autres avantages de l’utilisation de Rust est qu’il garantit une concurrence sûre, car il est conçu pour rendre le parallélisme aussi prévisible que possible. Polars peut ainsi utiliser tous les cœurs de votre unité centrale en toute sécurité, y compris pour les requêtes complexes impliquant plusieurs colonnes, à tel point que Ritchie Vink a décrit les performances de Polars comme étant « d’un niveau de parallélisme embarassant ». Cela confère à Polars des performances largement supérieures à celles de pandas, qui n’utilise qu’un seul cœur pour effectuer les opérations. Écoutez cette excellente intervention de Nico Kreiling lors de la PyCon DE 2024, qui explique en détail comment Polars parvient à obtenir ces résultats.

Une bibliothèque basée sur Arrow

Apache Arrow est un format de mémoire indépendant du langage qui contribue également aux performances impressionnantes de Polars. Arrow a été co-créé par Wes McKinney pour résoudre les nombreux problèmes qu’il avait constatés avec pandas lorsque que la taille des données explosait. Il s’agit également du backend de pandas 2.0, une version plus performante de pandas publiée en mars 2024. Toutefois, les backends Arrow des deux bibliothèques diffèrent légèrement : pandas 2.0 s’appuie sur PyArrow, tandis que l’équipe Polars a créé sa propre implémentation d’Arrow.

L’un des principaux avantages d’Arrow pour la création d’une bibliothèque de données est l’interopérabilité qu’il procure. Arrow a été conçu pour standardiser le format de données en mémoire entre les bibliothèques et il est déjà utilisé par plusieurs bibliothèques et bases de données importantes, comme vous pouvez le voir ci-dessous.

Cette interopérabilité accélère les performances, car elle évite d’avoir à convertir les données dans un format différent entre les différentes étapes du pipeline de données (en d’autres termes, elle évite de devoir sérialiser et désérialiser les données). Elle utilise également la mémoire plus efficacement, car deux processus peuvent partager les mêmes données sans avoir besoin de faire une copie. Étant donné que l’on estime que la sérialisation/désérialisation représente 80 à 90 % des coûts de calcul dans les workflows de données, le format de données commun d’Arrow offre à Polars des gains de performances significatifs.

Arrow fournit aussi une prise en charge intégrée pour davantage de types de données que pandas. La bibliothèque pandas étant basée sur NumPy, elle gère parfaitement les colonnes de valeurs entières et à virgule flottante, mais est bien moins efficace avec les autres types de données. Par contraste, Arrow offre une prise en charge avancée pour les données date/heure, booléennes, binaires, et même pour les types de colonnes complexes comme celles contenant des listes. De plus, Arrow est capable de traiter les données manquantes de façon native, alors que cela nécessite une solution de contournement dans NumPy.

Enfin, Arrow stocke les données par colonne, toutes les colonnes sont donc stockées dans un bloc de mémoire continu, quel que soit le type de données. Non seulement cela facilite le parallélisme, mais cela rend aussi la récupération des données plus rapide.

Optimisation des requêtes

L’une des autres raisons qui explique les performances de Polars réside dans la façon dont elle évalue le code. Pandas utilise l’exécution immédiate (eager) par défaut et effectue donc les opérations dans l’ordre dans lequel vous les avez écrites. Polars peut aussi bien utiliser l’exécution immédiate que l’exécution différée (lazy), dans lquelle un optimiseur de requêtes évalue toutes les opérations requises et cartographie la manière la plus efficace d’exécuter le code. Cela peut inclure, entre autres, la réécriture de l’ordre d’exécution des opérations ou l’abandon des calculs redondants. Prenons l’expression suivante pour obtenir la moyenne de la colonne Number1 pour chacune des catégories « A » et « B » dans Category.

(
df
.groupby(by = "Category").agg(pl.col("Number1").mean())
.filter(pl.col("Category").is_in(["A", "B"]))
)

Si cette expression est exécutée immédiatement, l’opération groupby sera inutilement effectuée pour l’ensemble du DataFrame et ensuite seulement filtrée par Category. Avec l’exécution différée, le DataFrame peut être filtré et l’opération groupby est effectuée seulement pour les données requises.

API expressive

Enfin, Polars dispose d’une API extrêmement expressive, ce qui signifie que toute opération que vous souhaitez effectuer peut être exprimée sous forme de méthode Polars. Dans pandas, les opérations plus complexes doivent souvent être transmises à la méthode apply en tant qu’expressions lambda. Le problème avec la méthode apply est qu’elle boucle sur les lignes du DataFrame et exécute l’opération de façon séquentielle sur chacune d’elles. La possibilité d’utiliser des méthodes intégrées vous permet de travailler au niveau des colonnes et de tirer parti d’une autre forme de parallélisme appelée SIMD.

Dans quels cas continuer à utiliser pandas ?

Tout cela paraît si génial que l’on peut se demander si cela vaut la peine de continuer à utiliser pandas. Pas si vite ! Mais bien que Polars soit extrêmement efficace pour effectuer des transformations de données, cela n’est pas l’option idéale pour l’exploration de données ou pour une utilisation dans le cadre de pipelines de machine learning. Dans ces domaines, pandas reste la meilleure solution.

En effet, bien que Polars offre une excellente interopérabilité avec d’autres paquets utilisant Arrow, elle n’est pas encore compatible avec la plupart des packages de visualisation des données, ni avec les bibliothèques de machine learning telles que scikit-learn et PyTorch. La seule exception est Plotly, qui permet de créer des graphiques directement depuis les DataFrames Polars.

L’une des solutions envisagées serait d’utiliser le Python dataframe interchange protocol dans ces packages pour leur permettre de prendre en charge plusieurs bibliothèques de dataframes afin d’d’élimininer les problèmes de goulots d’étrangement pour les workflows de science des données et de machine learning avec pandas. Toutefois, il s’agit d’une idée encore relativement nouvelle et il faudra encore patienter avant que ces projets ne soient implémentés.

Outils pour Polars et pandas

Après avoir lu tout cela, vous avez sûrement envie d’essayer Polars ! DataSpell et PyCharm Professional 2023.2 offrent d’excellents outils pour travailler avec pandas et Polars dans les notebooks Jupyter. Les dataframes pandas et Polars sont notamment affichés avec des fonctionnalités interactives, ce qui permet d’explorer les données plus facilement et rapidement.

La possibilité de faire défiler toutes les lignes et colonnes du DataFrame sans troncature, d’obtenir des agrégations des valeurs du DataFrame en un clic et d’exporter le DataFrame dans grand nombre de formats (y compris Markdown !) sont quelques-unes de mes fonctionnalités préférées.

Si vous n’utilisez pas encore DataSpell, vous pouvez l’essayer gratuitement pendant 30 jours en cliquant sur le lien ci-dessous.

Commencez votre essai gratuit de DataSpell

Auteur de l’article original en anglais :