Wir stellen Apache Spark® 4.3 vor – jetzt in Databricks Runtime 19 verfügbar

Einführung

Apache Spark 4.3 bringt zustandsbehaftete Verarbeitung in den Echtzeitmodus und erreicht bei drei repräsentativen zustandsbehafteten Benchmarks eine P99-End-to-End-Latenz von unter 150 ms. Streaming-Aggregationen, Deduplizierung und benutzerdefinierte zustandsbehaftete Verarbeitung können jetzt im Low-Latency-Ausführungsmodus von Structured Streaming ausgeführt werden, wodurch dieser auf Anwendungen ausgeweitet wird, die sich Kontext über Ereignisse hinweg merken müssen.

Die Auswirkungen gehen über schnellere Pipelines hinaus. Für unterstützte Workloads benötigen Sie keine separate Streaming-Engine mehr, nur um Latenzen im Millisekundenbereich zu erreichen. Von der Betrugserkennung bis hin zu kontinuierlich aktualisierten Benutzeraktivitäten und der Geräteüberwachung können Entwickler zustandsbehaftete Anwendungen mit vertrauten Structured Streaming-APIs in derselben offenen Engine erstellen, die sie auch für Batch-Verarbeitung, Analysen und KI verwenden.

Zustandsbehaftetes Echtzeit-Streaming ist das Aushängeschild von Spark 4.3, aber die Verbesserungen erstrecken sich über die gesamte Engine. Das Release bietet fünf Hauptvorteile:

• Zustandsbehaftete Echtzeitanwendungen erstellen: Nutzen Sie Streaming-Aggregation, Deduplizierung und transformWithState im Echtzeitmodus, um den Kontext beim Eintreffen von Ereignissen beizubehalten.
• Historie mit SCD Type 2 Auto CDC bewahren: Verfolgen Sie Änderungen von Datensätzen im Laufe der Zeit mit Python, SQL und Spark Connect nach, mit weniger benutzerdefinierter Änderungserfassungslogik
• Schnellere Iteration bei kleinen Daten: Project Feather zielt auf unnötigen Ausführungs-Overhead ab, während Arrow-native Caching eine effizientere Datenwiederverwendung unterstützt.
• Mehr Anwendungen mit Spark verbinden: Verbesserungen bei Spark Connect-Beobachtbarkeit, JDBC-Integration und Python machen die Remote-Ausführung einfacher in der Entwicklung und im Betrieb.
• Umfangreichere Analysen direkt in SQL ausdrücken: VARIANT-Transformationen, JSON_TABLE, temporale Joins und eine Nanosekunden-Zeitstempel-Vorschau erweitern die native Verarbeitung von geschachtelten und zeitbezogenen Daten.

Zusammen helfen diese Änderungen Entwicklern dabei, eine einzige offene Engine zu nutzen, um Daten zu untersuchen, sich ändernde Kontexte beizubehalten und Analyse- sowie KI-Anwendungen zu betreiben.

Spark 4.3 markiert auch den Start eines vierteljährlichen Release-Rhythmus für Features, der von einer Veröffentlichung alle sechs Monate auf alle drei Monate umstellt. Dieser kürzere Zyklus bringt fertiggestellte Verbesserungen schneller in die Hände der Benutzer und gibt der Community häufiger die Möglichkeit, Feedback zu geben und die Zukunft mitzugestalten.

Echtzeit-Streaming: Zustandsbehaftete Anwendungen mit Latenzen im Millisekundenbereich

Von der Ereignisverarbeitung zur Aufrechterhaltung des Kontexts

Ein Betrugssignal hängt nicht nur von der letzten Transaktion ab, sondern auch von den Aktivitäten davor. Personalisierung muss das aktuelle Verhalten eines Benutzers widerspiegeln. Die Geräteüberwachung muss Zähler und Aggregate aktualisieren, wenn neue Messwerte eintreffen. Diese Anwendungen erfordern sowohl eine niedrige Latenz als auch einen Zustand.

