Warum ist mein Spark-Auftrag in Amazon EMR fehlgeschlagen?

Lösung

Anwendungsfehler

FEHLER ShuffleBlockFetcherIterator: Blöcke konnten nicht von ip-192-168-14-250.us-east-2.compute.internal:7337 abgerufen werden

org.apache.spark.network.client.ChunkFetchFailureException: Fehler beim Abrufen von StreamChunkid[streamID=842490577174,chunkIndex=0]: java.lang.RuntimeException: Ausführer ist nicht registriert (appid=Application_1622819239076_0367, execid=661)

Dieses Problem kann auftreten, wenn sich der Ausführer-Worker-Knoten in Amazon EMR in einem fehlerhaften Zustand befindet. Wenn die Festplattenauslastung für einen Worker-Knoten den Auslastungsschwellenwert von 90 % überschreitet, meldet der YARN **NodeManager-**Health-Service den Knoten als FEHLERHAFT. Fehlerhafte Knoten sind in den Ablehnungslisten von Amazon EMR enthalten. Darüber hinaus werden YARN-Container diesen Knoten nicht zugewiesen.

Gehen Sie wie folgt vor, um dieses Problem zu beheben:

• Überprüfen Sie die Ressourcen-Manager-Protokolle des EMR-Cluster-Hauptknotens auf fehlerhafte Worker-Knoten. Weitere Informationen finden Sie unter Wie behebe ich die „Slave lost“-Fehler von ExecutorLostFailure in Spark auf Amazon EMR? und überprüfen Sie den Abschnitt Hohe Festplattenauslastung.
• Überprüfen Sie die Festplattenspeicherauslastung des betroffenen Knotens, überprüfen Sie Dateien, die Festplattenspeicher verbrauchen, und führen Sie eine Datenwiederherstellung durch, um die Knoten wieder in einen fehlerfreien Zustand zu versetzen. Weitere Informationen finden Sie unter Warum geht der Speicherplatz des Core-Knotens in meinem Amazon-EMR-Cluster zur Neige?

FEHLER [Executor Task Launch Worker für Aufgabe 631836] o.a.s.e.Executor:Executor:Exception in Aufgabe 24.0 in Phase 13028.0 (TID 631836) java.util.NoSuchElementException: None.get

Dieser Fehler tritt auf, wenn ein Problem im Anwendungscode und bei der SparkContext-Initialisierung auftritt.

Stellen Sie sicher, dass in derselben Sitzung nicht mehrere SparkContext-Aufträge aktiv sind. Laut der Java Virtual Machine (JVM) können Sie jeweils einen aktiven SparkContext haben. Wenn Sie einen anderen SparkContext initialisieren möchten, müssen Sie den aktiven Auftrag beenden, bevor Sie einen neuen erstellen.

Container auf Anfrage getötet. Exit-Code ist 137

Diese Ausnahme tritt auf, wenn eine Aufgabe in einem YARN-Container den für diesen Container zugewiesenen physischen Speicher überschreitet. Dies ist häufig der Fall, wenn Sie Shuffle-Partitionen, inkonsistente Partitionsgrößen oder eine große Anzahl von Ausführer-Kernen haben.

Überprüfen Sie die Fehlerdetails in den Spark-Treiberprotokollen, um die Ursache des Fehlers zu ermitteln. Weitere Informationen finden Sie unter Wie kann ich auf Spark-Treiberprotokolle auf einem Amazon-EMR-Cluster zugreifen?

Im Folgenden finden Sie ein Beispiel für einen Fehler aus dem Treiberprotokoll:

ERROR YarnScheduler: Lost executor 19 on ip-10-109-xx-xxx.aws.com : Container from a bad node: container_1658329343444_0018_01_000020 on host: ip-10-109-xx-xxx.aws.com . Exit status: 137.Diagnostics:
Container killed on request. Exit code is 137
Container exited with a non-zero exit code 137.
Killed by external signal
Executor container 'container_1658329343444_0018_01_000020' was killed with exit code 137. To understand the root cause, you can analyze executor container log.
# java.lang.OutOfMemoryError: Java heap space
# -XX:OnOutOfMemoryError="kill -9 %p"
# Executing /bin/sh -c "kill -9 23573"...

