Die Version 2.0 von Polars ist erschienen und argumentiert stillschweigend dafür, dass SQL in die Sprache integriert sein sollte, anstatt als nachträglich hinzugefügte Funktion behandelt zu werden. Das Update beinhaltet Unterstützung für das Auslagern von Daten auf die Festplatte (out-of-core spill-to-disk), eine Streaming-Engine und einen neuen Map-Datentyp. Es bringt außerdem neue Benchmark-Ergebnisse, die zeigen, dass Polars bei gängigen SQL-Tests besser abschneidet als DuckDB und DataFusion.
Ein Versionssprung sollte laut dem Ankündigungsbeitrag keine große Funktionsveröffentlichung signalisieren. Er ist es aber dennoch geworden. Diese Veröffentlichung liefert reichlich Gründe zur Begeisterung.
Was 2.0 tatsächlich bringt
Die Highlights der Veröffentlichung lassen sich in fünf Teile gliedern:
- Erste Unterstützung für das Auslagern von Daten auf die Festplatte (out-of-core spill-to-disk), jetzt standardmäßig aktiviert
- Verbesserungen der Kernleistung über den gesamten Bereich
- Volle SQL-Unterstützung als First-Class-Citizen
- Ein neuer Map-Datentyp
- Strengere Behandlung von Datentypen und Explicitness, was zu schnellerem Feedback und schnellerer KI-Iteration führt
Polars has added two major features: out-of-core support and a streaming engine. Out-of-core support means the library spills data to disk when memory is exhausted, instead of failing or grinding to a halt. The streaming engine alters how queries are gathered, so that a call to collect on a LazyFrame now defaults to using it. That change brings substantial gains in memory use and speed across most queries.
SQL als First-Class-Citizen
In den letzten Jahren hat Polars eine starke Engine aufgebaut. Nun ist es das Ziel des Teams mit 2.0, dass diese Engine mehr Arten von Aufgaben bewältigen kann, einschließlich SQL. Das schnelle Ausführen erforderte die Einführung zahlreicher Verbesserungen des Optimierers und der Engine.
Polars hat die inneren Abläufe von SQL zu einem festen Bestandteil seines Standardsatzes gemacht, anstatt sie als separates Funktionsset zu behandeln. Die wichtigsten Verbesserungen umfassen Join-Reihenfolgeoptimierung, verbesserte Common-Subplan-Eliminierung sowie dynamische Prädikate und Bloom-Filter. Dies sind die Werkzeuge, die SQL schnell laufen lassen.
Die Benchmark-Zahlen (
Das Team testete Polars, indem es Benchmarks mit Daten aus TPC-H und TPC-DS1 durchführte und seine Leistung mit mehreren anderen Projekten verglich. Diese Vergleiche umfassten die aktuelle DuckDB-Version (1.5.6), eine Vorabversion von DuckDB (2.0 alpha, 2.0.0.dev2610011535) und die neueste Version von DataFusion (54.0.0).
| Maschine ( | vCPUs ( | RAM ( |
|---|---|---|
| c7a.4xlarge ( | 16 | 32GB ( |
| c7a.metal ( | 192 | 384GB ( |
Jede Abfrage wurde in fünf Iterationen in einem warmen Zustand ausgeführt, wobei jeder Abfrage ein eigenes Prozess zugeordnet war und ein 60-Sekunden-Limit gesetzt wurde. Der Dateicache wurde nach jedem Engine/Benchmark-Paar geleert, jedoch nicht zwischen einzelnen Abfragen.
Das Team wählte die beste Ausführung von jedem der fünf Versuche für den Vergleich aus und misst die Engines anhand sowohl der Gesamt- als auch der geometrischen Durchschnittszeit dieser Abfragen. Die Daten stammen von tpcgen-cli, das aus dem Quellcode bei Commit 99bedae erstellt wurde, wobei die SQL-Abfragen mit DuckDB 1.5.6’s tpch_queries() und tpcds_queries() erzeugt wurden. Der Speicher befand sich auf EBS.
Auf c7a.4xlarge erlebte DataFusion ein Timeout bei der Verarbeitung von TPC-DS q72 und einmal bei q67, und es erschöpfte seinen Speicher bei TPC-H q18. Diese drei Abfragen werden von den oben genannten Engines aus den Ergebnissen ausgeschlossen.
Was die Diagramme zeigen )
Die Ergebnisse stechen heraus. Standardmäßig ist Polars in jedem Benchmark außer einem am schnellsten. Wird es auf 192 Threads skaliert, verursacht Polars einen konstanten Overhead, der kleine Datenabfragen beeinträchtigt. Tatsächlich macht die Beschränkung von Polars auf nur 32 Kerne es in allen Benchmarks wettbewerbsfähig oder siegreich.
Das Problem wurde vom Team auf ihrer Seite identifiziert, und sie planen, es in der kommenden Veröffentlichung zu beheben. Weitere Details zu den Tests finden sich im Anhang, wo das Team andere einlädt, die Ergebnisse zu bestätigen. Eine separate Sammlung mit dem Testmaterial befindet sich unter https://github.com/pola-rs/polars-2.0-benchmark.
Streaming Engine und OOC als Standard )
The shift in default behavior for collect on a LazyFrame is one of the largest changes in 2.0. Rather than running on the legacy engine, it now defaults to the streaming engine. This switch brings about significant gains in both memory efficiency and query performance across most use cases.
For some operations, such as join, group_by, and unpivot, the streaming engine doesn’t ensure row-order by default. Should you need to observe row-order in these operations, you can enable it by setting maintain_order=True.
Das Auslagern auf die Festplatte ist jetzt standardmäßig aktiviert. Eine Abfrage beginnt, Daten in den Speicher zu verschieben, wenn sie etwa 80 % des verfügbaren Speichers verbraucht hat, ein Schwellenwert, der möglicherweise angepasst werden muss. Mehrere Operationen erlauben dieses Verhalten derzeit: Sortieren, Fensterfunktionen und viele Ausdrücke, die nun alle beginnen können, Zwischenergebnisse auf die Festplatte zu schreiben, um ihre Arbeit abzuschließen.
Der anfängliche Grenzwert für den Festplattenplatz beträgt 64 GB. Das Team plant, Out-of-Core-Support für Joins und Group-By-Operationen bald einzuschalten. Sobald diese Änderungen umgesetzt sind, kann Polars hochspeicherintensive Arbeitslasten für Gelegenheitsnutzer deutlich besser verarbeiten.
Der Neue Map-Datentyp )
Polars unterstützt nun den Arrow MapType direkt als Polars Map-Datentyp. Man kann sich eine Map wie ein Python-Dictionary vorstellen, das Schlüssel auf Werte abbildet. Vor 2.0 wurde der Arrow MapType in Polars als List(Struct({„key“: …, „value“: …})) gelesen.
Hier ist, wie der neue Datentyp in der Praxis aussieht: )
python
df = pl.DataFrame({
"user": ["alice", "bob", "carol"],
"scores": pl.Series([
{"math": 90, "art": 75}, {"math": 60}, {}
], dtype=pl.Map(pl.String, pl.Int64)),
"subject": ["art", "art", "math"],
})
Diese Anordnung hat eine Form von (3), 3, und die Darstellung ihres Inhalts ist leicht zu erkennen. Sie ermöglicht Suchvorgänge nach Label und Dictionary-artige Operationen auf der Spalte.
python
df.select(
"user",
pl.col("scores").map.get("math").alias("math"), # fixed key
pl.col("scores").map.get(pl.col("subject")).alias("by_subject"), # key from another column
pl.col("scores").map.contains_key("art").alias("has_art"),
pl.col("scores").map.len().alias("n"),
pl.col("scores").map.keys().alias("keys"),
pl.col("scores").map.values().alias("values"),
)
Das Ergebnis enthält sechs Spalten: math, by_subject, has_art, n, keys und values. Keys erzeugt eine Liste von Strings, während values eine Liste von Integer-Zahlen generiert.
Warum das wichtig ist )
Die Version 2.0 von Polars stellt eine bemerkenswerte Verbesserung für ein Projekt dar, das sich still und leise im Laufe der Zeit entwickelt hat. Die Benchmark-Ergebnisse belegen das am deutlichsten, doch die Ankündigung weist auch auf eine Änderung hin, wie Polars SQL behandelt.
Der Streaming-Engine und die Unterstützung für Daten außerhalb des Hauptspeichers verbessern Polars‘ Leistung unter hoher Speicherauslastung. Die Hinzufügung des Map-Datentyps schließt eine Lücke in dem, was die Bibliothek leisten kann. Eine strenge Typüberprüfung beschleunigt außerdem die Entwicklung, wobei das Team schnellere Rückmeldungen und schnellere KI-Iterationen als Vorteile nennt.
Dies ist kein gewagter Marketing-Gag. Es ist eine technische Verbesserung, die denjenigen dient, die sich täglich auf das Werkzeug verlassen.
Die nächste Version
Das Skalierungsproblem wurde diagnostiziert, und das Team hofft, es in der nächsten Version zu beheben. Das ist ein Versprechen, das es wert ist, im Auge zu behalten. In der Zwischenzeit ist die Roadmap für Joins und Group-by außerhalb des Hauptspeichers bemerkenswert, denn sobald diese Funktionen aktiviert sind, wird das Argument für Resilienz noch überzeugender sein.
Polars hat in den letzten Jahren einen soliden Engine aufgebaut. In 2.0 behandelt es SQL endlich als First-Class-Citizen. Die Benchmarks demonstrieren die Verbesserungen.
Dieses Update ist ein sachlicher Bericht über die Technologie selbst, kein Marketing-Kampagne. Es beschreibt ein Werkzeug, das verbessert wurde, wobei Tests die Behauptung belegen. Bei fast jedem Test liegt Polars als schnellste Standardwahl vorne.
Quellenmaterial: „Release of Polars 2.0“, pola.rs.
Das Notizbuch abonnieren.
Die besten Geschichten des Tages und jedes neue Urteil, in klarem Deutsch, um sieben im Postfach. Eine Mail am Tag, nicht mehr.