AWS Glue 5.1 auf Spark 3.5.6: Was Datenteams jetzt tun müssen

Jeder Plattform-Lead, der schon einmal einen Batch-Job am Sonntagmorgen betrieben hat, kennt den Moment, wenn ein Spark-Versionskonflikt in einem Slack-Thread auftaucht, den niemand lesen möchte. AWS Glue hat seine Runtime innerhalb von zwölf Monaten zweimal stillschweigend aktualisiert. Wer Jobs noch auf 4.0 pinnt, liegt inzwischen zwei Engine-Versionen zurück. Der aktuelle Einstiegspfad über Amazons serverlose ETL-Oberfläche führt direkt zu Glue 5.1, und die Lücke zwischen dem Stand der meisten Teams und dem Ausgangspunkt neuer Projekte ist größer geworden.

Was passiert ist

Wie https in einem Walkthrough vom 21. August 2026 von Nadia Dubois berichtete, wurde AWS Glue 5.1 am 26. November 2025 veröffentlicht und läuft nun auf Apache Spark 3.5.6, Python 3.11 und Scala 2.12.18. Dieser Release folgte auf Glue 5.0, das Ende 2024 auf Spark 3.5.4 erschien und die Engine von der Spark-3.3.0-Basis ablöste, auf der Glue 4.0 feststeckte. In der Praxis bedeutet das für Teams, die einen Zyklus übersprungen haben: ein Sprung über zwei Spark-Nebenversionen und einen Python-Interpreter-Wechsel in einer einzigen Migration.

Glue 5.0 brachte mehr als Spark. Es enthielt Java 17, Hudi 0.15.0, Iceberg 1.7.1 und Delta Lake 3.3.0 und fügte Unterstützung für Amazon SageMaker Unified Studio und SageMaker Lakehouse hinzu. Glue 5.1 verwendet dieselben Python- und Scala-Versionen wie 5.0 und fügt laut AWS Performance- und Sicherheitsverbesserungen auf Basis des Spark-3.5.6-Updates hinzu.

Die Änderung mit dem größten operativen Auswirkungsradius kam im Juni 2025, als AWS Unterstützung dafür hinzufügte, dass Glue-5.0-Spark-Jobs direkt auf bei AWS Lake Formation registrierten Tabellen lesen und schreiben können – vorausgesetzt, die IAM-Rolle des Jobs verfügt über vollständigen Tabellenzugriff. Das ist genau die Art von leiser Feature-Einführung, die Lakehouse-Zugriffsmuster grundlegend verändert, ohne dass jemand darüber lautstark berichtet.

Technische Struktur

Die Glue-Architektur hat sich grundsätzlich nicht verändert. Es gibt weiterhin drei relevante Komponenten: den Glue Data Catalog als gemeinsamen Metadatenspeicher, Crawlers für die Schema-Erkennung und Jobs als ETL-Compute. Der Data Catalog bleibt das Herzstück, da er von Athena, Redshift Spectrum, EMR und Lake Formation gelesen wird. Daten einmal katalogisieren, aus vier Engines abfragen – das ist das eigentliche Produkt.

Was sich darunter verändert hat, ist die Runtime. Der Wechsel von Spark 3.3.0 in Glue 4.0 zu Spark 3.5.6 in Glue 5.1 ist kein einfaches Patch-Update. Der Catalyst-Optimizer verhält sich anders, die Standardwerte für Adaptive Query Execution haben sich verschoben, und Python 3.11 bricht alles, was auf älteres Typing-Verhalten oder entfernte Standardbibliotheksmodule angewiesen ist. Teams, mit denen ich bei ähnlichen Spark-Upgrades gearbeitet habe, unterschätzen konsequent die UDF-Oberfläche – besonders dort, wo pandas UDFs und PyArrow-Versionen zusammenwirken. Bei Scala-2.12-Jobs landet man weich, da Glue 5.x bei Scala 2.12.18 bleibt. Wer auf Scala 2.13 setzt, bekommt hier keine Erleichterung.

Die direkte Lese-/Schreibänderung für Lake Formation verdient einen eigenen Absatz. Vor Juni 2025 bedeutete das Ausführen eines Spark-Jobs gegen LF-verwaltete Tabellen, das Berechtigungsmodell zu umgehen oder auf reine Catalog-Lesezugriffe zurückzufallen. Jetzt kann Glue 5.0 Spark diese Tabellen nativ erreichen, sofern die IAM-Rolle des Jobs vollständigen Tabellenzugriff hat. Das ist der Baustein, der Glue endlich als primären Compute für ein Lake Formation-zentrisches Lakehouse tragfähig macht – statt nur als Metadaten-Teilnehmer. Für Teams, die Iceberg über Lake Formation standardisieren, schließt das eine echte Lücke. Für Teams, die Databricks-verwaltetes Delta auf denselben Daten nutzen, ist das Bild weniger klar; die Databricks-Dokumentation setzt weiterhin voraus, dass man die Compute-Ebene selbst kontrolliert.

Ein Detail, das für kostenempfindliche Workloads relevant ist: Glue Python Shell-Jobs laufen ohne Spark-Cluster. Da Glue-ETL-Compute nach DPU-Stunde abgerechnet wird, kann ein Python Shell-Job für eine leichtgewichtige Orchestrierungsaufgabe um eine Größenordnung günstiger sein als ein Spark-Job, der den Großteil seiner Zeit mit dem Cluster-Start verbringt. Das ist verschwendetes Geld bei Teams, die standardmäßig jeden Job-Typ auf Spark setzen.

Wer Probleme bekommt