Spark 4.3 erweitert den Echtzeitmodus auf diese zustandsbehafteten Verarbeitungsmuster und macht ihn zu einer vollständigen Streaming-Engine. Es fügt Unterstützung für Streaming-Aggregation, dropDuplicates und Scala/Java transformWithState (SPARK-58635, SPARK-57228) hinzu. Entwickler können schlüsselbasierte Zustände (Keyed State) verwalten und Ergebnisse mithilfe des vorhandenen Programmiermodells von Structured Streaming aktualisieren, anstatt eine andere Engine ausschließlich für eine geringere Latenz einzusetzen.

P99-Latenz unter 150 ms über drei zustandsbehaftete Benchmarks hinweg

In den in SPARK-58884 gemeldeten Benchmarks erreichten alle drei repräsentativen zustandsbehafteten Workloads eine P99-End-to-End-Latenz von unter 150 Millisekunden:

Diese Ergebnisse demonstrieren eine latenzarme Ausführung über Deduplizierung, fensterbasierte Aggregation und benutzerdefinierte zustandsbehaftete Verarbeitung hinweg. Dies sind Messungen der drei getesteten Workloads und keine Latenzgarantie für jede Pipeline.

Vertraute APIs, latenzarme Ausführung

Der Echtzeitmodus baut auf Structured Streaming auf, anstatt ein separates Programmiermodell einzuführen. Zustandsbehaftete Operatoren nutzen weiterhin die vorhandenen Zustandsspeicher- und Checkpoint-Mechanismen von Spark für Dauerhaftigkeit und Wiederherstellung.

Beispiel: Einen laufenden Zähler für jedes Gerät beibehalten. Gegeben ein Kafka-basiertes Streaming-DataFrame events mit einer device_id-Spalte:

Wenn Ereignisse für die Geräte A, A und B eintreffen, verwaltet Spark den Zustand und aktualisiert die Zähler auf A=2 und B=1. Wenn ein weiteres Ereignis für A eintrifft, wird dessen Zustand auf A=3 aktualisiert.

Eine für kontinuierlichen Datenfluss entwickelte Ausführungs-Engine

Die Unterstützung des zustandsbehafteten Echtzeitmodus erforderte eine grundlegende Änderung der Art und Weise, wie Spark Stages plant und verbindet. Bei einem herkömmlichen blockierenden Shuffle muss eine produzierende Stage abgeschlossen sein, bevor ihre nachgeschaltete Stage (Downstream Stage) beginnen kann. Dieses Modell kann keinen kontinuierlichen Datenfluss zwischen langlebigen Streaming-Tasks unterstützen.

Spark 4.3 führt die native gleichzeitige Stage-Planung (Concurrent Stage Scheduling) und Pipelined Shuffles ein, wodurch Produzenten- und Konsumenten-Stages gleichzeitig ausgeführt werden können (SPARK-54699, SPARK-58076, SPARK-56664). Streaming Shuffle implementiert diese Funktion für den Echtzeitmodus, indem Datensätze inkrementell an den nachgeschalteten Task übertragen werden, der für den jeweiligen Schlüssel verantwortlich ist, anstatt zu warten, bis die gesamte produzierende Stage abgeschlossen ist.

Konzeptionell ändert sich die Ausführung von:

Producer-Stage → Shuffle materialisieren → Consumer-Stage

zu:

Producer-Stage ⇄ Streaming-Shuffle ⇄ Consumer-Stage

Spark 4.3 fügt PipelinedShuffleDependency hinzu, eine neue Art von Shuffle-Abhängigkeit, die es Konsumenten ermöglicht, mit dem Lesen zu beginnen, während Produzenten noch laufen (SPARK-58185). Der Scheduler behandelt Stages, die durch diese Abhängigkeiten verbunden sind, als eine Pipeline-Gruppe, eine koordinierte Planeinheit. Ihre Stages werden zusammen geplant, und ein Fehler in einer Stage führt dazu, dass die gesamte Gruppe fehlschlägt (SPARK-58263, SPARK-58398). Kurz gesagt: Sie laufen zusammen und schlagen gemeinsam fehl.

Da alle Stages in einer Pipeline-Gruppe gleichzeitig ausgeführt werden, lässt Spark die Gruppe nur zu, wenn genügend Task-Slots für alle ihre Tasks verfügbar sind. Andernfalls schlägt sie schnell fehl, anstatt zu hängen.

