Migration von Aufträgen von AWS Glue für Spark zur AWS Glue-Version 4.0

Es basiert auf Apache Spark 3.3.0, enthält jedoch Optimierungen in AWS Glue und Amazon EMR, wie z. B. adaptive Abfrageläufe, vektorisierte Lesegeräte und optimierte Shuffles und Partitionszusammenführung.

Aktualisierte JDBC-Treiber für alle AWS Glue nativen Quellen, einschließlich MySQL, Microsoft SQL Server, Oracle, PostgreSQL, MongoDB, und aktualisierte Spark-Bibliotheken und -Abhängigkeiten, die von Spark 3.3.0 bereitgestellt wurden.

Aktualisiert mit einem neuen Amazon-Redshift-Konnektor und JDBC-Treiber.

Optimierter Amazon-S3-Zugriff mit aktualisiertem EMR File System (EMRFS, EMR-Dateisystem) und standardmäßig aktivierten Amazon-S3-optimierten Ausgabe-Committern.

Optimierter Data-Catalog-Zugriff mit Partitionsindizes, Pushdown-Prädikaten, Partitionsauflistung und einem aktualisierten Hive-Metastore-Client.

Integration mit Lake Formation für kontrollierte Katalogtabellen mit Filterung auf Zellenebene und Data-Lake-Transaktionen.

Verringerte Startlatenz zur Verbesserung der Gesamtzeiten für die Auftragserfüllung und Interaktivität.

Spark-Aufträge werden in 1-Sekunden-Schritten mit einer zehnmal geringeren Mindestabrechnungsdauer abgerechnet – von mindestens 10 Minuten bis zu mindestens 1 Minute.

Native Unterstützung für Open-Data-Lake-Frameworks mit Apache Hudi, Delta Lake und Apache Iceberg.

Native Unterstützung für das Amazon-S3-basierte Cloud-Shuffle-Speicher-Plugin (ein Apache-Spark-Plugin) zur Verwendung von Amazon S3 für Shuffling und elastische Speicherkapazität.

Laufzeitfilterung auf Zeilenebene (SPARK-32268).

ANSI-Verbesserungen (SPARK-38860).

Verbesserungen der Fehlermeldungen (SPARK-38781).

Unterstützung komplexer Typen für den vektorisierten Parquet-Reader (SPARK-34863).

Unterstützung für versteckte Dateimetadaten für Spark SQL (SPARK-37273).

Stellen Sie einen Profiler für Python/Pandas-UDFs bereit (SPARK-37443).

Führen Sie Trigger.AvailableNow ein, um Streaming-Abfragen wie Trigger.Once in mehreren Batches auszuführen (SPARK-36533).

Umfassendere Datasource-V2-Pushdown-Funktionen (SPARK-38788).

Migration von log4j1 zu log4j2 (SPARK-37814).

Abwärtskompatible Änderungen

Wählen Sie in AWS Glue Studio Glue 4.0 - Supports Spark 3.3, Scala 2, Python 3 in Glue version aus.

Wählen Sie in der API 4.0 im GlueVersion-Parameter in der UpdateJob-API-Operation aus.

Wählen Sie in der Konsole Spark 3.3, Python 3 (Glue Version 4.0) or Spark 3.3, Scala 2 (Glue Version 3.0) in der Glue version aus.

Wählen Sie in AWS Glue Studio Glue 4.0 - Supports Spark 3.3, Scala 2, Python 3 in Glue version aus.

Wählen Sie in der API 4.0 im GlueVersion-Parameter in der CreateJob-API-Operation aus.

Sind die externen Python-Bibliotheken Ihres Auftrags von Python 2.7/3.6 abhängig?

Alle vorhandenen Auftragsparameter und Hauptfeatures, die in AWS Glue 3.0 vorhanden sind, werden auch in AWS Glue 4.0 vorhanden sein.

AWS Glue 3.0 verwendet Amazon-MR-optimiertes Spark 3.1.1 und AWS Glue 4.0 verwendet Amazon-EMR-optimiertes Spark 3.3.0.

Einige Spark-Änderungen allein erfordern möglicherweise eine Überarbeitung Ihrer Skripts, um sicherzustellen, dass auf entfernte Features nicht verwiesen wird.

AWS Glue 4.0 enthält auch eine Aktualisierung für EMRFS und Hadoop. Informationen über die jeweilige Version finden Sie unter Anhang A: Nennenswerte Aktualisierungen von Abhängigkeiten.