Der vorherige Fehler-Stack-Trace weist darauf hin, dass auf dem Ausführer nicht genügend Speicher verfügbar ist, um die Verarbeitung der Daten fortzusetzen. Dieser Fehler kann in verschiedenen Auftragsphasen sowohl bei engen als auch bei umfassenden Transformationen auftreten.

Führen Sie einen der folgenden Schritte aus, um dieses Problem zu beheben:

• Erhöhen Sie den Arbeitsspeicher des Ausführers.
  Hinweis: Der Ausführer-Speicher umfasst den für die Ausführung der Aufgaben erforderlichen Speicher sowie den Overhead-Speicher. Die Summe dieser Werte darf nicht größer sein als die Größe von JVM und die maximale YARN-Containergröße.
• Fügen Sie weitere Spark-Partitionen hinzu.
• Erhöhen Sie die Anzahl der Shuffle-Partitionen.
• Reduzieren Sie die Anzahl der Ausführer-Kerne.

Weitere Informationen finden Sie unter Wie behebe ich das Problem „Container wurde auf Anfrage getötet“. Exit-Code ist 137" Fehler in Spark auf Amazon EMR?

Spark-Aufträge sind unbesetzt und werden nicht abgeschlossen

Spark-Aufträge könnten aus mehreren Gründen feststecken. Zum Beispiel, wenn der Spark-Treiberprozess (Anwendungsmaster) betroffen ist oder Ausführer-Container verloren gehen.

Dies ist häufig der Fall, wenn Sie eine hohe Festplattenspeicherauslastung haben oder wenn Sie Spot-Instances für Clusterknoten verwenden und die Spot-Instance beendet wird. Weiter Informationen finden Sie unter Wie behebe ich den „Slave lost“-Fehler von ExecutorLostFailure in Spark auf Amazon EMR?

Gehen Sie wie folgt vor, um dieses Problem zu beheben:

• Überprüfen Sie die Master- oder Treiberprotokolle der Spark-Anwendung auf etwaige Ausnahmen.
• Überprüfen Sie die YARN-Knotenliste auf fehlerhafte Knoten. Wenn die Festplattenauslastung für einen Kernknoten den Auslastungsschwellenwert überschreitet, meldet der YARN-Node-Manager-Health-Service den Knoten als FEHLERHAFT. Fehlerhafte Knoten sind in den Ablehnungslisten von Amazon EMR enthalten. Darüber hinaus werden YARN-Container diesen Knoten nicht zugewiesen.
• Überwachen Sie die Festplattenspeicherauslastung und konfigurieren Sie Amazon-Elastic-Block-Store-Volumes (Amazon EBS), um die Auslastung für EMR-Cluster-Worker-Knoten unter 90 % zu halten.

WARNUNG Ausführer: Problem bei der Kommunikation mit dem Treiber in Heartbeater org.apache.spark.rpc.rpcTimeoutException: Futures haben nach [10000 Millisekunden] ein Timeout erreicht. Dieses Timeout wird von spark.executor.heartbeatInterval gesteuert

Spark-Ausführer senden in Intervallen, die durch die Eigenschaft spark.executor.heartbeatInterval angegeben sind, Heartbeat-Signale an den Spark-Treiber. Während langer Pausen für die Speicherbereinigung sendet der Ausführer möglicherweise kein Heartbeat-Signal. Der Treiber beendet Ausführer, die bei mehr als dem angegebenen Wert kein Heartbeat-Signal senden.

TimeoutException

Timeout-Ausnahmen treten auf, wenn der Ausführer unter Speichermangel steht oder bei der Verarbeitung von Daten OOM-Probleme auftreten. Dies wirkt sich auch auf den Garbage-Collection-Prozess aus und führt zu weiteren Verzögerungen.

Verwenden Sie eine der folgenden Methoden, um Heartbeat-Timeout-Fehler zu beheben:

• Erhöhen Sie den Arbeitsspeicher des Ausführers. Je nach Bewerbungsprozess müssen Sie außerdem Ihre Daten neu partitionieren.
• Garbage Collection optimieren.
• Erhöhen Sie das Intervall für spark.executor.HeartBeatInterval.
• Geben Sie einen längeren Zeitraum für spark.network.timeout an.

ExecutorLostFailure „Exit-Status: -100. Diagnose: Container auf einem *Lost*-Knoten veröffentlicht

