Polars

 (pola.rs)
4 points par GN⁺ 2024-01-09 | 1 commentaires | Partager sur WhatsApp
  • Bibliothèque DataFrame open source destinée aux environnements nécessitant un traitement rapide des données sur une seule machine, avec plus de 575 millions de téléchargements et plus de 38 000 étoiles GitHub
  • Ses performances reposent principalement sur un moteur de requêtes multithread basé sur Rust, le traitement orienté colonnes, la vectorisation, SIMD et l’exécution parallèle
  • Elle reste disponible comme bibliothèque open source sous licence MIT, avec également Polars Cloud, qui permet d’étendre les workloads de production avec la même API
  • Revendique des performances plus de 30 fois supérieures à pandas ; le benchmark TPC-H dérivé a été exécuté sur c3-highmem-22 avec un scale factor de 10 et en incluant les E/S
  • Prend en charge CSV, JSON, Parquet, Delta Lake, AVRO, Excel, Arrow, les principales bases de données, ainsi que le stockage S3 et Azure, ce qui facilite son intégration aux stacks de données existantes

Modes de distribution de Polars

  • Polars est une bibliothèque open source de manipulation de données, qui s’impose comme l’une des solutions de traitement de données les plus rapides sur une seule machine
  • Elle fournit une API structurée et typée, avec pour objectifs à la fois l’expressivité et la facilité d’utilisation
  • Les indicateurs publics actuels sont les suivants
    • Plus de 575 M de téléchargements
    • Plus de 38 k étoiles GitHub
  • La documentation de démarrage est disponible sur Get started

  • Polars open source

    • Polars est une bibliothèque open source utilisable gratuitement sous licence MIT
    • Elle est proposée comme bibliothèque DataFrame haute performance, avec une installation simple
    • Exemples d’installation
      • Python : pip install polars
      • Rust : polars = { version = "x", features = ["lazy", ...]}
      • Node.js : const pl = require('nodejs-polars');

  • Polars Cloud

    • Polars Cloud est une solution managée qui étend les requêtes Polars exécutées dans des environnements notebook vers des workloads de production dans le cloud ou on-premise
    • Elle permet de passer à l’échelle avec la même API, sans modifier le code
    • Les modes de déploiement Cloud et On-Prem sont pris en charge
    • La facturation ne porte que sur l’exécution des requêtes
    • L’essai est disponible sur Polars Cloud

Modèle de performance et intégration des données

  • Les performances de Polars reposent sur un moteur de requêtes multithread basé sur Rust et une conception axée sur le traitement parallèle
  • La vectorisation et le traitement orienté colonnes permettent des algorithmes cohérents avec le cache et des performances élevées sur les processeurs modernes
  • Polars a été comparé à plusieurs solutions dans un benchmark TPC-H indépendant dérivé, visant à reproduire des tâches pratiques de préparation de données
    • Des gains de performance de plus de 30 fois sont possibles par rapport à pandas
    • Le benchmark a été exécuté sur c3-highmem-22 avec un scale factor de 10 et en incluant les E/S
    • Les requêtes sont publiées en open source
    • Plus d’informations sont disponibles sur Learn more

  • Ergonomie et optimisation de l’exécution

    • Les utilisateurs écrivent leurs requêtes de la manière souhaitée, et l’optimiseur de requêtes de Polars détermine le mode d’exécution efficace
    • Les tâches sont réparties entre les cœurs CPU disponibles pour une exécution parallèle, sans configuration supplémentaire ni surcharge de sérialisation
    • Le modèle mémoire Apache Arrow permet l’intégration avec les outils de données existants
    • Le partage de données en zero-copy réduit le coût de collaboration entre outils
    • Conçu au plus près de la machine, sans dépendances externes, il permet de contrôler l’API, la mémoire et l’exécution
    • Les jeux de données plus grands que la mémoire peuvent être traités avec l’API de streaming, sans charger l’intégralité des données en mémoire

  • Formats de données pris en charge

    • Polars prend en charge la lecture et l’écriture des formats de données courants afin de s’intégrer aux stacks de données existantes
    • La prise en charge couvre les éléments suivants
      • Texte : CSV, JSON
      • Binaire : Parquet, Delta Lake, AVRO, Excel
      • IPC : Feather, Arrow
      • Bases de données : MySQL, Postgres, SQL Server, Sqlite, Redshift, Oracle
      • Stockage cloud : S3, Azure Blob, Azure File