Das in ETL-Aufträgen bereitgestellte AWS-SDK wurde jetzt von 1.11 auf 1.12 aktualisiert.

Alle Python-Aufträge werden Python-Version 3.10 verwenden. Zuvor wurde Python 3.7 in AWS Glue 3.0 verwendet.

Infolgedessen werden einige von AWS Glue standardmäßig bereitgestellte Pymodule aktualisiert.

Log4j wurde auf Log4j2 aktualisiert.

Informationen zur Migration bestimmter Konnektoren finden Sie unter Konnektor- und JDBC-Treibermigration für AWS Glue 4.0.

Das AWS-Encryption SDK wurde von 1.x auf 2.x aktualisiert. AWS Glue-Aufträge, die AWS Glue-Sicherheitskonfigurationen verwenden, und Aufträge, die von der in der Laufzeit bereitgestellten AWS-Encryption-SDK-Abhängigkeit abhängig sind, sind davon betroffen. Lesen Sie die Anweisungen zur AWS Glue-Auftragsmigration.

Sie können einen AWS Glue 2.0/3.0-Auftrag auf einen AWS Glue 4.0-Auftrag aktualisieren, da AWS Glue 2.0/3.0 bereits die Bridge-Version des AWS-Encryption-SDK enthält.

Upgrade von Spark SQL 3.1 auf 3.2

Upgrade von Spark SQL 3.2 auf 3.3

Alle vorhandenen Auftragsparameter und Hauptfeatures, die in AWS Glue 2.0 vorhanden sind, werden auch in AWS Glue 4.0 vorhanden sein.

Der S3-optimierte EMRFS-Committer zum Schreiben von Parquet-Daten in Amazon S3 ist seit AWS Glue 3.0 standardmäßig aktiviert. Sie können ihn jedoch nach wie vor deaktivieren, indem Sie --enable-s3-parquet-optimized-committer auf false einstellen.

AWS Glue 2.0 verwendet Open-Source-Spark 2.4 und AWS Glue 4.0 verwendet Amazon-EMR-optimierte Spark 3.3.0.

Das in ETL-Aufträgen bereitgestellte AWS-SDK wurde jetzt von 1.11 auf 1.12 aktualisiert.

AWS Glue 4.0 bietet auch eine Aktualisierung für EMRFS, aktualisierte JDBC-Treiber und zusätzliche Optimierungen auf Spark selbst von AWS Glue.

Scala wurde von 2.11 auf 2.12 aktualisiert und Scala 2.12 ist nicht abwärtskompatibel mit Scala 2.11.

Python 3.10 ist die Standardversion, die für Python-Skripte verwendet wird, da AWS Glue 2.0 nur Python 3.7 und 2.7 verwendet hat.

Mehrere Abhängigkeitsaktualisierungen, hervorgehoben in Anhang A: Nennenswerte Aktualisierungen von Abhängigkeiten.

Alle zusätzlichen JAR-Dateien, die in vorhandenen AWS Glue 2.0-Aufträgen vorhanden sind, können zu widersprüchlichen Abhängigkeiten führen, da Upgrades bei mehreren Abhängigkeiten in 4.0 von 2.0 vorgenommen wurden. Sie können Klassenpfadkonflikte in AWS Glue 4.0 mit dem --user-jars-first-Auftragsparameter AWS Glue vermeiden.

AWS Glue 4.0 verwendet Spark 3.3. Ab Spark 3.1 gab es eine Änderung im Verhalten beim Laden/Speichern von Zeitstempeln aus/in Parquet-Dateien. Weitere Informationen finden Sie unter Upgrade von Spark SQL 3.0 auf 3.1.

Wir empfehlen, beim Lesen/Schreiben von Parquet-Daten, die Zeitstempelspalten enthalten, die folgenden Parameter einzustellen. Das Festlegen dieser Parameter kann das Problem mit der Kalenderinkompatibilität, das während des Upgrades von Spark 2 auf Spark 3 auftritt, sowohl für den AWS Glue Dynamic Frame als auch den Spark Data Frame beheben. Verwenden Sie die Option CORRECTED, um den Datetime-Wert so zu lesen, wie er ist, und die LEGACY-Option, um die Datetime-Werte im Hinblick auf die Kalenderdifferenz während des Lesens neu zu basieren.