Die Teams mit dem schwierigsten Quartal sind jene, die produktive Glue-4.0-Jobs mit umfangreichen PySpark UDFs und ohne diszipliniertes Runtime-Pinning betreiben. Zwei Spark-Nebenversionen und ein Sprung von Python 3.9 auf 3.11 sind kein Lift-and-Shift. Regressionstests werden echte Engineering-Zeit kosten. In einem zehnköpfigen Datenplattform-Team entspricht ein zweiköpfiger Migrationsaufwand für ein Quartal zwanzig Prozent der Kapazität – und das, bevor jemand ein Ticket zu einer defekten Athena-Abfrage downstream öffnet.

iGaming- und Fintech-Unternehmen, die geplante Batch-ETL gegen S3-Data-Lakes betreiben, sind die offensichtlich betroffene Gruppe – besonders wenn derselbe Catalog Athena-Dashboards für Compliance-Reporting speist. Die unbequeme Einschätzung: Wer seinen Reporting-Stack 2023 auf Glue 4.0 aufgebaut hat und ihn nie angefasst hat, weil er funktionierte, liegt nun drei Jahre und zwei Runtimes zurück – und die Deprecation-Uhr macht für niemanden eine Pause.

Lakehouse-Teams erhalten gemischte Nachrichten. Wer auf Iceberg auf Lake Formation gesetzt hat, findet in Glue 5.0 und 5.1 die ersten Releases, bei denen die Geschichte von Anfang bis Ende stimmig ist. Wer auf Delta Lake mit Databricks-verwaltetem Compute gesetzt hat und Glue als günstige Sekundär-Engine nutzte, steht vor einem dünner werdenden Wertversprechen. Delta Lake 3.3.0 ist in Glue 5.0 enthalten, aber der operative Schwerpunkt für Delta liegt weiterhin anderswo.

Teams, die Snowflake als Warehouse und Glue nur als Ingest-Schicht nutzen, sind von den Lakehouse-Änderungen weitgehend unberührt, sollten aber dennoch auf den Python-3.11-Wechsel achten. Jeder benutzerdefinierte Connector-Code, der 3.9-Semantik voraussetzt, muss geprüft werden. Snowflakes Ingestion-Muster sind in der Snowflake-Dokumentation beschrieben, falls man die Grenzen neu auslotet.

Leitfaden für Datenteams

Meine Einschätzung: Kein neues Glue-Projekt, das in Q3 2026 startet, sollte auf eine ältere Version als 5.1 abzielen. Die Runtime-Lücke wird sich nur vergrößern, und heute auf 4.0 zu starten bedeutet, sich für eine Migration anzumelden, die noch nicht geplant ist.

Konkrete Maßnahmen für diese Woche:

• Glue-Jobs nach Version inventarisieren. Wer bis Freitag keine Tabelle aller Jobs mit ihrer Runtime vorweisen kann, sollte genau dort anfangen. Jobs dabei gleich dem verantwortlichen Team zuordnen.
• Runtimes explizit pinnen. Nicht auf Standardwerte verlassen. Die Glue-Versionshinweise listen die genauen gebündelten Versionen von Hadoop, Iceberg, Hudi und Delta Lake pro Release auf. In der IaC gegen diese Matrix pinnen.
• UDFs auf Python-3.11-Kompatibilität prüfen. Alles, was distutils, veraltete asyncio-APIs oder ältere Typing-Muster verwendet, muss angepasst werden, bevor ein Job auf 5.1 umgestellt wird.
• Jobs nach Typ neu klassifizieren. Jeder Job, der eigentlich Orchestrierung oder leichte Datenverarbeitung ist, sollte zu Python Shell wechseln, nicht Spark ETL. Glue wird nach DPU-Stunde abgerechnet, und ein Spark-Cluster-Start für eine 30-Sekunden-Aufgabe ist reiner Budgetverlust.
• Lake Formation-Integration in einer Sandbox testen. Wer verwaltete Tabellen betreibt, sollte den direkten Lese-/Schreibpfad vom Juni 2025 mit einer Rolle mit vollständigem Tabellenzugriff validieren, bevor Produktions-Jobs umgekabelt werden.

Für Teams, die prüfen, ob Glue überhaupt das richtige Werkzeug ist: Die ehrliche Antwort hängt von der Workload-Form ab. Wer SQL-first transformiert und das Warehouse ins Zentrum stellt, wird mit dbt plus einer Warehouse-Engine in der Ergonomie immer besser fahren als mit Glue. Glue rechtfertigt seine DPU-Stunden bei echten Spark-Workloads, S3-nativen Daten und einem Catalog, der Engine-übergreifend geteilt werden soll.

Die wichtigsten Erkenntnisse

• AWS Glue 5.1 erschien am 26. November 2025 auf Spark 3.5.6, Python 3.11 und Scala 2.12.18. Kein neues Projekt sollte auf eine ältere Runtime abzielen.
• Der Sprung von Spark 3.3.0 auf 3.5.6 von Glue 4.0 auf 5.1 ist eine echte Migration, kein Versions-Bump. Entsprechend planen und budgetieren.
• Die direkte Lese-/Schreibunterstützung für Lake Formation vom Juni 2025 macht Glue als primären Compute für LF-verwaltete Lakehouses tragfähig – sofern die IAM-Rolle vollständigen Tabellenzugriff hat.
• Glue Python Shell-Jobs umgehen den Spark-Cluster vollständig und sind die richtige Standardwahl für leichtgewichtige, nach DPU-Stunde abgerechnete Workloads.
• Der Data Catalog bleibt Glues eigentlicher Vorteil: gemeinsam genutzt von Athena, Redshift Spectrum, EMR und Lake Formation aus einem einzigen Crawl.