La bibliothèque de DataFrame Python Ibis abandonne les backends Pandas et Dask

• Les backends pandas et dask sont abandonnés et seront supprimés dans la version 10.0
• Il n’y a plus de différence fonctionnelle entre le backend pandas et le backend DuckDB par défaut, tandis que DuckDB offre des performances bien supérieures
• Les DataFrame pandas peuvent toujours être utilisés dans Ibis comme format d’échange de données, mais l’exécution de requêtes avec pandas n’est plus prise en charge
• L’essentiel de cette logique s’applique aussi au backend dask, et dask reste un excellent projet à continuer d’utiliser en dehors d’Ibis

Pourquoi pandas ? Et l’histoire d’Ibis

• Au début d’Ibis, seul le backend Impala existait
• Un backend Postgres a été ajouté, mais son installation était complexe, ce qui empêchait les utilisateurs d’essayer facilement Ibis
• Il fallait un moyen de tester l’API d’Ibis sans infrastructure supplémentaire en dehors d’un notebook
• À l’époque, connecter le backend pandas, le seul moteur de DataFrame en mémoire disponible, était la réponse évidente

Les difficultés du backend Pandas

• pandas était alors le meilleur choix, mais il s’accordait mal avec le modèle d’analyse de données d’Ibis
• Le backend pandas est fondamentalement différent des autres backends et contient le plus grand nombre de traitements spécifiques
• pandas est essentiellement un moteur à exécution immédiate, tandis qu’Ibis utilise un modèle d’exécution différée
• Il est difficile de faire fonctionner l’interface de pandas selon une approche différée
• Le backend pandas est plus lent que les autres backends, tout en nécessitant des milliers de lignes de code
• Le NaN de pandas et le NULL d’Ibis sont des concepts fondamentalement différents, mais il faut malgré tout les traiter comme équivalents
  • Dans pandas, NaN a été utilisé comme indicateur de valeur manquante, mais cela posait des problèmes de compatibilité avec les autres backends
  • NULL représente une valeur manquante, tandis que NaN signifie qu’une valeur n’est pas un nombre : ce sont des concepts fondamentalement différents
• Les nouveaux types de pandas basés sur Arrow constituent une amélioration majeure, mais des problèmes subsistent

Une source de confusion pour les nouveaux utilisateurs

• Les gens préfèrent ce qu’ils connaissent déjà
• Lors d’une première utilisation d’Ibis, il faut choisir à la fois Ibis et un backend
• Les nouveaux utilisateurs signalent souvent qu’« Ibis est lent »
• C’est en grande partie parce qu’ils utilisaient le backend pandas
• Avec DuckDB ou Polars, leurs débuts auraient probablement été bien plus simples

Équivalence fonctionnelle

• La raison la plus forte de supprimer le backend pandas est sa redondance
• Le backend DuckDB peut interroger sans friction des DataFrame pandas, prend en charge plusieurs formes d’UDF et peut lire et écrire divers formats comme parquet, CSV, JSON, etc.
• DuckDB est facile à installer, s’exécute en local, est extrêmement rapide et interagit bien avec l’écosystème Python

Le résumé de GN⁺

• Le choix d’adopter DuckDB comme backend par défaut semble très judicieux. Il est facile à installer, s’exécute en local, est très rapide et interagit bien avec l’écosystème Python. C’était d’ailleurs aussi la raison pour laquelle Ibis avait initialement ajouté pandas comme backend
• Le fait que pandas puisse toujours servir de format d’échange de données est une bonne nouvelle pour les utilisateurs existants de pandas. Il n’est pas nécessaire d’abandonner entièrement le code existant
• En revanche, ne plus utiliser pandas pour exécuter les requêtes semble aller dans la bonne direction. Le modèle d’exécution immédiate de pandas ne correspond pas au modèle d’exécution différée d’Ibis. Pour cette raison, le backend pandas est souvent bien plus lent que l’utilisation directe de pandas
• À mesure qu’Ibis prend en charge toujours plus de backends, maintenir du code adapté à des backends spécifiques devient de plus en plus difficile. Supprimer le backend pandas rendra la base de code plus propre et plus facile à maintenir
• Si l’utilisation du backend DuckDB permet de remplacer toutes les fonctionnalités de pandas, il ne semble plus y avoir de raison de conserver le backend pandas. Au contraire, cela peut semer la confusion chez les nouveaux utilisateurs

[yangeok]

En réalité, on utilise encore beaucoup le très familier pandas,,

[GN⁺]

Avis Hacker News

• NaN est le résultat de 0/0, ce qui signifie qu’une valeur existe mais qu’on ne la connaît pas précisément

  • NULL signifie qu’on ne connaît pas la valeur à un emplacement donné
  • L’implémentation de NaN et de NULL diffère, mais ils ne sont pas totalement sans rapport
  • Le None de Python est différent de NaN et de NULL

• Il existe beaucoup de moteurs de calcul meilleurs que pandas

  • On continue d’utiliser pandas à cause du code existant et des intégrations tierces
  • Pour les petits traitements de données, pandas reste tout à fait adapté

• Depuis quelques mois, pandas est remplacé par ibis dans les nouveaux projets

  • La syntaxe d’ibis est plus flexible que celle de pandas
  • L’enchaînement des opérations rend les extraits de code plus portables
  • Le backend DuckDB est très rapide
  • La communauté est très active et bienveillante
  • ibis est recommandé aux collègues

• La fonctionnalité de multi-index de pandas est sa plus grande force

  • Elle peut aussi être utilisée sur les colonnes
  • On ne sait pas trop comment les nouveaux outils vont gérer cette fonctionnalité

• Je me demande si Polars a été envisagé

  • Dans le groupe, on n’aime pas pandas, donc Polars est utilisé comme standard

• pandas peut être étendu à de nouveaux types de colonnes

  • Je ne suis pas certain que Polars le prenne en charge

• La valeur d’Ibis ne vient pas du fait qu’il permet d’utiliser DuckDB

  • Même si de nouveaux outils apparaissent, la syntaxe continue de fonctionner

• Je n’ai pas beaucoup entendu parler d’Ibis

  • Si je quitte pandas, j’aurai moins de chances d’essayer Ibis
  • De nouveaux frameworks s’éloignent de pandas/numpy, mais je vais attendre que la compatibilité et les cas limites soient réglés
  • Attendre quelques millisecondes de plus ne me dérange pas

• L’API de bibliothèque de pandas n’est pas toujours intuitive

  • Il y a le problème NaN/None, mais ce n’est qu’un inconvénient mineur

• Si pandas est utilisé, c’est grâce à son écosystème intégré

  • pandas est pratique pour lire des données depuis des fichiers json, des fichiers csv, des dictionnaires Python, etc., puis les visualiser avec plotly
  • Si Ibis est compatible avec les DataFrames pandas, le backend m’importe peu