Spark leitet jeden Shuffle basierend auf seinem Abhängigkeitstyp an einen Shuffle-Manager weiter:

• Ein regulärer ShuffleDependency verwendet einen blockierenden Shuffle-Manager, der alle Shuffle-Ausgaben materialisiert, bevor nachgeschaltete Stages sie lesen. SortShuffleManager ist die integrierte Implementierung.
• Ein PipelinedShuffleDependency verwendet einen Pipelined Shuffle Manager, der die Ausgabe sofort bei ihrer Erstellung verfügbar macht. StreamingShuffleManager ist die integrierte Implementierung (SPARK-57141).

Der Abhängigkeitstyp definiert den Ausführungsvertrag; der Shuffle Manager stellt den Mechanismus für die Datenübertragung bereit. Der Scheduler koordiniert pipelined Stages, ohne wissen zu müssen, welche Workload sie erstellt hat.

Diese Grundlage geht über den Echtzeitmodus hinaus. Die gleichzeitige Stage-Planung, der pipelined Datenaustausch und die koordinierte Ausführung sind generische Funktionen der Spark-Engine und keine einmalige Streaming-Infrastruktur. In Spark 4.3 ermöglichen sie eine zustandsbehaftete Verarbeitung mit gering Latenz. Langfristig bieten sie eine Basis für andere Workloads, die über das herkömmliche Stage-by-Stage-Ausführungsmodell hinausgehen müssen.

Hintergrundinformationen zum Design und zu den Anwendungsszenarien des Echtzeitmodus finden Sie in der Einführung in den Echtzeitmodus. Dieser Beitrag beschreibt die Databricks-Implementierung; der hier besprochene Funktionsumfang von Spark 4.3 und die Benchmark-Ergebnisse entsprechen den oben genannten.

Project Feather: Schnelleres Iterieren bei kleinen Daten

Die KI-gestützte Entwicklung folgt häufig einer kurzen Feedbackschleife: Generieren Sie eine Transformation, führen Sie diese auf einem Sample aus, überprüfen Sie die Ergebnisse und verfeinern Sie den Code. Jede Iteration verarbeitet möglicherweise nur eine kleine Datei oder wenige Zeilen, dennoch können Aufgabenplanung und Shuffling mehr kosten als die eigentliche Berechnung.

Project Feather zielt auf diesen festen Ausführungs-Overhead ab und macht Spark reaktionsschneller für das Erkunden und Validieren von SQL- und DataFrame-Code auf kleinen Datensätzen. Entwickler können dieselben APIs verwenden, wenn sie von einem Sample zu größeren Workloads übergehen – unabhängig davon, ob sie den Code selbst schreiben oder mit einem KI-Assistenten arbeiten.

Spark 4.3 führt eine optionale, shuffle-freie Single-Task-Ausführung für geeignete kleine, partitionenübergreifende Abfragefragmente ein (SPARK-57851). Wenn ein qualifizierender Scan meldet, dass seine Ausgabe bereits in einer Partition vorliegt, können unterstützte nachgeschaltete Operationen ein unnötiges Shuffling vermeiden.

Beispiel: Ausführen und Überprüfen einer kleinen Aggregation. Verwenden Sie ein kleines Parquet-Dataset, das als einzelne Datei gespeichert ist, mit einer Kategoriesspalte:

Sechs Fälle:

category, Exchange, SPARK_LOCAL_CONNECT_REUSE=1, zip, counter_diff and jaro_winkler_similarity.

Das Ergebnis ist eine Anzahl pro Kategorie. Bei einer gültigen Abfrage kann der physische Plan das `Exchange` weglassen, das sonst ein Shuffling auslösen würde. Dies unterstützt denselben Workflow zum Ausführen und Überprüfen, unabhängig davon, ob die Transformation von einem Entwickler geschrieben oder von einem Coding-Assistenten vorgeschlagen wurde.

Bei den Standard-Eignungsgrenzen lesen qualifizierende Dateiscans eine nicht leere kleine Datei, die in eine einzige Partition passt, während qualifizierende lokale In-Memory-Relationen bis zu 1.000 Zeilen enthalten. Zu den unterstützten Abfrageformen gehören ausgewählte Scans, Aggregationen, Distinct-Operationen, Window-Funktionen, Sortierungen und Limits.