À lire aussi

1 commentaires

 
GN⁺ 2024-01-09
Avis sur Hacker News

  • Il est très clair que cette page s’adresse à des gens qui savent déjà ce qu’ils regardent. Dès la première phrase, elle ne décrit pas l’outil, mais parle de qualité avec « Polars is written from the ground up with performance in mind », et le reste suit la même logique.
    Quelqu’un peut-il expliquer comme à un enfant de 5 ans ce que c’est et à quels besoins cela répond bien ?
    Mise à jour : j’ai fini par comprendre qu’il s’agit d’une implémentation alternative au DataFrame de Pandas. D’après l’explication trouvée sur Google à l’adresse https://realpython.com/pandas-dataframe/, un DataFrame est une structure qui contient des données bidimensionnelles et des libellés ; il est largement utilisé dans des domaines intensifs en données comme la data science, le machine learning et le calcul scientifique, et ressemble à une table SQL ou à une feuille de calcul Excel/Calc.

    • C’est précisément l’un des défauts agaçants de beaucoup de produits techniques. Il est naturel de vouloir parler au public cible — ici des data scientists qui aiment Pandas mais le trouvent lent et peu flexible —, mais pour les débutants, cela donne l’impression d’être exclus.
      Je fais partie du public cible de Polars et j’essaie de m’y mettre depuis des mois, mais je repousse sans cesse. Je garde une certaine loyauté envers Pandas parce que Wes McKinney, son créateur, a écrit un livre utile qui explique les outils d’analyse courants : https://wesmckinney.com/book/.
    • C’est Pandas, mais rapide. Pandas est la bibliothèque open source de DataFrame d’origine ; elle est robuste et largement utilisée, mais son périmètre est vaste et elle semble plus lente que ce nouvel acteur. Le terme « DataFrame » parle immédiatement à ceux qui en ont déjà utilisé.
    • Chaque fois que je vois ce genre de page, ça me rend humble. « DataFrame for the new Era » : je me demande si je sais vraiment ce qu’est un DataFrame ; puis je vois « moteur de requêtes multithread » et je me demande si c’est une sorte de base de données.
      Il y a un graphique qui compare avec des choses appelées pandas, modin, vaex, mais comme je ne les connais pas du tout non plus, je me dis finalement que ce n’est pas fait pour moi. J’aime lire et apprendre sur de nouvelles technologies ou de nouveaux projets, mais ici je n’ai rien à quoi me raccrocher.
      C’est probablement ce que vivent les gens ordinaires quand je parle de mon petit monde du développement web.
    • Pour être juste, le titre de la page est « Dataframes for the new Era », et le lien Get Started sous le titre pointe vers une documentation sur la page GitHub. GitHub explique ce qu’est cette bibliothèque aux personnes ayant un bagage en analyse de données : https://github.com/pola-rs/polars
    • Je suis en train de me faire aspirer par le monde des « données », et c’est comme un univers parallèle avec son propre contexte et sa propre culture. On y trouve beaucoup de formulations du genre « se connecter à une instance Antelope ou Meringue avec l’utilisabilité de Nincompoop et les performances d’ARSE2 ».
      Ce qui est intéressant avec Polars, c’est que c’est similaire à Pandas, mais qu’il utilise Arrow, un backend Rust plus efficace, et qu’il dispose d’un planificateur de requêtes ou quelque chose du genre pour rendre les combinaisons d’opérations plus efficaces. En général, Polars est bien plus efficace que Pandas, si bien que des tâches qui nécessitaient auparavant une infrastructure complexe peuvent souvent être exécutées sur une seule machine.
      C’est une concurrence très amicale, créée par un développeur clé de Pandas ; tout le monde semble l’apprécier et, avec le temps, il paraît très probable que Polars remplace Pandas.

  • Articles liés :
    Detailed Comparison Between Polars, DuckDB, Pandas, Modin, Ponder, Fugue, Daft - https://news.ycombinator.com/item?id=37087279 - août 2023
    Polars: Company Formation Announcement - https://news.ycombinator.com/item?id=36984611 - août 2023
    Replacing Pandas with Polars - https://news.ycombinator.com/item?id=34452526 - janvier 2023
    Fast DataFrames for Ruby - https://news.ycombinator.com/item?id=34423221 - janvier 2023
    Modern Polars: A comparison of the Polars and Pandas dataframe libraries - https://news.ycombinator.com/item?id=34275818 - janvier 2023
    Rust polars 0.26 is released - https://news.ycombinator.com/item?id=34092566 - décembre 2022
    Polars: Fast DataFrame library for Rust and Python - https://news.ycombinator.com/item?id=29584698 - décembre 2021
    Polars: Rust DataFrames Based on Apache Arrow - https://news.ycombinator.com/item?id=23768227 - juillet 2020

  • J’ai utilisé Pandas pendant des années, mais j’ai toujours eu l’impression de pousser une boule en haut d’une colline. Rien que pour des opérations simples comme les jointures, et il ne faut pas oublier non plus de réinitialiser l’index
    Polars me paraît meilleur que Pandas à presque tous les égards. Il est plus rapide, utilise plusieurs cœurs, consomme moins de mémoire et son API est plus intuitive. Comme c’est encore une bibliothèque relativement jeune, elle a des défauts, mais pour un nouveau projet, elle mérite au moins d’être examinée
    Le fait de pouvoir exploiter facilement l’écosystème Rust est aussi excellent. J’ai écrit moi-même un plugin pour paralléliser une fonction, et rendu une partie de mon code géospatial 100 fois plus rapide

    • C’est un peu ironique de prendre les jointures comme exemple. J’ai toujours pensé que le plus gros problème de Pandas, c’était sa documentation. Par exemple, savais-tu qu’il existe une façon de joindre des dataframes sans utiliser les index ? Ça ne s’appelle pas “join”, mais merge
      À ses débuts, Pandas a été fortement influencé par la terminologie et les usages de R, où “merge” était déjà un terme courant pour dire “join”. Si on ne connaissait pas déjà R vers 2015, quand on commençait à apprendre Pandas, ça devait être difficile à assimiler rapidement
    • Je serais curieux de savoir ce que vous pensez de PRQL (prql-lang.org). Personnellement, je trouve qu’il combine l’ergonomie et l’expérience développeur de Polars ou Pandas avec la puissance et l’universalité de SQL
      Les requêtes peuvent s’exécuter non seulement avec Polars et Pandas, mais aussi sur le moteur d’exécution compatible SQL de votre choix : DuckDB, ClickHouse, BigQuery, Redshift, Postgres, Trino/Presto, SQLite, etc.
      La syntaxe et la sémantique des jointures font partie des points les plus délicats, et nous en rediscutons récemment. C’est au cœur de l’algèbre relationnelle, et c’est aussi le R de PRQL. La plupart des transformations de base de PRQL sont de simples manipulations de listes comme map, filter ou reduce, mais les jointures demandent de l’attention si l’on veut préserver la composition monadique. J’ai laissé mes réflexions ici : https://github.com/PRQL/prql/issues/3782#issuecomment-1811312787
      Cette issue est fermée, mais n’hésitez pas à en ouvrir une nouvelle ou à me taguer avec @snth pour donner votre avis. À noter que je suis contributeur de PRQL
    • Je me demande ce qu’il y a de difficile dans la fusion de dataframes Pandas

  • Après évaluation, le plus gros avantage était que l’API était bien plus cohérente et facile à comprendre que celle de Pandas. C’est aussi logique, puisqu’ils ont pu apprendre des 20 grandes versions de Pandas
    En revanche, comme Polars est beaucoup moins utilisé, Copilot écrivait mal le code Polars. Donc pour l’instant, je continue avec Pandas et Copilot. C’est la première fois que je ressens ce genre de barrière pour les nouvelles bibliothèques en général

    • C’est la première fois que je vois quelqu’un dire publiquement qu’il privilégie une bibliothèque à cause du support de Copilot. Je ne juge pas, je trouve ça intéressant
      Cela dit, Copilot apprend très vite dans un dépôt. J’utilise une stack extrêmement personnalisée construite avec TS-Plus, un fork de TypeScript que même son auteur n’utilise ni ne recommande, et Copilot produit du code TS-Plus plutôt bon
      Après avoir vu quelques exemples, il ne faut pas sous-estimer à quel point Copilot peut devenir assez bon sur le code répétitif
    • Le support de Copilot est un problème de poule et d’œuf. Il doit apprendre à partir du code des autres, mais si les gens n’écrivent pas de code Polars sans Copilot, Copilot ne deviendra pas meilleur pour écrire du code Polars
    • J’ai eu quelque chose de similaire en utilisant danfo.js, une autre bibliothèque de dataframes pour JS. Copilot hallucinait purement et simplement les fonctionnalités et les noms de méthodes
      Ce n’était pas un gros problème, puisqu’il suffit de lire la documentation, mais c’était pénible que Copilot ne puisse pas recracher directement ce dont j’avais besoin
    • Tu reconnais que l’API est plus cohérente et plus facile à comprendre, mais tu vas rester sur Pandas uniquement parce que Copilot te facilite la tâche ? Il vaut mieux utiliser l’outil que tu reconnais toi-même comme meilleur, pour toi comme pour l’innovation open source
      J’ai longtemps utilisé l’API de Pandas et je l’ai détestée. Je suis plutôt proactif quand il s’agit de continuer à améliorer mon apprentissage, mes outils, ma façon de penser et mes compétences
    • La bibliothèque Polars évolue vite. Je n’utilise pas Copilot, mais en donnant au système des consignes avec des informations récentes, par exemple que with_column est devenu with_columns, et en ajoutant le contenu de la documentation, j’ai obtenu de très bons résultats avec ChatGPT

  • Quand Deno a lancé le support de Jupyter, nodejs-polars faisait partie des bibliothèques clés de data science prises en charge
    https://blog.jupyter.org/bringing-modern-javascript-to-the-jupyter-notebook-fc998095081e
    Personnellement, je ne viens pas du monde de la data science, mais vu que l’écosystème JS/Jupyter en est encore à ses débuts, j’ai été surpris de voir à quel point il était rapide de lancer de l’analyse basée sur pola.rs en TypeScript
    Les bindings JS ont clairement des points à améliorer, mais j’espère que cette accessibilité accrue entraînera des améliorations itératives

    • J’ai toujours voulu quelque chose comme Pandas en JS, je découvre ça

  • Polars me paraît vraiment prometteur et ses performances sont impressionnantes, mais ça me gêne de voir vaex, modin et dask comparés dans le même benchmark
    Toutes ces bibliothèques visent le traitement de données hors mémoire, c’est-à-dire les cas où les données sont trop volumineuses et où les calculs se font sur plusieurs machines. Les comparer à une bibliothèque de dataframes pour une seule machine est étrange, et comme elles ont forcément beaucoup d’overhead, elles seront nécessairement plus lentes
    On utilise rarement Polars dans le même contexte que ces bibliothèques, donc le présenter comme équivalent dans un benchmark est un peu ridicule. En plus, DuckDB, qui peut être utilisé dans les mêmes contextes que Polars et qui est souvent plus rapide, n’apparaît pas dans le benchmark
    Le travail d’ingénierie logicielle derrière Polars est excellent, et il n’a pas besoin de benchmarks aussi trompeurs

    • Je ne sais pas pour les autres, mais Dask peut aussi s’utiliser sur une seule machine, et c’est même la façon la plus simple de l’utiliser. Il découpe un dataframe en partitions et les traite sur chaque cœur pour paralléliser les opérations
      Sans configuration, on peut obtenir 2 fois les performances de Pandas, et j’ai vu jusqu’à 5 fois sur certaines opérations
    • Ibis, le dataframe Python créé par le fondateur de Pandas, utilise DuckDB comme backend par défaut et, à l’exception de quelques cas particuliers de requêtes, bat généralement Polars dans ce genre de benchmarks

  • Je n’utilise pas directement Polars, mais comme format matérialisé dans un workflow DuckDB.
    duckdb.query(sql).pl() est beaucoup plus rapide que duckdb.query(sql).df(). Avec Polars, c’est du zéro copie et ça se termine instantanément, alors qu’avec Pandas, si le DataFrame est gros, cela peut prendre un bon moment. Et, à quelques différences de syntaxe près, on peut le manipuler comme un DataFrame Pandas.
    C’est très bien pour traiter de gros jeux de données.

  • Il doit exister un corollaire à la dixième règle de Greenspun (https://en.wikipedia.org/wiki/Greenspun's_tenth_rule)) : toute bibliothèque d’analyse de données suffisamment complexe finit par implémenter la moitié de SQL de façon bricolée, non spécifiée, pleine de bugs et lente.
    J’utilise Pandas de temps en temps et j’essaierai probablement aussi celui-ci, mais je me dis toujours que j’aurais mieux fait de mettre dès le départ les données sur lesquelles je travaille dans Postgres.
    Je ne suis pas expert en bases de données et Python m’est beaucoup plus confortable, mais pour sélectionner, trier, filtrer et joindre des données tabulaires, SQL est nettement meilleur.

    • Je recommande de regarder DuckDB et l’extension duckdb-prql.
      DuckDB permet de manipuler directement en SQL des données aux formats Polars, Pandas et Arrow, sans copie ni duplication des données.
      duckdb-prql permet d’utiliser PRQL (prql-lang.org) et, personnellement, je trouve que cela combine la puissance et l’universalité de SQL avec le ressenti d’utilisation et l’expérience développeur de Polars ou Pandas. À noter que je contribue à PRQL.
    • On peut faire comme ça, mais pour des requêtes « analytiques », les performances risquent d’être bien moins bonnes, avec moins de souplesse et d’expressivité.
      À la place, DuckDB vaut le coup d’œil. Son implémentation de SQL n’est pas bricolée, ni truffée de bugs, lente ou incomplète. Je ne sais pas trop ce qu’il en est de la formalité de la spécification, mais il est compatible avec Polars.
    • Personnellement, je trouve que la syntaxe des dataframes paresseux est une bien meilleure interface front-end pour un moteur de requêtes. Polars prend aussi en charge SQL, mais les bugs viennent généralement du moteur de requêtes, pas du front-end.
      Pour les types de requêtes que l’on exécute avec ce genre de moteur, Postgres sera probablement plus lent d’un ordre de grandeur qu’un moteur de requêtes OLAP.
    • Le créateur de Pandas a créé Ibis avec un backend Postgres pour cette raison : https://ibis-project.org/backends/postgresql
      C’est une meilleure approche pour utiliser ensemble les dataframes Python et SQL.

  • Il y a quelques mois, j’ai essayé de porter une grosse base de code Pandas vers Polars. Je n’aime pas beaucoup faire de l’analyse ou du data pipelining en Python, car les transformations complexes prennent 2 à 5 fois plus de temps dans Pandas qu’en Julia ou en R (avec dataframes.jl, dplyr).
    Malheureusement, Polars n’était pas non plus la solution. Il y avait trop de bugs dans les opérations standard, et l’interopérabilité avec Pandas était fragile. C’est un problème, car beaucoup de bibliothèques exigent un DataFrame Pandas en entrée. L’API est aussi très verbeuse pour une bibliothèque de dataframes moderne, même si elle reste meilleure que Pandas.
    J’espère que cela se réglera avec le temps, mais pour l’instant, le mieux a été d’utiliser DuckDB par-dessus Pandas. C’est aussi rapide que Polars, tout en étant plus stable et avec une meilleure interopérabilité.
    J’espère qu’un jour l’écosystème Python des dataframes atteindra un stade comparable à R, où l’on peut utiliser facilement à la fois une bibliothèque de dataframes orientée analyse avec une API intuitive (dplyr) et une bibliothèque de dataframes haute performance (data.table).

    • Moi aussi, la verbosité m’a agacé. Pandas est déjà assez verbeux par rapport à quelque chose comme data.table, mais Polars donne davantage l’impression d’utiliser une API que celle d’un « outil de manipulation de données ».
      Je ne pense pas que je l’utiliserai pour l’analyse exploratoire ou la recherche, mais j’ai commencé à l’employer dans certains scripts de production grâce à ses meilleures performances.
      La combinaison dplyr + data.table en R reste mon expérience préférée pour la manipulation de données. J’aimerais simplement que R ait quelque chose comme Matplotlib. ggplot est trop haut niveau, et les graphiques de base sont trop bas niveau. Scikit-Learn est aussi beaucoup plus modulaire que Caret, donc Caret ne me manque pas.
    • Je serais curieux de savoir ce que vous pensez de PRQL (prql-lang.org). Son objectif est d’offrir l’ergonomie de dplyr partout où l’on utilise SQL, et il se compile en SQL.
      Personnellement, je trouve qu’il combine l’expérience développeur de dplyr, Polars et Pandas avec la puissance et l’universalité de SQL. Les requêtes peuvent s’exécuter sur le moteur compatible SQL de votre choix, non seulement Polars et Pandas, mais aussi DuckDB, ClickHouse, BigQuery, Redshift, Postgres, Trino/Presto, SQLite, etc.
      J’aimerais connaître votre avis dans les discussions GitHub (https://github.com/PRQL/prql/discussions) ou sur Discord (https://discord.com/invite/XWxbCrWr). À noter que je contribue à PRQL.
    • C’est intéressant que vous ayez utilisé les dataframes de R, Python et Julia. Je serais curieux de savoir lequel vous préférez. Les écosystèmes ne sont sans doute pas directement comparables, mais pour des tâches comme les opérations de base, lequel vous a semblé le meilleur ?
    • Ibis avec un backend DuckDB vaut aussi le coup d’être essayé. Personnellement, j’aime aussi assez Polars. Les développeurs réagissent globalement assez vite aux issues.

  • Notre équipe data science a évalué Polars, avec des résultats mitigés. S’il y a des sections où les performances sont critiques, nous envisagerions de l’adopter, mais en dehors de cela, nous étions plutôt réservés à cause du coût de remplacement de Pandas dans des dizaines de projets.

    • Je pense que ce jugement est juste. Pour l’instant, je pense que c’est plutôt le moment d’expérimenter que de remplacer un Pandas qui fonctionne déjà très bien.
      L’API comporte encore des changements cassants prévisibles, ce qui peut devenir une charge de maintenance sur plusieurs projets. Cela dit, l’API semble déjà plus cohérente, et dans l’ensemble elle paraît aller dans la bonne direction.
    • Mieux vaut ne pas réécrire tout le code. En revanche, pour du nouveau code, cela vaut la peine de l’adopter ou de l’évaluer.
      En particulier, le coût d’interopérabilité avec Pandas est très faible, et avec le backend Arrow, il est même assez facile de passer à Pandas en zéro copie.
    • Pour la suite, il y a https://github.com/fugue-project/fugue.
    • Je me demande si votre équipe utilise pandasql, ou si elle utilise surtout directement l’API Pandas.