Dieser Fehler tritt auf, wenn ein Kern- oder Taskknoten aufgrund einer hohen Festplattenspeicherauslastung beendet wird. Der Fehler tritt auch auf, wenn ein Knoten aufgrund einer längeren hohen CPU-Auslastung oder zu geringem verfügbarem Speicher nicht mehr reagiert. Schritte zur Fehlerbehebung finden Sie unter Wie kann ich den Fehler „Ausgangsstatus:-100 beheben. Diagnose: Container auf einem *lost-Knoten freigegeben“ in Amazon EMR lösen?

Hinweis: Dieser Fehler kann auch auftreten, wenn Sie Spot-Instances für Clusterknoten verwenden und eine Spot-Instance beendet wird. In diesem Szenario stellt der EMR-Cluster eine On-Demand-Instance bereit, um die terminierte Spot-Instance zu ersetzen. Dies bedeutet, dass sich die Anwendung möglicherweise von selbst erholt. Weitere Informationen finden Sie unter Spark-Verbesserungen für Elastizität und Resilienz auf Amazon EMR.

Ausführer 38: java.sql.SqlException (Netzwerkfehler IOException: Zeitlimit für Verbindung überschritten (Zeitlimit für Verbindung überschritten)

Dieses Problem bezieht sich auf die Kommunikation mit der SQL-Datenbank zum Herstellen der Socket-Verbindung beim Lesen oder Schreiben von Daten. Stellen Sie sicher, dass der DB-Host eingehende Verbindungen auf Port 1433 von Ihren EMR-Cluster-Sicherheitsgruppen empfangen kann.

Überprüfen Sie außerdem die maximale Anzahl paralleler Datenbankverbindungen, die für die SQL-DB konfiguriert sind, und die Speicherzuweisung für die DB-Instance-Klasse. Datenbankverbindungen verbrauchen auch Speicher. Wenn die Auslastung hoch ist, überprüfen Sie die Datenbankkonfiguration und die Anzahl der zulässigen Verbindungen. Weitere Informationen finden Sie unter Maximale Anzahl von Datenbankverbindungen.

Amazon-S3-Ausnahmen

HTTP 503 „Verlangsamen“

HTTP-503-Ausnahmen treten auf, wenn Sie die Amazon-Simple-Storage-Service-Anforderungsrate (Amazon S3) für das Präfix überschreiten. Eine 503-Ausnahme bedeutet nicht immer, dass ein Fehler auftritt. Durch die Minderung des Problems kann jedoch die Leistung Ihrer Anwendung verbessert werden.

Weiter Informationen finden Sie unter Warum schlägt mein Spark- oder Hive-Auftrag in Amazon EMR mit einer AmazonS3Exception-Meldung vom Typ HTTP 503 „Verlangsamen“ fehl?

HTTP 403 „Zugriff verweigert“

HTTP-403-Fehler werden durch falsche oder nicht gültige Anmeldeinformationen verursacht, wie zum Beispiel:

• Anmeldeinformationen oder Rollen, die in Ihrem Anwendungscode angegeben sind.
• Die Richtlinie, die an die Amazon-EC2-Instance-Profilrolle angehängt ist.
• Amazon-Virtual-Private-Cloud-Endpunkte (Amazon VPC) für Amazon S3.
• S3-Quellen- und Ziel-Bucket-Richtlinien.

Um 403-Fehler zu beheben, stellen Sie sicher, dass die entsprechende AWS-Identity-and-Access-Management-Rolle (IAM) oder -Richtlinie den Zugriff auf Amazon S3 ermöglicht. Weitere Informationen finden Sie unter Warum schlägt meine Amazon-EMR-Anwendung mit einer HTTP-403-AmazonS3Exception „Zugriff verweigert“ fehl?

HTTP 404 „Nicht gefunden“

HTTP-404-Fehler weisen darauf hin, dass die Anwendung erwartet hat, ein Objekt in S3 zu finden, das Objekt zum Zeitpunkt der Anfrage jedoch nicht gefunden wurde. Zu den häufigsten Ursachen gehören:

• Falsche S3-Pfade (z. B. ein falsch eingegebener Pfad).
• Die Datei wurde durch einen Prozess außerhalb der Anwendung verschoben oder gelöscht.
• Ein Vorgang, der letztendlich zu Konsistenzproblemen führte, z. B. zu einem Überschreiben.

Weitere Informationen finden Sie unter Warum schlägt meine Amazon-EMR-Anwendung mit einer AmazonS3Exception vom Typ HTTP 404 „Nicht gefunden“ fehl?

---