Warum schlägt mein AWS Glue ETL-Auftrag mit der Fehlermeldung "Container wird von YARN wegen Überschreitung der Speichergrenzen beendet" fehl?

Lesedauer: 4 Minute
0

Mein AWS Glue-Job zum Extrahieren, Transformieren und Laden (ETL) schlägt mit dem Fehler „Container wurde von YARN wegen Überschreitung der Speicherlimits getötet“ fehl.

Kurzbeschreibung

Die häufigsten Ursachen für diesen Fehler sind die folgenden:

  • Speicherintensive Operationen, wie das Verbinden großer Tabellen oder das Verarbeiten von Datensätzen mit einer schiefen Verteilung bestimmter Spaltenwerte, wodurch der Speicherschwellenwert des zugrunde liegenden Spark-Clusters überschritten wird
  • Dicke Datenpartitionen, die mehr als den Speicher verbrauchen, der dem jeweiligen Executor zugewiesen ist
  • Große Dateien, die nicht aufgeteilt werden können, was zu großen In-Memory-Partitionen führt

Behebung

Verwenden Sie eine oder mehrere der folgenden Lösungsoptionen, um diesen Fehler zu beheben:

  • Aktualisieren Sie den Worker-Typ von G.1x auf G.2x mit höheren Speicherkonfigurationen. Weitere Informationen zu den Spezifikationen von Arbeitertypen finden Sie im **Abschnitt **Worker-Typ unter Definieren von Jobeigenschaften für Spark-Jobs.
  • Weitere Informationen zur Migration von AWS Glue 2.0 zu 3.0 finden Sie unter Migration von AWS Glue 2.0 zu AWS Glue 3.0.
  • In der folgenden Tabelle finden Sie auch Informationen zu den Spezifikationen für Arbeitsertypen:
AWS Glue-Versionen 1.0 und 2.0
Standardisierungspark.executor.memory: 5g spark.driver.memory: 5g spark.executor.cores: 4
G.1xspark.executor.memory: 10g spark.driver.memory: 10g spark.executor.cores: 8
G.2xspark.executor.memory: 20g spark.driver.memory: 20g spark.executor.cores: 16
AWS Glue, Version 3.0
Standardisierungspark.executor.memory: 5g spark.driver.memory: 5g spark.executor.cores: 4
G.1xspark.executor.memory: 10g spark.driver.memory: 10g spark.executor.cores: 4
G.2xspark.executor.memory: 20g spark.driver.memory: 20g spark.executor.cores: 8
  • Wenn der Fehler nach dem Upgrade des Worker-Typs weiterhin besteht, erhöhen Sie die Anzahl der Executoren für den Job. Jeder Executor hat eine bestimmte Anzahl von Kernen. Diese Zahl bestimmt die Anzahl der Partitionen, die vom Executor verarbeitet werden können. Spark-Konfigurationen für die Datenverarbeitungseinheiten (DPUs) werden auf der Grundlage des Worker-Typs definiert.
  • Stellen Sie sicher, dass die Daten ordnungsgemäß parallelisiert sind, sodass die Executoren gleichmäßig verwendet werden können, bevor ein Shuffle-Vorgang, z. B. Joins, durchgeführt wird. Sie können die Daten auf alle Executoren verteilen. Sie können dies tun, indem Sie die folgenden Befehle für AWS Glue DynamicFrame bzw. Spark DataFrame in Ihren ETL-Job aufnehmen.
dynamicFrame.repartition(totalNumberOfExecutorCores)

dataframe.repartition(totalNumberOfExecutorCores)
  • Durch die Verwendung von Job-Lesezeichen können nur die neu geschriebenen Dateien vom AWS Glue-Job verarbeitet werden. Dadurch wird die Anzahl der vom AWS Glue-Job verarbeiteten Dateien reduziert und Speicherprobleme vermieden. Lesezeichen speichern die Metadaten über die Dateien, die im vorherigen Lauf verarbeitet wurden. In der nachfolgenden Ausführung vergleicht der Job den Zeitstempel und entscheidet dann, ob diese Dateien erneut verarbeitet werden sollen. Weitere Informationen finden Sie unter Verfolgen verarbeiteter Daten mithilfe von Job-Lesezeichen.
  • 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. Dies kann länger dauern und sogar zu Speicherfehlern für den Executor führen. Stattdessen können Sie bestimmte Eigenschaften Ihrer JDBC-Tabelle festlegen, um AWS Glue anzuweisen, Daten parallel über DynamicFrame zu lesen. Weitere Informationen finden Sie unter Paralleles Lesen aus JDBC-Tabellen. Oder Sie können parallele Lesevorgänge von JDBC über Spark DataFrame erreichen. Weitere Informationen finden Sie unter Parallel Reads von Spark DataFrame aus JDBC und überprüfen Sie Eigenschaften wie PartitionColumn, LowerBound, UpperBound und NumPartitions.
  • Vermeiden Sie die Verwendung benutzerdefinierter Funktionen in Ihrem ETL-Job, insbesondere wenn Sie Python-/Scala-Code mit den Funktionen und Methoden von Spark kombinieren. Vermeiden Sie beispielsweise die Verwendung von df.count() von Spark zur Überprüfung leerer DataFrames in if/else-Anweisungen oder für Schleifen. Verwenden Sie stattdessen leistungsfähigere Funktionen wie **df.schema() ** oder df.rdd.isEmpty().
  • Testen Sie den AWS Glue-Job auf einem Entwicklungsendpunktund optimieren Sie den ETL-Code entsprechend.
  • Wenn keine der vorherigen Lösungsoptionen funktioniert, teilen Sie die Eingabedaten in Blöcke oder Partitionen auf. Führen Sie dann mehrere AWS Glue ETL-Jobs aus, anstatt einen großen Job auszuführen. Weitere Informationen finden Sie unter Workload-Partitionierung mit begrenzter Ausführung.

Ähnliche Informationen

Debuggen von OOM-Ausnahmen und Jobanomalien

Bewährte Methoden zur Skalierung von Apache Spark-Jobs und Partitionierung von Daten mit AWS Glue

Optimieren der Speicherverwaltung in AWS Glue

AWS OFFICIAL
AWS OFFICIALAktualisiert vor 2 Jahren