Das Release mit null neuen Funktionen
Polars 2.0 enthält keine neuen Funktionen und positioniert dieses Release als eine entscheidende Bereinigung und architektonische Überarbeitung. Entwickler beschreiben es nicht als Funktions-Update, sondern als grundlegende Anstrengung zur Verbesserung der internen Konsistenz und Robustheit. Dieses Update zielt auf langfristige Stabilität ab und verändert grundlegend die Funktionsweise bestehenden Codes, trotz des Fehlens neuer, für den Benutzer sichtbarer Funktionalitäten.
Die wirkungsvollste Änderung führt eine neue Standard-Streaming-Engine für alle LazyFrame-Abfragen ein. Diese Engine verarbeitet Daten in kleineren, parallelen Blöcken, sogenannten Morsels, was zu massiven Leistungs- und Speichereffizienzgewinnen führt. Erste Einschätzungen prognostizieren, dass die Ausführung aggregierter Abfragen unter diesem neuen Paradigma "leicht 5x schneller" sein wird, wodurch der Speicherbedarf erheblich reduziert wird, da nicht mehr ganze Datensätze gleichzeitig in den RAM geladen werden müssen.
Dieses grundlegende Update ist für die ambitionierte Zukunft von Polars unerlässlich. Die neue Streaming-Engine schafft die kritische Basis für die Erzielung einer echten Out-of-Core-Verarbeitung, wodurch die Bibliothek Datensätze, die größer als der verfügbare Systemspeicher sind, effizient verarbeiten kann. Sie ebnet zudem den Weg für einen leistungsfähigeren und ausgefeilteren Abfrageoptimierer, was die analytischen Fähigkeiten und die Skalierbarkeit von Polars weiter verbessert.
Ihr Code ist beschädigt: API-Änderungen erklärt
Polars 2.0 führt explizite API-Änderungen ein, die bestehenden Code direkt beschädigen. Dieses Update ist kein Funktions-Release; stattdessen priorisiert es die langfristige architektonische Konsistenz gegenüber der Abwärtskompatibilität für bestimmte Funktionen. Entwickler werden auf unmittelbare Fehler stoßen, da frühere Methoden nicht mehr unter ihrem Namen funktionieren.
Mehrere Kernfunktionen wurden umbenannt oder entfernt. Die melt-Methode heißt jetzt unpivot, ein Name, der für die Umformung von Daten von breit nach lang als intuitiver angesehen wird. join_nulls wurde zur besseren Klarheit bei Join-Operationen in nulls_equal umbenannt. Zusätzlich ist LazyFrame.profile nicht mehr verfügbar.
Die Änderungen spiegeln eine Verschiebung hin zu optimierter Lazy-Execution und strengerer Datenverarbeitung wider. Zum Beispiel nutzt read_csv nun intern scan_csv().collect(), was eine automatische Lazy-Optimierung bietet. Die Kombination von vorzeichenbehafteten und vorzeichenlosen 64-Bit-Integers ergibt nun einen Int128-Typ, wodurch ein stiller Präzisionsverlust verhindert wird, der zuvor durch die Umwandlung in einen Float verursacht wurde.
Die Migration wird durch eine verbesserte Fehlerbehandlung gestrafft. Entfernte Funktionen werfen nun einen AttributeRemovedError, der explizit die Ersatzmethode angibt. Dieser entwicklerfreundliche Ansatz stellt sicher, dass ein Aufruf von melt direkt die Verwendung von unpivot vorschlägt, was gezielte Korrekturen ermöglicht und Ausfallzeiten minimiert.
Die stille Falle: Die Zeilenreihenfolge ist nicht garantiert
Polars 2.0 führt eine Standard-Streaming-Engine für alle LazyFrame-Abfragen ein, die die Zeilenreihenfolge für Operationen wie join, group_by und unpivot nicht garantiert. Diese grundlegende architektonische Änderung, die auf signifikante Leistungs- und Speichereffizienzgewinne ausgelegt ist, verarbeitet Daten in kleineren, parallelen Blöcken. Dies kann die Reihenfolge der Zeilen in der Ausgabe subtil verändern, was eine stille, brechende Änderung für bestehenden Code darstellt.
Diese Verschiebung birgt ein kritisches Risiko: Ausgabedaten können numerisch korrekt sein, aber stillschweigend an die falschen Zeilen angehängt werden. Solche Diskrepanzen führen zu subtiler Datenbeschädigung, die außergewöhnlich schwer zu erkennen und zu debuggen ist und möglicherweise nachgelagerte Analysen untergräbt. Im Gegensatz zu expliziten API-Änderungen löst dieses Problem nicht sofort einen Fehler aus, was es zu einer gefährlichen Falle macht.
Benutzer, die eine bestimmte Zeilenreihenfolge benötigen, müssen nun explizit maintain_order=True bei den betroffenen Operationen setzen. Diese Vorgabe wird von den Polars-Entwicklern als "gute Breaking Change" bezeichnet, da sie Benutzer dazu zwingt, die Datenkorrektheit zu definieren, anstatt sich auf die zufällige Zeilenbewahrung der vorherigen Engine zu verlassen. Für umfassende Details zu den Änderungen in Polars 2.0 lesen Sie den Version 2.0-rc - Polars user guide.
Gefällt Ihnen der Artikel? Erhalten Sie jeden Morgen einen wie diesen per E-Mail.
eine E-Mail pro Tag · Abmeldung mit zwei Klicks · kein Tracking durch Dritte
Warum dieses 'langweilige' Update für KI wichtig ist
Polars 2.0 festigt seine Position als leistungsstarke, auf Rust basierende Alternative zu Pandas, die speziell für große Daten-Workloads auf einzelnen Maschinen entwickelt wurde. Diese Version, die keine neuen benutzerorientierten Funktionen enthält, ist eine kritische architektonische Überarbeitung, die auf langfristige Stabilität, Speichereffizienz und Leistung ausgerichtet ist. Sie adressiert die zugrunde liegende Engine-Mechanik und API-Konsistenz, die für anspruchsvolle Data-Science- und KI-Anwendungen, bei denen Verarbeitungsgeschwindigkeit und Ressourcenmanagement von größter Bedeutung sind, unerlässlich sind.
Die interne Bereinigung ebnet direkt den Weg für fortschrittliche Funktionen, die für die zukünftige Datenverarbeitung und das Training von KI-Modellen entscheidend sind. Zu den kommenden Entwicklungen gehören ein cost-based planner, der darauf ausgelegt ist, komplexe Abfrageausführungspläne intelligent zu optimieren, sowie verbesserte join reordering-Algorithmen, die die Leistung bei komplexen Datenzusammenführungen verbessern. Diese architektonischen Verbesserungen, gepaart mit einer signifikanten Erweiterung der SQL-Abdeckung, werden es Polars ermöglichen, anspruchsvolle analytische Herausforderungen effizienter und zuverlässiger zu bewältigen und Engpässe bei der Datenvorbereitung zu reduzieren.
Entwickler betrachten dieses "langweilige" Update als strategische Investition in die grundlegende Stabilität, wobei Robustheit gegenüber sofortigen, auffälligen Funktionen priorisiert wird. Die neue standardmäßige streaming engine, die Daten in kleineren, parallelen Blöcken (Morsels) verarbeitet, soll die meisten Abfragen insgesamt "leicht 5x schneller" machen. Polars 2.0 stellt einen bewussten Schritt zur Festigung seiner Kernarchitektur dar, um eine schnellere, robustere Datenverarbeitungszukunft zu gewährleisten, die den sich entwickelnden Anforderungen von KI- und Machine-Learning-Pipelines gerecht wird, die eine konsistente Datenmanipulation mit hohem Durchsatz erfordern.
Häufig gestellte Fragen
Warum ist Polars 2.0 ein 'Breaking'-Release ohne neue Funktionen?
Polars 2.0 ist ein 'Aufräum-Release', das sich auf die interne Architektur und API-Konsistenz konzentriert. Es führt eine neue Standard-Abfrage-Engine ein und benennt mehrere Methoden um, was bestehenden Code beschädigen kann, aber diese Änderungen legen ein robusteres Fundament für die zukünftige Entwicklung.
Was ist die wichtigste Änderung in Polars 2.0?
Die kritischste Änderung ist, dass die neue Standard-'streaming engine' die Zeilenreihenfolge bei Operationen wie Joins und Group-bys nicht garantiert. Benutzer müssen nun explizit maintain_order=True setzen, um stille Datenintegritätsprobleme zu vermeiden.
Wie korrigiere ich meinen Code nach dem Upgrade auf Polars 2.0?
Die meisten Breaking Changes lösen einen AttributeRemovedError aus, der Ihnen genau sagt, was stattdessen zu verwenden ist (z. B. melt durch unpivot ersetzen). Überprüfen Sie bei potenziellen stillen Fehlern jeden Code, bei dem die Zeilenreihenfolge kritisch ist, und fügen Sie maintain_order=True hinzu.
Ist Polars 2.0 schneller als frühere Versionen?
Ja. Aufgrund der neuen Standard-Streaming-Engine, die Daten in parallelen Blöcken verarbeitet, wird erwartet, dass die meisten Abfragen deutlich schneller sind, mit einem geschätzten Leistungszuwachs von etwa 5x.
Unterstützt Polars 2.0 Datensätze, die größer als der RAM sind?
Noch nicht vollständig. Während die Streaming-Engine ein grundlegender Schritt in Richtung echter Out-of-Core-Verarbeitung ist, erfordert die aktuelle Implementierung immer noch, dass der Datensatz in den Arbeitsspeicher passt. Eine vollständige Out-of-Core-Unterstützung ist für ein zukünftiges Release geplant.