- Key: --conf
- Value: spark.sql.legacy.parquet.int96RebaseModeInRead=[CORRECTED|LEGACY] --conf spark.sql.legacy.parquet.int96RebaseModeInWrite=[CORRECTED|LEGACY] --conf spark.sql.legacy.parquet.datetimeRebaseModeInRead=[CORRECTED|LEGACY]

Informationen zur Migration bestimmter Konnektoren finden Sie unter Konnektor- und JDBC-Treibermigration für AWS Glue 4.0.

Das AWS-Encryption-SDK wurde von 1.x auf 2.x aktualisiert. AWS Glue-Aufträge, die AWS Glue-Sicherheitskonfigurationen verwenden, und Aufträge, die von der in der Laufzeit bereitgestellten AWS-Encryption-SDK-Abhängigkeit abhängig sind, sind davon betroffen. Lesen Sie diese Anleitung für die Migration von AWS Glue-Aufträgen:

Upgrade von Spark SQL 2.4 auf 3.0

Upgrade von Spark SQL 3.1 auf 3.2

Upgrade von Spark SQL 3.2 auf 3.3

Änderungen im Datetime-Verhalten sind ab Spark 3.0 zu erwarten.

AWS Glue 1.0 verwendet Open-Source-Spark 2.4 und AWS Glue 4.0 verwendet Amazon-EMR-optimiertes Spark 3.3.0.

Alle Aufträge in AWS Glue 4.0 werden mit deutlich verbesserten Startzeiten ausgeführt. Spark-Aufträge werden in 1-Sekunden-Schritten mit einer 10-fach niedrigeren Mindestabrechnungsdauer in Rechnung gestellt, da die Startlatenz von maximal 10 Minuten zu maximal 1 Minute reicht.

Das Protokollierungsverhalten hat sich in AWS Glue 4.0 erheblich geändert. Spark 3.3.0 hat eine Mindestanforderung von Log4j2.

Mehrere Abhängigkeitsaktualisierungen, hervorgehoben im Anhang.

Scala wurde von 2.11 auf 2.12 aktualisiert und Scala 2.12 ist nicht abwärtskompatibel mit Scala 2.11.

Python 3.10 ist auch die Standardversion für Python-Skripte, da AWS Glue 0.9 nur Python 2 verwendet hat.

Python 2.7 wird mit Spark 3.3.0 nicht unterstützt. Jeder Auftrag, der Python 2 in der Auftragskonfiguration anfordert, schlägt mit einer IllegalArgumentException fehl.

Ein neuer Mechanismus zum Installieren zusätzlicher Python-Module über pip ist seit AWS Glue 2.0 verfügbar. Weitere Informationen finden Sie unter Installieren zusätzlicher Python-Module mit Pip in AWS Glue 2.0+.

AWS Glue 4.0 wird nicht auf Apache YARN ausgeführt, daher gelten die YARN-Einstellungen nicht.

AWS Glue 4.0 verfügt über kein Hadoop Distributed File System (HDFS).

Alle zusätzlichen JAR-Dateien, die in vorhandenen AWS Glue 1.0-Aufträgen vorhanden sind, können zu widersprüchlichen Abhängigkeiten führen, da Upgrades bei mehreren Abhängigkeiten in 4.0 von 1.0 vorgenommen wurden. Wir aktivieren AWS Glue 4.0 standardmäßig mit dem --user-jars-first AWS Glue-Auftragsparameter, um dieses Problem zu vermeiden.

AWS Glue 4.0 unterstützt jetzt Auto Scaling. Daher ist die ExecutorAllocationManager-Metrik verfügbar, wenn Auto Scaling aktiviert ist.

Für Aufträge von AWS Glue-Version 4.0 geben Sie die Anzahl der Worker und den Worker-Typ an. Sie geben jedoch keinen maxCapacity an.

AWS Glue 4.0 unterstützt Machine-Learning-Transformationen noch nicht.

Informationen zur Migration bestimmter Konnektoren finden Sie unter Konnektor- und JDBC-Treibermigration für AWS Glue 4.0.

Das AWS-Encryption-SDK wurde von 1.x auf 2.x aktualisiert. AWS Glue-Aufträge, die AWS Glue-Sicherheitskonfigurationen verwenden, und Aufträge, die von der in der Laufzeit bereitgestellten AWS-Encryption-SDK-Abhängigkeit abhängig sind, sind davon betroffen. Lesen Sie diese Anleitung für die Migration von AWS Glue-Aufträgen.