Feather fügt außerdem ein optionales Arrow-natives Dataset-Caching hinzu (SPARK-57268), bei dem gecachte Batches im Arrow-Format mit Komprimierung und Spaltenstatistiken gespeichert werden. Arrow-basierte Eingaben können unnötige Konvertierungen vermeiden und Workloads unterstützen, die dieselben Daten wiederholt untersuchen. Sowohl die Single-Task-Optimierung als auch der Arrow-Cache sind optional. Um diese zu aktivieren, setzen Sie die statische Konfiguration spark.sql.cache.serializer=org.apache.spark.sql.execution.columnar.ArrowCachedBatchSerializer beim Start einer neuen Spark-Anwendung. Eine umfassendere lokale Repartitionierung im Prozess ist als Folgearbeit für das nächste Release geplant (SPARK-57399).

Diese Verbesserungen sind erst der Anfang. Die Spark-Community wird in zukünftigen Versionen weiterhin in die Leistung bei kleinen Daten investieren, um den Ausführungs-Overhead zu reduzieren und Feedbackschleifen für interaktive Erkundungen und KI-gestützte Entwicklung zu verkürzen.

SCD Type 2 in Open-Source Auto CDC: Historie bei Datenänderungen beibehalten

Eine Tabelle mit dem aktuellen Status kann Ihnen zwar sagen, wo ein Kunde heute wohnt, aber nicht, zu welcher Region er gehörte, als eine Bestellung aufgegeben wurde. Reporting, Auditing und historische Analysen erfordern oft beides. Spark 4.3 fügt Auto CDC eine umfassende Unterstützung für Slowly Changing Dimensions (SCD) Typ 2 hinzu (SPARK-56249), sodass Pipelines die Historie jedes Datensatzes verfolgen können, anstatt den neuesten Wert bei jeder Änderung zu überschreiben. Die Funktion ist über Python, SQL und Spark Connect verfügbar (SPARK-58321, SPARK-58247, SPARK-58261) und ermöglicht Benutzern, Änderungen automatisch anzuwenden, anstatt manuelle Merge-Vorgänge durchzuführen.

Beispiel: Kundenstatus und Region im Zeitverlauf verfolgen. Gegeben sei eine customer_changes-Pipeline-Quelle mit einer Kunden-ID, der Event-Zeit, dem Status und der Region:

Alternativ kann dies in SQL ausgedrückt werden:

In einer SCD-2-Ausgabetabelle wird jeder eindeutige Schlüssel durch eine Sequenz von Datensätzen dargestellt, die jeweils den Start und das Ende ihrer Gültigkeit mithilfe von zwei zusätzlichen Metadatenspalten (__START_AT und __END_AT) markieren. Wenn beispielsweise ein Änderungsdatensatz anzeigt, dass der Kunde mit der ID 17 von Region West nach East gezogen ist, behält die Pipeline den Datensatz mit der vorherigen Region West bei und markiert dessen Ende als die Event-Zeit des Änderungsdatensatzes; sie fügt einen neuen Datensatz mit Region East und der Event-Zeit des Datensatzes als Startzeit ein. Eine Analyse kann dann die Region verwenden, die zum relevanten Zeitpunkt in der Event-Zeit-Sequenz gültig war.

Im Hintergrund verbindet Auto CDC die deklarative Flussdefinition mit der Ableitung des Zielschemas und einer dedizierten SCD-Typ-2-Stream-Verarbeitung (SPARK-58319, SPARK-57395, SPARK-58321). Schlüssel identifizieren die Entität, die Sequenzierung bestimmt die Reihenfolge der Änderungen, und die Spalten zur Historienverfolgung legen fest, welche Attributänderungen historische Versionen erstellen. Die Engine validiert außerdem reservierte Spalten, Sequenzierungstypen und die Konfiguration der Historienverfolgung (SPARK-57251, SPARK-58313, SPARK-58391) und gleicht kleinere Mikro-Batches mit einem weiterentwickelten Zielschema ab (SPARK-58418).

