Polars 2.0 Release Candidate: Streaming Engine wird Standard und beschleunigt Queries um das Fünffache
Pre-Release of Polars 2.0
Polars hat den ersten Release Candidate für Version 2.0 veröffentlicht. Das Update fokussiert nicht auf neue Features, sondern auf grundlegende Verbesserungen: Der Streaming-Engine wird zum Standard für alle LazyFrame-Queries, was zu erheblichen Speicher- und Performance-Gewinnen führt – im Schnitt wird eine 5-fache Beschleunigung erwartet. Zudem wird Polars strenger: Fehlerhafte Datentyp-Konvertierungen und stilles Auffüllen mit null werden nun durch klare Fehler ersetzt. Ein umfassender Migrationsleitfaden hilft bei der Umstellung.
Wir hoffen, dass dieses Release eher langweilig ist.
- benrutter
> Wir streben keinen großen Feature-Release von Polars 2.0 an. Tatsächlich hoffen wir, dass es eine langweilige Erfahrung für euch wird. Der Grund, warum wir diese Major-Version erhöhen, ist, dass wir Designentscheidungen aus der Vergangenheit loswerden können, die uns derzeit blockieren, und dann wollen wir die Standardeinstellungen auf sinnvollere Optionen ändern, die einem größeren Publikum zugutekommen.
Ich weiß, diese Ansicht entlarvt mich als sehr langweilige Person, aber ich liebe es, wenn Projekte SemVer so ernst nehmen! Versionssprünge sollten wirklich darum gehen, veralteten Ballast zu entfernen, statt um glänzende neue Features.
Ich nutze Polars schon eine Weile und ihr Fokus auf Stabilität war ein großer Teil davon, mich anfangs zum Wechsel zu überzeugen!
- perrygeo
Für mich ist die Superkraft von Polars die Produktionsstabilität.
Pandas tendiert dazu, alle Probleme zur Laufzeit zu verschieben, mit allerlei versteckten Heuristiken. Besonders bei Spaltentypen und fehlenden Werten. Es ist sehr schwer zu wissen, ob man alle Randfälle getestet hat. Der einzige Weg, seinen Code zu testen, ist, alle Variationen der Daten darauf zu werfen. Gut, wenn man vor einem Notebook sitzt und die Geduld hat, Daten in dessen Namen zu validieren und zu "bereinigen". Nicht so gut, wenn man um 3 Uhr morgens angerufen wird, weil die Datenpipeline fehlgeschlagen ist, als sie eine Int-Spalte erwartete, aber Float bekam.
Polars ist standardmäßig strenger und verlagert Kosten durch seinen Planer nach vorne. Die resultierenden Anwendungen sind in der Produktion spürbar stabiler. Man kann Code testen und mit angemessener Sicherheit davon ausgehen, dass er mit Daten in freier Wildbahn funktioniert.
Ich habe eigentlich kein Interesse an der API-Ergonomie oder der Syntax – beide sind in Ordnung. Es geht nur darum, wie sie mit Datenvariationen zur Laufzeit umgehen. Kann man allgemeinen Code schreiben, der nicht bei Varianten bricht? Pandas: keine Chance. Polars: absolut!
Bonusrunde: Polars hat auch eine Rust-API; der Compiler kann effektiv beweisen, dass dein Programm jeden Randfall behandelt. Es ist üblich, Rust-Polars-Anwendungen zu schreiben, die jahrelang unbeaufsichtigt laufen.
- trombonechamp
Gibt es außer der Leistung einen Grund, warum maintain_order=False standardmäßig ist? Ich frage, weil Polars in vielen wissenschaftlichen Datenanalyse-Pipelines verwendet wird und nicht-deterministisches Verhalten eine gut dokumentierte Quelle von Bugs im wissenschaftlichen Rechnen ist (z. B. https://pmc.ncbi.nlm.nih.gov/articles/PMC6919963/). Die neue Standardeinstellung erfordert, dass Benutzer die Implementierungsdetails der API im Kopf behalten, während sie bestimmen, ob Code korrekt ist oder nicht. Das ist beim wissenschaftlichen Rechnen knifflig, weil die korrekte Antwort nicht im Voraus bekannt ist, sodass Bugs durchrutschen und stillschweigend falsche Ergebnisse liefern können.
- bbstats
Es nervt mich ungemein, dass "Verwenden Sie stattdessen: .cat.to(dtype) für int → categorical, .cat.physical() für categorical → int." kein erforderliches Codebeispiel liefert!
- lmeyerov
Die Bewegung hin zu Streaming und generell Out-of-Core ist großartig.
Wir haben kürzlich ein Polars-Backend zu GFQL hinzugefügt (Cypher-Graph-Abfragen auf Dataframes, keine DB nötig), sowohl im CPU- als auch im GPU-Modus, und es ist super beeindruckend. Deutliche Verbesserungen gegenüber pandas/cudf, und es ermöglichte GFQL, beliebte Systeme in mehr Kategorien zu schlagen, wie z. B. bei geringer Latenz, nicht nur bei großen Datensätzen: https://www.graphistry.com/blog/cypher-on-polars-cpu-gpu-gra...
- bobson_dugnutt5
Ich liebe Polars. Ich habe bei der Arbeit viel Evangelisierung betrieben, um Leute dazu zu bringen, Pandas zugunsten von Polars aufzugeben.
- Kydlaw
Ich freue mich über Aktivitäten rund um Polars. Dies war meine bevorzugte Bibliothek für die Datenverarbeitung aufgrund der verbesserten Ergonomie im Vergleich zu Pandas und SQL.
Aber sie waren in letzter Zeit etwas ruhig, und ich habe mich in letzter Zeit immer mehr mit DuckDB beschäftigt … bis zur jüngsten Übernahme von DuckLab durch AWS.
- arn3n
Die Entscheidung, standardmäßig die Streaming-Engine zu verwenden, ist wirklich interessant. Meine Intuition ist, dass dies langsamer wäre als andere Dataframe-Operationen, die mit Batch-Verarbeitung besser parallelisierbar sind, weil Streaming-Engines notwendigerweise Zeilen sequenziell verarbeiten. Liege ich mit meiner Intuition falsch/überschätze ich, wie viel Auto-Parallelisierung Polars durchführt?