Polars

 (pola.rs)
4 Punkte von GN⁺ 2024-01-09 | 1 Kommentare | Auf WhatsApp teilen
  • Open-Source-DataFrame-Bibliothek für Umgebungen, die schnelle Datenverarbeitung auf einer einzelnen Maschine benötigen; verzeichnet über 575 Mio. Downloads und mehr als 38.000 GitHub-Stars
  • Kern der Performance sind die Rust-basierte multithreaded Query Engine sowie spaltenorientierte Verarbeitung, Vektorisierung, SIMD und parallele Ausführung
  • Wird weiterhin als Open-Source-Bibliothek unter MIT-Lizenz angeboten; zusätzlich gibt es Polars Cloud, um mit derselben API bis hin zu Produktions-Workloads zu skalieren
  • Bewirbt eine mehr als 30-fache Leistungssteigerung gegenüber pandas; der abgeleitete TPC-H-Benchmark wurde auf c3-highmem-22 mit Scale Factor 10 und einschließlich I/O durchgeführt
  • Unterstützt CSV, JSON, Parquet, Delta Lake, AVRO, Excel, Arrow, wichtige Datenbanken sowie S3 und Azure Storage und lässt sich dadurch leicht an bestehende Daten-Stacks anbinden

Bereitstellungsmodell von Polars

  • Polars ist eine Open-Source-Bibliothek zur Datenmanipulation und hat sich als eine der schnellsten Lösungen für Datenverarbeitung auf einer einzelnen Maschine positioniert
  • Bietet eine strukturierte, typisierte API und zielt zugleich auf Ausdrucksstärke und Benutzerfreundlichkeit ab
  • Die derzeit veröffentlichten Kennzahlen lauten:
    • 575M+ Downloads
    • 38k+ GitHub-Stars
  • Die Einstiegsdokumentation ist unter Get started verfügbar

  • Open-Source-Polars

    • Polars ist eine unter der MIT-Lizenz frei nutzbare Open-Source-Bibliothek
    • Sie wird als leistungsstarke DataFrame-Bibliothek bereitgestellt und ist einfach zu installieren
    • Installationsbeispiele:
      • Python: pip install polars
      • Rust: polars = { version = "x", features = ["lazy", ...]}
      • Node.js: const pl = require('nodejs-polars');

  • Polars Cloud

    • Polars Cloud ist eine Managed Solution, die Polars-Queries aus Notebook-Umgebungen auf Produktions-Workloads in der Cloud oder On-Premises erweitert
    • Mit derselben API lässt sich ohne Codeänderungen skalieren
    • Unterstützte Bereitstellungsformen sind Cloud oder On-Prem
    • Abgerechnet wird nur die Query-Ausführung
    • Ein Test ist über Polars Cloud möglich