Auto CDC wendet jeden Mikro-Batch mithilfe von MERGE auf das Ziel an, weshalb sich die Zieltabelle in einem Katalog befinden muss, dessen Connector zeilenebene Operationen von Data Source V2 implementiert. Die integrierten Dateiformate von Spark, einschließlich Parquet, erfüllen diese Voraussetzung nicht. Daher ist Iceberg eine häufige Wahl.

Spark Connect: Einfacher zu entwickeln, zu beobachten und zu betreiben

Anwendungen und KI-Agenten müssen Spark aus ihren eigenen Prozessen aufrufen, Sitzungen verwalten und eine fehlgeschlagene Anfrage mit der auf dem Server auszuführenden Arbeit verknüpfen. Spark 4.3 stärkt Spark Connect für diese Workflows durch Sitzungs- und Operationssichtbarkeit, Anforderungszuordnung und einen breiteren Client-Support.

Spark Connect sendet DataFrame-Operationen als logische Pläne über gRPC, führt sie über die Spark-Engine des Servers aus und streamt Ergebnisse in Arrow-Batches zurück. Spark 4.3 fügt REST-Endpunkte zum Auflisten und Untersuchen von Connect-Sitzungen und -Operationen sowie Operations-IDs hinzu, um die Ausführung über Clients und den Server hinweg nachzuverfolgen (SPARK-57941, SPARK-58547). Für die lokale PySpark-Entwicklung auf POSIX-Systemen wird durch die experimentelle Option `SPARK_LOCAL_CONNECT_REUSE=1` ein persistenter Connect-Server über mehrere Läufe hinweg wiederverwendet, wodurch wiederholter Startaufwand vermieden wird (SPARK-57787). Der SQLContext-Kompatibilitätswrapper von PySpark funktioniert ebenfalls mit Spark Connect (SPARK-57021).

Der Spark Connect JDBC-Treiber fügt Unterstützung für ARRAY-, MAP- und STRUCT-Ergebnisse sowie eine leistungsfähigere Verarbeitung von Ergebnismengen (SPARK-57380, SPARK-57274), SQL-Typ-Metadaten und eine kompatiblere Schema-Introspektion (SPARK-57627) sowie eine verbesserte Ausnahmebehandlung hinzu (SPARK-57933, SPARK-58619). Die API-Abdeckung wird durch DataFrame.zip, SCD Type 2 Auto CDC sowie Nanosekunden-Zeitstempeltypen und Literale erweitert (SPARK-57247, SPARK-58247, SPARK-57160, SPARK-57161).

Unabhängig davon umfasst die Community-Arbeit ein Spark Connect Gateway (SPARK-58455) für sitzungsbasiertes Routing und mandantenfähige Operationen, Rust- und Rust-basierte Python-Clients (SPARK-58960) für einen alternativen Client-Implementierungspfad sowie einen Vorschlag zur Fähigkeitserkennung (SPARK-56398) zur Identifizierung unterstützter Serveroperationen vor dem Absenden einer Abfrage. Diese Bemühungen haben separate Entwicklungszeitpläne und sind keine gebündelten 4.3-Funktionen.

PySpark: Umfangreichere APIs und bessere Python-Ausführung

Python-Workflows erstellen abgeleitete Spalten oft in separaten Schritten, kombinieren die Ergebnisse und verschieben Daten zwischen pandas, Arrow und Spark. Spark 4.3 stellt mehr dieser Funktionen über DataFrame-APIs zur Verfügung und optimiert gleichzeitig die zugrundeliegenden Ausführungspfade. DataFrame.zip fügt eine Möglichkeit hinzu, kompatible Spaltenprojektionen zu kombinieren, ohne auf RDD-APIs zurückzugreifen, auch bei der Verwendung von Spark Connect (SPARK-55886, SPARK-57247).

Beispiel: Kombinieren Sie Bezeichner mit einem abgeleiteten Wert. Erstellen Sie zwei Projektionen aus derselben Eingabe und führen Sie deren Spalten zusammen:

Das Ergebnis paart id=1 mit doubled=20 und id=2 mit doubled=40. `zip` kombiniert rein projektionsbasierte Transformationen desselben zugrundeliegenden Plans; Filterung, Sortierung, Joins oder Aggregationen unterhalb dieser Projektionen müssen auf beiden Seiten identisch sein, um die Zeilenausrichtung beizubehalten.

