Warum schlägt mein AWS-Glue-ETL-Auftrag mit der Fehlermeldung „Container killed by YARN for exceeding memory limits“ fehl?

Kurzbeschreibung

Im Folgenden sind die häufigsten Ursachen für diesen Fehler aufgeführt:

• Speicherintensive Vorgänge, die den Speicherschwellenwert des zugrunde liegenden Apache-Spark-Clusters überschreiten. Diese Vorgänge können beispielsweise beim Zusammenführen großer Tabellen oder bei der Verarbeitung von Datensätzen mit einer ungleichen Verteilung auftreten.
• FAT-Datenpartitionen, die mehr Speicher verbrauchen als dem jeweiligen Executor zugewiesen ist.
• Große Dateien, die du nicht teilen kannst und die zu großen In-Memory-Partitionen führen.

Lösung

Führe eine oder mehrere der folgenden Lösungen aus, um diesen Fehler zu beheben.

Worker-Typ aktualisieren

Da G.2x über höhere Speicherkonfigurationen verfügt, aktualisiere den Worker-Typ. Du kannst den Worker-Typ von G.1x auf die folgenden Worker-Typen aktualisieren:

• G.2x
• G.4x
• G.8x
• G.12x
• G.16x
• R.1x
• R.2x
• R.4x
• R.8x

Weitere Informationen zu den Spezifikationen der Worker-Typen findest du unter Definieren von Auftragseigenschaften für Spark-Aufträge und AWS-Glue-Versionen.

Anzahl der Executoren für den Auftrag erhöhen

Wenn der Fehler nach dem Upgrade des Worker-Typs weiterhin besteht, erhöhe die Anzahl der Executoren für den Auftrag. Für jeden Executor gibt es eine bestimmte Anzahl von Kernen. Diese Zahl bestimmt die Anzahl der Partitionen, die der Executor verarbeiten kann. Der Worker-Typ definiert die Spark-Konfigurationen für die Data Processing Units (DPUs, Datenverarbeitungseinheiten).

Daten aktualisieren

Stelle sicher, dass deine Daten parallel sind, um sicherzustellen, dass AWS Glue vor einem Shuffle-Vorgang, z B. Joins, gleichmäßig die Executoren verwendet. Um Daten auf allen Executoren neu zu partitionieren, füge einen der folgenden Befehle in den ETL-Auftrag ein.

Füge für DynamicFrame den folgenden Befehl ein:

dynamicFrame.repartition(totalNumberOfExecutorCores)

Füge für DataFrame den folgenden Befehl ein:

dataframe.repartition(totalNumberOfExecutorCores)

Auftrags-Lesezeichen verwenden

Wenn du Auftrags-Lesezeichen verwendest, verarbeitet der AWS-Glue-Auftrag nur die neu geschriebenen Dateien. Diese Konfiguration reduziert die Anzahl der Dateien, die der AWS-Glue-Auftrag verarbeitet, und Speicherprobleme. Lesezeichen speichern die Metadaten aus verarbeiteten Dateien aus der vorherigen Ausführung. In den nachfolgenden Ausführungen vergleicht der Auftrag den Zeitstempel und entscheidet dann, ob diese Dateien erneut verarbeitet werden sollen. Weitere Informationen findest du unter Verfolgen verarbeiteter Daten mithilfe von Auftrags-Lesezeichen.

DynamicFrame verwenden, um Daten parallel zu lesen

Wenn eine Verbindung zu einer JDBC-Tabelle hergestellt wird, öffnet Spark standardmäßig nur eine gleichzeitige Verbindung. Der Treiber versucht, die gesamte Tabelle auf einmal in einem einzigen Spark-Executor herunterzuladen. Dieser Download kann länger dauern und kann zu Out-of-Memory (OOM)-Fehlern für den Executor führen. Konfiguriere stattdessen bestimmte Eigenschaften der JDBC-Tabelle, um AWS Glue anzuweisen, DynamicFrame zum parallelen Lesen von Daten zu verwenden. Oder du kannst Spark DataFrame verwenden, um parallele Lesevorgänge von JDBC zu erreichen. Weitere Informationen findest du unter JDBC to other databases (JDBC zu anderen Datenbanken) auf der Spark-Website.

Leistungsfähige Funktionen im ETL-Auftrag verwenden

Verwende für den ETL-Auftrag keine benutzerdefinierten Funktionen, insbesondere wenn du Python- oder Scala-Code mit den Funktionen und Methoden von Spark kombinierst. Verwende beispielsweise nicht den Spark df.count(), um leere DataFrames in if/else-Anweisungen oder für Schleifen zu verifizieren. Verwende stattdessen leistungsfähigere Funktionen wie df.schema() oder df.rdd.isEmpty().

Den AWS-Glue-Auftrag testen und optimieren

Bevor du den AWS-Glue-Auftrag in der Produktion ausführst, teste den AWS-Glue-Auftrag in einer interaktiven Sitzung und optimiere den ETL-Code.

Wenn keine der vorherigen Lösungsoptionen funktioniert, teile die Eingabedaten in Blöcke oder Partitionen auf. Führe dann mehrere AWS-Glue-ETL-Aufträge aus, anstatt einen einzelnen großen Auftrag auszuführen. Weitere Informationen findest du unter Workload-Partitionierung mit begrenzter Ausführung.

Ähnliche Informationen

Debuggen von OOM-Ausnahmen und Auftragsanomalien

Bewährte Methoden zur Skalierung von Spark-Aufträgen und Partitionierung von Daten mit AWS Glue

Optimieren der Speicherverwaltung in AWS Glue