Performance-Modell und Datenintegration

  • Die Performance-Basis von Polars ist eine Rust-basierte multithreaded Query Engine und ein auf Parallelverarbeitung ausgelegtes Design
  • Vektorisierung und spaltenorientierte Verarbeitung ermöglichen cache-kohärente Algorithmen und hohe Performance auf modernen Prozessoren
  • In einem abgeleiteten, unabhängigen TPC-H-Benchmark wurde Polars mit mehreren Lösungen verglichen; Ziel war die Nachbildung praktischer Datenbereinigungsaufgaben
    • Gegenüber pandas sind mehr als 30-fache Performance-Steigerungen möglich
    • Der Benchmark wurde auf c3-highmem-22 mit Scale Factor 10 und einschließlich I/O durchgeführt
    • Die Queries sind als Open Source veröffentlicht
    • Weitere Details gibt es unter Learn more

  • Bedienbarkeit und Ausführungsoptimierung

    • Nutzer schreiben Queries so, wie sie es beabsichtigen, und der Query Optimizer von Polars bestimmt eine effiziente Ausführungsweise
    • Aufgaben werden auf die verfügbaren CPU-Kerne verteilt und ohne zusätzliche Konfiguration oder Serialisierungs-Overhead parallel ausgeführt
    • Das Apache Arrow-Speichermodell ermöglicht die Integration mit bestehenden Datenwerkzeugen
    • Zero-Copy-Datenaustausch kann den Aufwand für die Zusammenarbeit zwischen Tools reduzieren
    • Das System ist ohne externe Abhängigkeiten nah an der Maschine konzipiert, sodass API, Speicher und Ausführung kontrollierbar bleiben
    • Datensätze, die größer als der Arbeitsspeicher sind, werden über die Streaming API verarbeitet, ohne die gesamten Daten in den Speicher laden zu müssen

  • Unterstützte Datenformate

    • Polars unterstützt das Lesen und Schreiben gängiger Datenformate und kann so in bestehende Daten-Stacks integriert werden
    • Der unterstützte Umfang umfasst:
      • Text: CSV, JSON
      • Binary: Parquet, Delta Lake, AVRO, Excel
      • IPC: Feather, Arrow
      • Databases: MySQL, Postgres, SQL Server, Sqlite, Redshift, Oracle
      • Cloud storage: S3, Azure Blob, Azure File

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-01-09
Hacker-News-Kommentare

  • Diese Seite ist ganz offensichtlich für Leute geschrieben, die bereits wissen, worum es geht. Schon der erste Satz beginnt nicht mit einer Erklärung des Tools, sondern mit einer Aussage zur Qualität wie „Polars is written from the ground up with performance in mind“, und der Rest folgt demselben Muster.
    Kann jemand wie für einen Fünfjährigen erklären, was das ist und für welchen Bedarf es eine gute Lösung ist?
    Nachtrag: Ich habe es letztlich als alternative Implementierung eines Pandas DataFrame verstanden. Laut der Erklärung, die ich bei Google gefunden habe, https://realpython.com/pandas-dataframe/, ist ein DataFrame eine Struktur für zweidimensionale Daten und Labels, wird häufig in datenintensiven Bereichen wie Data Science, Machine Learning und wissenschaftlichem Rechnen verwendet und ähnelt einer SQL-Tabelle oder einer Excel/Calc-Tabelle.

    • Das ist eine der nervigen Schwächen vieler technischer Produkte. Es ist natürlich, dass man die Zielgruppe ansprechen will, hier also Data Scientists, die Pandas mögen, es aber als langsam und unflexibel empfinden; für Einsteiger wirkt das jedoch ausgrenzend.
      Ich gehöre zur Zielgruppe von Polars und wollte es seit Monaten ausprobieren, schiebe es aber immer wieder auf. Ich habe noch eine gewisse Loyalität zu Pandas, weil Wes McKinney, der Schöpfer von Pandas, ein nützliches Buch geschrieben hat, das gängige Analysewerkzeuge erklärt: https://wesmckinney.com/book/.
    • Es ist Pandas, nur schnell. Pandas ist die ursprüngliche Open-Source-DataFrame-Bibliothek; sie ist robust und weit verbreitet, aber offenbar breit angelegt und langsamer als dieser Newcomer. Das Wort „DataFrame“ ist für Leute, die so etwas schon benutzt haben, sofort ein Signal.
    • Jedes Mal, wenn ich so eine Seite sehe, fühle ich mich demütig. „DataFrame der neuen Ära“ – da frage ich mich, ob ich überhaupt weiß, was ein DataFrame ist; und bei „Multithreaded Query Engine“ frage ich mich, ob das so etwas wie eine Datenbank ist.
      Dann kommt ein Diagramm, das mit Dingen namens pandas, modin und vaex vergleicht, aber die kenne ich auch überhaupt nicht, also komme ich zu dem Schluss: Das ist wohl nichts für mich. Ich lese gern über neue Technologien oder Projekte und lerne dabei, aber hier gibt es nichts, woran ich mich festhalten kann.
      Vermutlich ist das genau das, was normale Menschen erleben, wenn ich über irgendwelche belanglosen Webentwicklungsdinge rede.
    • Fairerweise lautet der Seitentitel „Dataframes for the new Era“, und der Link Get Started unter dem Titel verweist auf die Dokumentation auf der GitHub-Seite. GitHub erklärt Leuten mit Hintergrund in Datenanalyse, was diese Bibliothek ist: https://github.com/pola-rs/polars
    • Ich werde gerade in den Bereich „Daten“ hineingezogen, und es wirkt wie ein Paralleluniversum mit eigenem Hintergrund und eigener Kultur. Es gibt viele Formulierungen im Stil von „mit der Bedienbarkeit von Nincompoop und der Performance von ARSE2 eine Verbindung zu einer Antelope- oder Meringue-Instanz herstellen“.
      Interessant an Polars ist, dass es Pandas ähnelt, aber mit Arrow ein effizienteres Rust-Backend nutzt und Dinge wie einen Query Planner hat, der Kombinationen von Operationen effizienter macht. Üblicherweise ist Polars deutlich effizienter als Pandas, sodass Aufgaben, für die früher komplexe Infrastruktur nötig war, häufig auf einer einzelnen Maschine laufen können.
      Es ist eine sehr freundschaftliche Konkurrenz, geschaffen von einem Kernentwickler von Pandas, und dem Anschein nach finden alle das gut; mit der Zeit könnte es Pandas wahrscheinlich ersetzen.

  • Verwandte Beiträge:
    Detailed Comparison Between Polars, DuckDB, Pandas, Modin, Ponder, Fugue, Daft - https://news.ycombinator.com/item?id=37087279 - August 2023
    Polars: Company Formation Announcement - https://news.ycombinator.com/item?id=36984611 - August 2023
    Replacing Pandas with Polars - https://news.ycombinator.com/item?id=34452526 - Januar 2023
    Fast DataFrames for Ruby - https://news.ycombinator.com/item?id=34423221 - Januar 2023
    Modern Polars: A comparison of the Polars and Pandas dataframe libraries - https://news.ycombinator.com/item?id=34275818 - Januar 2023
    Rust polars 0.26 is released - https://news.ycombinator.com/item?id=34092566 - Dezember 2022
    Polars: Fast DataFrame library for Rust and Python - https://news.ycombinator.com/item?id=29584698 - Dezember 2021
    Polars: Rust DataFrames Based on Apache Arrow - https://news.ycombinator.com/item?id=23768227 - Juli 2020

  • Ich habe Pandas jahrelang benutzt, aber es fühlte sich immer an, als würde man eine Kugel einen Hügel hinaufrollen. Schon bei einfachen Aufgaben wie Joins, und man darf auch nicht vergessen, den Index zurückzusetzen.
    Polars fühlt sich in fast jeder Hinsicht besser an als Pandas. Es ist schneller, nutzt mehrere Kerne, verbraucht weniger Speicher und die API ist intuitiver. Als noch relativ junge Library hat es zwar Nachteile, aber bei neuen Projekten ist es zumindest eine Prüfung wert.
    Auch dass man das Rust-Ökosystem leicht nutzen kann, ist großartig. Ich habe selbst ein Plugin geschrieben, um eine Funktion zu parallelisieren, und damit manchen Geospatial-Code um den Faktor 100 beschleunigt.

    • Dass du gerade Joins als Beispiel nennst, ist ein bisschen ironisch. Ich fand immer, das größte Problem von Pandas sei die Dokumentation. Wusstest du zum Beispiel, dass es eine Möglichkeit gibt, Dataframes ohne Index zu joinen? Sie heißt nicht „join“, sondern merge.
      Pandas war anfangs stark von der Terminologie und den Nutzungsmustern aus R geprägt, und in R war „merge“ für „join“ bereits geläufig. Wenn man um 2015, als man anfing, Pandas zu lernen, R nicht schon kannte, war es vermutlich schwer, schnell hineinzukommen.
    • Mich würde interessieren, wie du PRQL (prql-lang.org) einschätzt. Persönlich sehe ich darin eine Kombination aus dem Bediengefühl und der Developer Experience von Polars oder Pandas mit der Stärke und Universalität von SQL.
      Abfragen lassen sich nicht nur mit Polars und Pandas ausführen, sondern auch auf einer beliebigen SQL-kompatiblen Execution Engine wie DuckDB, ClickHouse, BigQuery, Redshift, Postgres, Trino/Presto, SQLite usw.
      Join-Syntax und -Semantik gehören zu den kniffligsten Teilen, daher diskutieren wir sie gerade wieder. Sie sind ein Kern der relationalen Algebra und entsprechen auch dem R in PRQL. Die meisten grundlegenden PRQL-Transformationen sind einfache Listenoperationen wie map, filter und reduce, aber bei Joins muss man vorsichtig sein, wenn man monadische Komposition erhalten will. Meine Gedanken dazu habe ich hier hinterlassen: https://github.com/PRQL/prql/issues/3782#issuecomment-1811312787
      Das Issue ist zwar geschlossen, aber es wäre schön, wenn du ein neues Issue eröffnest oder mich mit @snth taggst und deine Meinung teilst. Zur Einordnung: Ich bin PRQL-Contributor.
    • Mich würde interessieren, was am Zusammenführen von Pandas-Dataframes schwierig ist.

  • Als ich es evaluiert habe, war der größte Vorteil, dass die API viel konsistenter und verständlicher war als die von Pandas. In gewisser Weise ist das naheliegend, weil sie aus 20 großen Pandas-Versionen gelernt haben dürfte.
    Da es aber deutlich weniger genutzt wird, konnte Copilot Polars-Code nicht gut schreiben. Deshalb nutze ich vorerst weiter Pandas und Copilot. Diesmal habe ich zum ersten Mal gemerkt, dass es bei neuen Libraries generell diese Hürde gibt.

    • Ich glaube, ich sehe zum ersten Mal jemanden öffentlich sagen, dass er eine Library wegen der Copilot-Unterstützung bevorzugt. Nicht wertend gemeint, nur interessant.
      Trotzdem lernt Copilot innerhalb eines Repositorys sehr schnell. Ich nutze einen extrem stark angepassten Stack, der auf TS-Plus basiert, einem TypeScript-Fork, den nicht einmal der Autor selbst nutzt oder empfiehlt, und Copilot erzeugt ziemlich guten TS-Plus-Code.
      Nachdem es ein paar Beispiele gesehen hat, sollte man nicht unterschätzen, dass Copilot bei Boilerplate ziemlich gut werden kann.
    • Copilot-Unterstützung ist ein Henne-Ei-Problem. Es muss aus dem Code anderer Leute lernen, aber wenn die Leute ohne Copilot keinen Polars-Code schreiben, wird Copilot auch nicht besser darin, Polars-Code zu schreiben.
    • Ähnlich war es bei danfo.js, einer weiteren Dataframe-Library für JS. Copilot hat Funktionen und Methodennamen einfach halluziniert.
      Das war kein großes Problem, weil man ja die Doku lesen kann, aber es war lästig, dass Copilot nicht einfach sofort das ausspucken konnte, was ich brauchte.
    • Du erkennst an, dass die API konsistenter und verständlicher ist, willst aber allein deshalb bei Pandas bleiben, weil Copilot es dir leichter macht? Es wäre besser, das Tool zu nutzen, das du selbst als besser anerkennst – für dich und für Open-Source-Innovation.
      Ich habe die Pandas-API lange benutzt und gehasst. Ich bin ziemlich aktiv darin, mein Lernen, meine Tools, Denkweisen und Technologien kontinuierlich zu verbessern.
    • Die Polars-Library ändert sich schnell. Ich nutze Copilot nicht, aber wenn man in die Systemanweisungen aktuelle Informationen einfügt, etwa dass with_column zu with_columns geworden ist, und Inhalte aus der Dokumentation ergänzt, bekommt man mit ChatGPT ziemlich gute Ergebnisse.

  • Als Deno Jupyter-Unterstützung veröffentlicht hat, war nodejs-polars eine der unterstützten Kern-Libraries für Data Science.
    https://blog.jupyter.org/bringing-modern-javascript-to-the-jupyter-notebook-fc998095081e
    Persönlich komme ich nicht aus dem Data-Science-Bereich, aber wenn man bedenkt, dass das JS/Jupyter-Ökosystem noch am Anfang steht, war es überraschend schnell, Analysen auf Basis von pola.rs in TypeScript zum Laufen zu bringen.
    Die JS-Bindings haben sicher noch Stellen, an denen gearbeitet werden muss, aber ich hoffe, dass die bessere Zugänglichkeit zu iterativen Verbesserungen führt.

    • Ich wollte schon immer etwas Pandas-Ähnliches in JS haben; das ist neu für mich.

  • Ich bin wirklich gespannt auf Polars und die Performance ist beeindruckend, aber es stört mich, vaex, modin und dask alle im selben Benchmark zu vergleichen.
    Diese Libraries zielen alle auf Out-of-Core-Datenverarbeitung ab, also auf Fälle, in denen die Daten zu groß sind und Berechnungen über mehrere Maschinen verteilt werden. Sie mit einer Single-Machine-Dataframe-Library zu vergleichen, ist seltsam; zwangsläufig haben sie mehr Overhead und müssen langsamer sein.
    Man wird Polars selten im selben Kontext wie solche Libraries einsetzen, daher ist es etwas absurd, sie in einem Benchmark als gleichwertig darzustellen. Außerdem fehlt DuckDB im Benchmark, das man in ähnlichen Kontexten wie Polars einsetzen kann und das in vielen Fällen schneller ist.
    Das Software Engineering von Polars ist hervorragende Arbeit und braucht solche potenziell irreführenden Benchmarks nicht.

    • Zu den anderen kann ich nichts sagen, aber Dask lässt sich auch auf einer einzelnen Maschine nutzen, und das ist wahrscheinlich sogar der einfachste Einstieg in Dask. Es teilt den Dataframe in Partitionen auf und verarbeitet sie auf den einzelnen Kernen, um Operationen zu parallelisieren.
      Ohne Konfiguration sind gegenüber Pandas 2× Performance-Gewinn möglich, und bei bestimmten Operationen habe ich bis zu 5× gesehen.
    • Ibis, ein Python-Dataframe-Projekt vom Schöpfer von Pandas, nutzt DuckDB als Standard-Backend und schlägt Polars in solchen Benchmarks normalerweise, abgesehen von einigen Query-Ausnahmen.

  • Ich nutze Polars nicht direkt, sondern als Materialisierungsformat in DuckDB-Workflows.
    duckdb.query(sql).pl() ist deutlich schneller als duckdb.query(sql).df(). Mit Polars ist es Zero-Copy und damit sofort fertig, während Pandas bei großen DataFrames ziemlich lange dauern kann. Und abgesehen von leicht anderer Syntax lässt es sich wie ein Pandas DataFrame bearbeiten.
    Sehr gut für den Umgang mit großen Datensätzen.

  • Es dürfte ein Korollar zu Greenspun's Tenth Rule (https://en.wikipedia.org/wiki/Greenspun's_tenth_rule)) geben. Sinngemäß: Jede hinreichend komplexe Datenanalyse-Bibliothek implementiert am Ende die Hälfte von SQL auf ad-hoc-artige, informell spezifizierte, fehleranfällige und langsame Weise.
    Ich nutze Pandas gelegentlich und werde vermutlich auch das hier ausprobieren, aber ich denke ständig, dass ich die Daten, an denen ich arbeite, einfach von Anfang an in Postgres hätte stecken sollen.
    Obwohl ich kein Datenbankexperte bin und Python für mich viel bequemer ist, ist SQL beim Auswählen, Sortieren, Filtern und Joinen tabellarischer Daten deutlich besser.

    • Ich empfehle, sich DuckDB und die Erweiterung duckdb-prql anzusehen.
      DuckDB erlaubt es, Daten in Polars-, Pandas- und Arrow-Formaten direkt per SQL zu bearbeiten, ohne Daten zu kopieren oder zu duplizieren.
      duckdb-prql ermöglicht die Nutzung von PRQL (prql-lang.org), und persönlich finde ich, dass es die Stärke und Universalität von SQL mit dem Bediengefühl und der Developer Experience von Polars oder Pandas verbindet. Zur Einordnung: Ich bin PRQL-Contributor.
    • Das kann man so machen, aber bei „analytischen“ Queries wird die Performance wahrscheinlich deutlich schlechter, und Flexibilität sowie Ausdrucksstärke nehmen ebenfalls ab.
      Stattdessen lohnt sich ein Blick auf DuckDB. Dessen SQL-Implementierung ist weder ein Provisorium noch voller Bugs, langsam oder unvollständig. Wie formal die Spezifikation ist, weiß ich nicht genau, aber es ist mit Polars kompatibel.
    • Persönlich halte ich Lazy-DataFrame-Syntax für ein deutlich besseres Frontend für Query-Engines. Polars unterstützt zwar auch SQL, aber Bugs kommen normalerweise nicht aus dem Frontend, sondern aus der Query-Engine.
      Bei der Art von Queries, die man mit solchen Engines ausführt, dürfte Postgres um einen einstelligen Faktor langsamer sein als eine OLAP-Query-Engine.
    • Der Gründer von Pandas hat aus genau solchen Gründen Ibis mit Postgres-Backend entwickelt: https://ibis-project.org/backends/postgresql
      Das ist ein besserer Ansatz, um Python-DataFrames und SQL zusammen zu verwenden.

  • Vor ein paar Monaten habe ich versucht, eine große Pandas-Codebasis auf Polars zu migrieren. Ich mag Analyse und Daten-Pipelining in Python ohnehin nicht besonders; komplexe Transformationen dauern in Pandas 2- bis 5-mal länger als in Julia oder R (mit dataframes.jl bzw. dplyr).
    Leider war Polars auch nicht die Lösung. Es hatte zu viele Bugs bei Standardoperationen, und die Interoperabilität mit Pandas war instabil. Das ist ein Problem, weil viele Bibliotheken Pandas DataFrames als Eingabe verlangen. Die API ist für eine moderne DataFrame-Bibliothek ebenfalls sehr ausführlich, aber immer noch besser als Pandas.
    Ich hoffe, dass sich das mit der Zeit löst, aber im Moment war DuckDB auf Pandas die beste Lösung. Es ist so schnell wie Polars, dabei stabiler und interoperabler.
    Ich hoffe, dass das Python-DataFrame-Ökosystem irgendwann einen Punkt erreicht, an dem man wie in R eine analyseorientierte DataFrame-Bibliothek mit intuitiver API (dplyr) und eine High-Performance-DataFrame-Bibliothek (data.table) problemlos gemeinsam nutzen kann.

    • Mich hat die Ausführlichkeit auch genervt. Pandas ist im Vergleich zu etwas wie data.table ebenfalls ziemlich wortreich, aber Polars fühlt sich eher so an, als würde man eine API benutzen, statt wie ein „Werkzeug zur Datenmanipulation“.
      Für explorative Datenanalyse oder Forschung werde ich es vermutlich nicht verwenden, aber wegen der besseren Performance habe ich angefangen, es in einigen Produktionsskripten einzusetzen.
      Die Kombination aus dplyr + data.table in R ist für mich immer noch die beste Erfahrung bei der Datenmanipulation. Ich wünschte nur, R hätte etwas wie Matplotlib. ggplot ist zu High-Level, und die Basisgrafik ist zu Low-Level. Scikit-Learn ist außerdem viel modularer als Caret, daher vermisse ich Caret nicht.
    • Mich würde interessieren, wie du PRQL (prql-lang.org) siehst. Ziel ist es, überall dort, wo SQL verwendet wird, das Bediengefühl von dplyr zu bieten; PRQL wird nach SQL kompiliert.
      Persönlich finde ich, dass es die Developer Experience von dplyr, Polars und Pandas mit der Stärke und Universalität von SQL verbindet. Queries können nicht nur mit Polars und Pandas laufen, sondern auf jeder gewünschten SQL-kompatiblen Execution Engine wie DuckDB, ClickHouse, BigQuery, Redshift, Postgres, Trino/Presto, SQLite usw.
      Ich würde deine Gedanken gern in den GitHub-Diskussionen (https://github.com/PRQL/prql/discussions) oder auf Discord (https://discord.com/invite/XWxbCrWr) hören. Zur Einordnung: Ich bin PRQL-Contributor.
    • Schön, dass du Erfahrung mit DataFrames in R, Python und Julia hast. Mich würde interessieren, welche davon dir am besten gefällt. Das Ökosystem lässt sich wahrscheinlich nicht direkt vergleichen, aber gemessen an Aufgaben wie Kernoperationen: Welche war am besten?
    • Ibis mit DuckDB-Backend ist ebenfalls einen Versuch wert. Persönlich mag ich Polars auch ziemlich. Die Entwickler reagieren insgesamt recht schnell auf Issues.

  • Unser Data-Science-Team hat Polars evaluiert, und die Ergebnisse waren gemischt. Wenn es Bereiche gibt, in denen Performance wichtig ist, würden wir eine Einführung in Betracht ziehen, ansonsten waren wir wegen der Kosten für den Ersatz von Pandas in Dutzenden Projekten eher skeptisch

    • Ich halte diese Einschätzung für richtig. Im Moment ist es meiner Meinung nach eher Zeit zum Experimentieren, nicht dazu, ein bereits gut funktionierendes Pandas zu ersetzen
      Die API hat noch vorhersehbare Breaking Changes, und über mehrere Projekte hinweg kann das zu Wartungsaufwand werden. Trotzdem wirkt die API schon konsistenter, und insgesamt scheint es in die richtige Richtung zu gehen
    • Man sollte nicht den gesamten Code neu schreiben. Bei neuem Code lohnt sich eine Einführung oder zumindest eine Evaluierung aber durchaus
      Besonders die Interoperabilitätskosten mit Pandas sind sehr niedrig, und mit dem Arrow-Backend ist auch ein Zero-Copy-Wechsel zu Pandas ziemlich einfach möglich
    • Für die Zukunft gibt es https://github.com/fugue-project/fugue
    • Mich würde interessieren, ob das Team pandasql verwendet oder hauptsächlich direkt die Pandas-API nutzt