Die umfassenderen Arbeiten zur Ausführung zielen auf Datentransfer, Batch-Verarbeitung und native Berechnung ab. Auf Pickle basierende UDF-Eingabe-Batches können nach Bytes statt nur nach Zeilenanzahl begrenzt werden, was eine bessere Kontrolle ermöglicht, wenn Zeilen in der Größe variieren (SPARK-57593). Gebatchte pandas-on-Spark-Projektionen und zusätzliche native NumPy-Implementierungen reduzieren vermeidbare Arbeit (SPARK-58230, SPARK-58234), während die Konvertierung von pandas zu Spark Unterstützung für PyArrow ChunkedArray-Spalten hinzufügt (SPARK-46776).

Das Release fügt außerdem Python- und Scala-Bindings für bestehende Vektorfunktionen (SPARK-57284), gruppierte Kovarianz und deskriptive Statistiken (SPARK-40336, SPARK-40337), gleitende und expandierende Median- und Standardfehleroperationen (SPARK-40341, SPARK-40340) sowie show_versions-Diagnosen hinzu (SPARK-40373). Traceback-Lokale sind optional, da sie sensible Daten enthalten können (SPARK-57271).

Spark SQL: Besseren Kontext für Analytics und KI vorbereiten

Ereignisnutzdaten kommen als verschachtelte Dokumente an, und dicht aufeinanderfolgende Ereignisse erfordern möglicherweise eine höhere Präzision als Mikrosekunden. Die Vorbereitung dieser Eingaben sollte keine separate benutzerdefinierte Verarbeitungsschicht für jede Transformation erfordern. Spark 4.3 erweitert natives SQL für semistrukturierte Daten und zeitbezogene Analysen, einschließlich Dokumentenbearbeitung, zeitlichem Abgleich und einer optionalen Nanosekunden-Zeitstempel-Vorschau (SPARK-56822).

Beispiel: Unterscheiden Sie zwei Ereignisse innerhalb derselben Mikrosekunde. Aktivieren Sie die Vorschau (Funktion ist noch nicht stabil, es kann zu Breaking Changes kommen) und vergleichen Sie Zeitstempel im Abstand einer Nanosekunde (SPARK-56969, SPARK-56965, SPARK-57211):

Der Vergleich ergibt true: Die letzte Ziffer wird beibehalten statt verworfen. Die Vorschau unterstützt TIMESTAMP_NTZ(p) und TIMESTAMP_LTZ(p) bei Genauigkeiten von 7 bis 9.

Dies erforderte mehr als nur das Akzeptieren eines neuen SQL-Typnamens. Die Nanosekunden-Unterstützung erstreckt sich auf Parsing, interne Wertedarstellungen, Casts, Ausdrücke, Spark Connect, Caching und Datenquellenintegration (SPARK-56822). Neue timestamp_nanos- und unix_nanos-Funktionen verarbeiten numerische Konvertierungen (SPARK-57526, SPARK-57527). Speicher- und Connector-Unterstützung bleiben für jeden Datenpfad spezifisch, daher muss die Vorschau von Anfang bis Ende evaluiert werden.

Verwandeln Sie sich verändernde JSON-Nutzdaten in nutzbare Daten

Anwendungsereignisse, Dokumentexporte und Modellantworten kommen oft als verschachteltes JSON an. Spark 4.3 JSON_TABLE (SPARK-58366) kombiniert Array-Erweiterung und typisierte Feldextraktion, während VARIANT-Transformationen es Pipelines ermöglichen, Felder ohne benutzerdefinierte Dokumentverarbeitungs-UDFs zu aktualisieren oder zu entfernen (SPARK-57804, SPARK-57417). Zusammen vereinfachen sie die Aufbereitung von Inhalten für Analyse-, Anreicherungs- und Abruf-Pipelines.

Beispiel: Relevante Dokumentenabschnitte extrahieren.