Upgrade von Spark SQL 2.4 auf 3.0

Upgrade von Spark SQL 3.0 auf 3.1

Upgrade von Spark SQL 3.1 auf 3.2

Upgrade von Spark SQL 3.2 auf 3.3

Änderungen im Datetime-Verhalten sind ab Spark 3.0 zu erwarten.

AWS Glue 0.9 verwendet Open-Source-Spark 2.2.1 und AWS Glue 4.0 verwendet Amazon-EMR-optimiertes Spark 3.3.0.

Alle Aufträge in AWS Glue 4.0 werden mit deutlich verbesserten Startzeiten ausgeführt. Spark-Aufträge werden in 1-Sekunden-Schritten mit einer 10-mal geringeren Mindestabrechnungsdauer abgerechnet, da die Startlatenz von maximal 10 Minuten auf maximal 1 Minute sinkt.

Das Protokollierungsverhalten hat sich seit AWS Glue 4.0 erheblich geändert, Spark 3.3.0 hat eine Mindestanforderung von Log4j2, wie hier erwähnt (https://spark.apache.org/docs/latest/core-migration-guide.html#upgrading-from-core- 32 bis 33).

Mehrere Abhängigkeitsaktualisierungen, hervorgehoben im Anhang.

Scala wurde von 2.11 auf 2.12 aktualisiert und Scala 2.12 ist nicht abwärtskompatibel mit Scala 2.11.

Python 3.10 ist auch die Standardversion für Python-Skripte, da AWS Glue 0.9 nur Python 2 verwendet hat.

AWS Glue 4.0 wird nicht auf Apache YARN ausgeführt, daher gelten die YARN-Einstellungen nicht.

AWS Glue 4.0 verfügt über kein Hadoop Distributed File System (HDFS).

Alle zusätzlichen JAR-Dateien, die in vorhandenen AWS Glue 0.9-Aufträgen vorhanden sind, können zu widersprüchlichen Abhängigkeiten führen, da Upgrades bei mehreren Abhängigkeiten in 3.0 von 0.9 vorgenommen wurden. Sie können Klassenpfadkonflikte in AWS Glue 3.0 mit dem AWS Glue-Auftragsparameter --user-jars-first vermeiden.

AWS Glue 4.0 unterstützt jetzt Auto Scaling. Daher ist die ExecutorAllocationManager-Metrik verfügbar, wenn Auto Scaling aktiviert ist.

Für Aufträge von AWS Glue-Version 4.0 geben Sie die Anzahl der Worker und den Worker-Typ an. Sie geben jedoch keinen maxCapacity an.

AWS Glue 4.0 unterstützt Machine-Learning-Transformationen noch nicht.

Informationen zur Migration bestimmter Konnektoren finden Sie unter Konnektor- und JDBC-Treibermigration für AWS Glue 4.0.

Das AWS-Encryption-SDK wurde von 1.x auf 2.x aktualisiert. AWS Glue-Aufträge, die AWS Glue-Sicherheitskonfigurationen verwenden, und Aufträge, die von der in der Laufzeit bereitgestellten AWS-Encryption-SDK-Abhängigkeit abhängig sind, sind davon betroffen. Lesen Sie diese Anleitung für die Migration von AWS Glue-Aufträgen.

Upgrade von Spark SQL 2.2 auf 2.3

Upgrade von Spark SQL 2.3 auf 2.4

Upgrade von Spark SQL 2.4 auf 3.0

Upgrade von Spark SQL 3.0 auf 3.1

Upgrade von Spark SQL 3.1 auf 3.2

Upgrade von Spark SQL 3.2 auf 3.3

Änderungen im Datetime-Verhalten sind ab Spark 3.0 zu erwarten.

Anhang B: Aktualisierungen von JDBC-Treibern

Anhang C: Konnektor-Upgrades

Verbesserungen der Spark-SQL-Unterstützung:

Jede Hudi-Tabelle, die vor Version 0.10.0 ohne ein primaryKey erstellt wurde, muss seit Version 0.10.0 mit einem primaryKey-Feld neu erstellt werden.

Verschiedene Sicherheitslücken (CVEs) wurden behoben.

Java 8 wird nativ unterstützt.

Wenn der Auftrag mit Ausnahme von Byte-Arrays Arrays von Arrays verwendet, kann dieses Szenario als mehrdimensionale Arrays behandelt werden.

Der aktuelle MongoDB-Konnektor unterstützt Spark-Version 3.1 oder höher und MongoDB-Version 4.0 oder höher.

Aufgrund des Konnektor-Upgrades haben sich einige Eigenschaftsnamen geändert. Beispielsweise wurde der URI-Eigenschaftsname in connection.uri geändert. Weitere Informationen zu den aktuellen Optionen finden Sie im Blog zu MongoDB-Spark-Konnektor.

Die Verwendung von MongoDB 4.0, das von Amazon DocumentDB gehostet wird, weist einige funktionale Unterschiede auf. Weitere Informationen enthalten die folgenden Themen:

Die Option „Partitionierer“ ist auf ShardedPartitioner, PaginateIntoPartitionsPartitioner, und SinglePartitionPartitioner beschränkt. Es kann die Standardwerte SamplePartitioner und PaginateBySizePartitioner für Amazon DocumentDB nicht verwenden, da der Stage-Operator die MongoDB-API nicht unterstützt. Weitere Informationen finden Sie unter Unterstützte MongoDB-APIs, Operationen und Datentypen.

Delta Lake unterstützt jetzt Zeitreisen in SQL zum einfachen Abfragen älterer Daten. Mit diesem Aktualisierungen sind Zeitreisen jetzt sowohl in Spark SQL als auch über die DataFrame-API verfügbar. Für die aktuelle Version von TIMESTAMP in SQL wurde Unterstützung hinzugefügt.

Spark 3.3 führt Trigger.AvailableNow zum Ausführen von Streaming-Abfragen als Äquivalent zu Trigger.Once für Batch-Abfragen ein. Diese Unterstützung ist auch bei Verwendung von Delta-Tabellen als Streaming-Quelle verfügbar.

Unterstützung für SHOW COLUMNS, um die Liste der Spalten in einer Tabelle zurückzugeben.

Unterstützung für DESCRIBE DETAIL in der Scala- und Python-DeltaTable-API. Es ruft detaillierte Informationen über eine Delta-Tabelle ab, die entweder die DeltaTable-API oder Spark SQL verwendet.

Unterstützung für die Rückgabe von Vorgangsmetriken aus SQL-Befehlen zum Löschen, Zusammenführen und Aktualisieren. Zuvor gaben diese SQL-Befehle einen leeren DataFrame zurück, jetzt geben sie einen DataFrame mit nützlichen Metriken über die durchgeführte Operation zurück.

Leistungsverbesserungen optimieren:

Weitere nennenswerte Änderungen:

Es wurden mehrere Leistungsverbesserungen für die Scan-Planung und Spark-Abfragen hinzugefügt.

Es wurde ein allgemeiner REST-Katalog-Client hinzugefügt, der änderungsbasierte Commits verwendet, um Commit-Konflikte innerhalb des Services zu lösen.

AS OF-Syntax für SQL-Zeitreiseabfragen wird unterstützt.

Es wurde Merge-on-Read-Unterstützung für MERGE- und UPDATE-Abfragen hinzugefügt.

Es wurde Unterstützung zum Neuschreiben von Partitionen mit Z-Reihenfolge hinzugefügt.

Es wurde eine Spezifikation und Implementierung für Puffin hinzugefügt, ein Format für große Statistik- und Index-Blobs, wie Theta-Skizzen oder Bloom-Filter.

Es wurden neue Schnittstellen für die inkrementelle Nutzung von Daten hinzugefügt (sowohl Append- als auch Changelog-Scans).

Es wurde Unterstützung für Massenvorgänge und Bereichslesevorgänge für FileIO-Schnittstellen hinzugefügt.

Es wurden weitere Metadaten-Tabellen hinzugefügt, um gelöschte Dateien in der Metadaten-Struktur anzuzeigen.

Das Verhalten der Ablagetabelle hat sich geändert. In Iceberg 0.13.1 entfernt das Ausführen von DROP TABLE die Tabelle aus dem Katalog und löscht auch den Tabelleninhalt. In Iceberg 1.0.0 entfernt DROP TABLE nur die Tabelle aus dem Katalog. Um den Tabelleninhalt zu löschen, verwenden Sie DROP TABLE PURGE.

In Iceberg 1.0.0 sind vektorisierte Parquet-Lesevorgänge standardmäßig aktiviert. Wenn Sie vektorisierte Lesevorgänge deaktivieren möchten, setzen Sie read.parquet.vectorization.enabled auf false.