Amazon EMR bekommt eine LTS-Linie mit 36 Monaten, zuerst mit Spark 4.1
Serguey Asael Shinder2 Min. LesezeitAWS hat Long-Term-Support-Releases fuer Amazon EMR eingefuehrt, beginnend mit emr-spark-8.1.0 und Apache Spark 4.1. Die Mitteilung datiert auf den 22. September 2026.
Ausgewiesene Versionen der AWS-Laufzeit fuer Apache Spark erhalten nun 36 Monate Support, mit Korrekturen fuer kritische und schwerwiegende Sicherheits-, Fehler- und Datenkorruptionsprobleme, vorbehaltlich der Verfuegbarkeit. Den Zweck benennt AWS unumwunden: Produktions-Workloads laenger auf einem Release betreiben und nach eigenem Zeitplan aktualisieren, ohne Zusatzkosten.
Das Release selbst bringt mehrere Aenderungen, die von der Supportpolitik zu trennen sind. Es unterstuetzt Apache Iceberg v3 vollstaendig und bringt damit Geodatentypen, hochpraezise Zeitstempel und Faehigkeiten zur Schema-Evolution. Spark-SQL-Abfragen koennen Kataloge per Namen ansprechen, auch kontenuebergreifend und bei Amazon-S3-Tables-Katalogen, und erkennen die Tabellenformate Iceberg, Delta Lake und Hudi automatisch, ohne jeden Katalog in der Spark-Konfiguration zu registrieren. Die feingranulare Zugriffskontrolle deckt mehr Iceberg-Operationen und die Delta-Lake-Operation VACUUM ab, sodass Spalten- und Zeilenrechte fuer mehr Jobs gelten. EMR-on-EKS-Cluster unterstuetzen Spark-Connect-Endpunkte mit tokenbasierter Authentifizierung.
Verfuegbar ist es in allen Regionen mit EMR, auf EMR on EC2, EMR on EKS und EMR Serverless.
Was das bedeutet
Drei Jahre Korrekturen fuer eine Datenlaufzeit sind eher eine Terminfrage als eine technische — und der Termin ist der teure Teil. Ein Spark-Upgrade ist selten nur ein Versionssprung: Es veraendert UDF-Verhalten, Konnektorversionen und gelegentlich Abfrageergebnisse, sodass die Arbeit in der Validierung liegt und nicht im Ausrollen. Den Zeitpunkt dafuer selbst zu waehlen, statt von einem Supportfenster getrieben zu werden, ist hier das eigentliche Produkt.
Die Formulierung verdient genaues Lesen: kritische und schwerwiegende Sicherheits-, Fehler- und Datenkorruptionskorrekturen, vorbehaltlich der Verfuegbarkeit. Das ist enger als "gepflegt" — eine Leistungsregression oder ein mittelschweres Problem ist nicht zugesagt, und der Vorbehalt leistet echte Arbeit.
Im Alltag sichtbar wird die Katalog-per-Name-Aenderung. Die Registrierung je Katalog aus der Spark-Konfiguration zu nehmen, verschiebt umgebungsspezifisches Setup aus dem Deployment in die Abfrage — dorthin, wo die meisten Teams es ohnehin haben wollten.