Dadurch entsteht eine typisierte Zeile, die eine Pipeline vor weiteren nachgeschalteten Operationen mit Quell-Metadaten anreichern kann. JSON_TABLE löst seine Spaltenpfade durch einen gemeinsamen Durchlauf jedes Zeilenelements auf, wodurch ein separates Parsen für jede Spalte vermieden wird. Unabhängig davon erweitert Spark den Pushdown für die Extraktion von VARIANT-Feldern auf unterstützte Abfragen, die aggregieren, sortieren oder verknüpfen (SPARK-58089).

Weiterführende SQL/JSON-Arbeiten (SPARK-58686) führen diese Richtung fort mit JSON_VALUE, JSON_EXISTS und JSON_QUERY für skalare Extraktion, Existenzprüfungen und Fragmentabruf (SPARK-58685, SPARK-58687, SPARK-58723). Die explizite Behandlung fehlender Werte und von Fehlern hilft Anwendungen dabei, sich ändernde Schemas vorhersehbarer zu verarbeiten. Dies sind weiterführende Entwicklungen und keine zusätzlichen 4.3-Funktionen.

Ereignisse den zum Zeitpunkt verfügbaren Informationen zuordnen

Historische Analysen und Modellbewertungen erfordern den Kontext, der beim Auftreten eines Ereignisses verfügbar war, und keine später hinzugefügten Informationen. Das SQL ASOF JOIN von Spark 4.3 drückt diesen zeitlichen Abgleich direkt aus (Funktion in der Vorschau, es kann zu Breaking Changes kommen) und ersetzt handgeschriebene Bereichs-Joins gefolgt von einer Rangbildung (SPARK-58092).

Beispiel: Rekonstruktion der für eine Vorhersage verfügbaren Features. Hier zeichnet available_at auf, wann eine Feature-Version verfügbar wurde (SPARK-58122, SPARK-58123):

Eine Vorhersage um 10:03 Uhr entspricht der um 10:00 Uhr verfügbaren Feature-Version, nicht der von 10:05 Uhr. Ein dedizierter Sort-Merge-Ausführungspfad macht diesen Abgleich zu einer Engine-Operation anstelle einer anwendungsspezifischen Abfragelogik. Das Ergebnis ist eine einfachere zeitpunktbezogene Anreicherung für Trainingsdaten, Evaluierungen und Vorfallanalysen, vorausgesetzt, die Verfügbarkeits-Zeitstempel spiegeln genau das wider, was damals bekannt war.

Nennenswerte Verbesserungen und Danksagungen

Spark 4.3 führt außerdem neue APIs und Leistungsverbesserungen für die alltägliche Datenverarbeitung ein. SQL erhält ANSI UNNEST zum Erweitern von Arrays in Zeilen zusammen mit der Fensterschichtfunktion `counter_diff` zum Konvertieren kumulativer Zähler in Deltas und `jaro_winkler_similarity` für String-Ähnlichkeitsvergleiche. Unterstützte Dateiquellen erhalten eine optionale Unterstützung zum Lesen von tar-, zip- und 7z-Archiven, wodurch ein separater Extraktionsschritt entfällt. Die Engine verbessert die Aggregationsausführung und ermöglicht standardmäßig die Whole-Stage-Code-Generation für berechtigte UNION-Operationen. Eine optionale Optimierung verteilt Null-Join-Keys über Shuffle-Partitionen in berechtigten Outer- und Anti-Joins. Die Verarbeitung verschachtelter Daten erhält ein stärkeres Bereinigen nicht verwendeter Felder in Arrays von Structs und eine Code-Generation für weitere Array-Higher-Order-Funktionen. Vektorisierte Parquet-Lesevorgänge verbessern die Typkonvertierung und die Wörterbuchdekodierung.

Spark 4.3 spiegelte die Stärke der Apache Spark-Community wider, wobei über 200 Mitwirkende bei der Bearbeitung von mehr als 1.100 Jira-Tickets halfen. Wir danken allen, die Code, Reviews, Tests, Dokumentationen und Feedback beigetragen haben, um dieses Release zu ermöglichen.

Erste Schritte mit Spark 4.3

Besuchen Sie die Apache Spark-Download-Seite für Releases und Dokumentationen und lesen Sie vor dem Upgrade die Migrationsleitfäden. Informationen zur Databricks-Verfügbarkeit finden Sie in den Databricks Runtime-Release-Hinweisen.

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag