Pourquoi ma tâche Spark dans Amazon EMR a-t-elle échoué ?

Lecture de 8 minute(s)
0

Ma tâche Apache Spark dans Amazon EMR a échoué.

Solution

Échecs d'applications

ERROR ShuffleBlockFetcherIterator: Failed to get block(s) from ip-192-168-14-250.us-east-2.compute.internal:7337

org.apache.spark.network .client.ChunkFetchFailureException: Failure while fetching StreamChunkId[streamId=842490577174,chunkIndex=0]: java.lang.RuntimeException: Executor is not registered (appId=application_1622819239076_0367, execId=661)

Ce problème peut se produire lorsque le composant master de l'exécuteur dans Amazon EMR est en mauvais état. Lorsque l'utilisation du disque pour un composant master dépasse le seuil d'utilisation de 90 %, l'état des services YARN NodeManager indique que le nœud est UNHEALTHY (EN MAUVAIS ÉTAT). Les nœuds en mauvais état sont inclus dans les listes de refus d'Amazon EMR. De plus, les conteneurs YARN ne sont pas alloués à ces nœuds.

Pour corriger le problème, procédez comme suit :

ERROR [Executor task launch worker for task 631836] o.a.s.e.Executor:Exception in task 24.0 in stage 13028.0 (TID 631836) java.util.NoSuchElementException: None.get

Cette erreur se produit en cas de problème au niveau du code de l'application et de l'initialisation de SparkContext.

Assurez-vous qu'il n'y ait pas plusieurs tâches SparkContext actives au cours de la même session. Selon la machine virtuelle Java (JVM), vous ne pouvez avoir qu'un seul SparkContext actif à la fois. Si vous souhaitez initialiser un autre SparkContext, vous devez arrêter la tâche active avant d'en créer une nouvelle.

Container killed on request. Exit code is 137

Cette exception se produit lorsqu'une tâche dans un conteneur YARN dépasse la mémoire physique allouée à ce conteneur. Cela se produit généralement lorsque vous avez des partitions aléatoires, des tailles de partition incohérentes ou un grand nombre de cœurs de l'exécuteur.

Consultez les détails de l'erreur dans les journaux de pilotes Spark pour déterminer la cause de l'erreur. Pour plus d'informations, consultez Comment accéder aux journaux de pilotes Spark dans un cluster Amazon EMR ?

Voici un exemple d'erreur tiré du journal du pilote :

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"...

La trace de pile d'erreurs précédente indique que la mémoire disponible sur l'exécuteur est insuffisante pour poursuivre le traitement des données. Cette erreur peut se produire à différentes étapes de la tâche, dans des transformations étroites ou étendues.

Pour résoudre ce problème, effectuez l'une des opérations suivantes :

  • Augmentez la mémoire de l'exécuteur.
    Remarque : la mémoire de l'exécuteur inclut la mémoire requise pour exécuter les tâches, ainsi que la surcharge de mémoire. La somme de ces valeurs ne doit pas être supérieure à la taille de la JVM et à la taille maximale du conteneur YARN.
  • Ajoutez d'autres partitions Spark.
  • Augmentez le nombre de partitions aléatoire.
  • Réduisez le nombre de cœurs de l'exécuteur.

Pour plus d'informations, consultez Comment résoudre les erreurs « Container killed on request. Exit code is 137 » dans Spark sur Amazon EMR ?

Les tâches Spark sont bloquées et ne se terminent pas

Les tâches Spark peuvent être bloquées pour plusieurs raisons. Par exemple, si le processus du pilote Spark (maître d'application) est affecté ou si les conteneurs de l'exécuteur sont perdus.

Cela se produit généralement lorsque vous utilisez beaucoup d'espace disque ou lorsque vous utilisez des instances Spot pour des nœuds de cluster et que l'instance Spot est résiliée. Pour plus d'informations, consultez Comment résoudre les erreurs ExecutorLostFailure « Slave Lost » (Esclave perdu) dans Spark sur Amazon EMR ?

Pour corriger le problème, procédez comme suit :

  • Consultez le maître d'application ou les journaux de pilotes Spark pour détecter toute exception.
  • Validez la liste des nœuds YARN pour détecter tout nœud en mauvais état. Lorsque l'utilisation du disque pour un nœud principal dépasse le seuil d'utilisation, l'état des services YARN indique que le nœud est UNHEALTHY (EN MAUVAIS ÉTAT). Les nœuds en mauvais état sont inclus dans les listes de refus d'Amazon EMR. De plus, les conteneurs YARN ne sont pas alloués à ces nœuds.
  • Surveillez l'utilisation de l'espace disque et configurez les volumes Amazon Elastic Block Store (Amazon EBS) afin de maintenir l'utilisation en dessous de 90 % pour les composants master du cluster EMR.

WARN Executor: Issue communicating with driver in heartbeater org.apache.spark.rpc.RpcTimeoutException: Futures timed out after [10000 milliseconds]. Ce délai d'attente est contrôlé par spark.executor.heartbeatInterval

Les exécuteurs Spark envoient des signaux de pulsation au pilote Spark à des intervalles spécifiés par la propriété spark.executor.heartbeatInterval. Pendant les longues pauses de récupérateur de mémoire, l'exécuteur peut ne pas envoyer de signal de pulsation. Le pilote arrête les exécuteurs qui n'envoient pas de signal de pulsation supérieur à la valeur spécifiée.

TimeoutException

Les exceptions de délai d'attente se produisent lorsque l'exécuteur est soumis à une contrainte de mémoire ou rencontre des problèmes d'OOM lors du traitement des données. Cela a également un impact sur le processus de récupérateur de mémoire, ce qui entraîne des retards supplémentaires.

Utilisez l'une des méthodes suivantes pour résoudre les erreurs de délai d'attente de pulsation :

  • Augmentez la mémoire de l'exécuteur. Vous pouvez également répartir vos données en fonction du processus d'application.
  • Réglez le récupérateur de mémoire.
  • Augmentez l'intervalle pour spark.executor.heartbeatInterval.
  • Spécifiez une durée période spark.network.timeout plus longue.

ExecutorLostFailure "Exit status: -100. Diagnostics: Container released on a *lost* node

Cette erreur se produit lorsqu'un nœud principal ou un nœud de tâche est résilié en raison d'une utilisation élevée de l'espace disque. Elle se produit également lorsqu'un nœud ne répond plus en raison d'une utilisation prolongée du processeur ou de l'insuffisance de l'espace mémoire disponible. Pour les étapes de résolution des problèmes, consultez la section Comment puis-je résoudre les erreurs « Exit status: -100. Diagnostics: Container released on a *lost* node » dans Amazon EMR ?

Remarque : cette erreur peut également se produire lorsque vous utilisez des instances Spot pour des nœuds de cluster et qu'une instance Spot est résiliée. Dans ce scénario, le cluster EMR met en place une instance à la demande pour remplacer l'instance Spot résiliée. Cela signifie que l'application peut être récupérée d'elle-même. Pour plus d'informations, consultez Améliorations Spark pour l'élasticité et la résilience sur Amazon EMR.

executor 38: java.sql.SQLException (Network error IOException: Connection timed out (Connection timed out)

Ce problème est lié à la communication avec la base de données SQL pour établir la connexion socket lors de la lecture ou de l'écriture de données. Vérifiez que l'hôte de base de données peut recevoir des connexions entrantes sur le port 1433 en provenance des groupes de sécurité de votre cluster EMR.

Vérifiez également le nombre maximal de connexions de base de données parallèles configurées pour la base de données SQL et l'allocation de mémoire pour la classe d'instance de base de données. Les connexions à la base de données consomment également de la mémoire. Si le taux d'utilisation est élevé, vérifiez la configuration de la base de données et le nombre de connexions autorisées. Pour plus d'informations, consultez la section Nombre maximal de connexions à la base de données.

Exceptions relatives à Amazon S3

HTTP 503 « Slow Down »

Des exceptions HTTP 503 se produisent lorsque vous dépassez le taux de requêtes Amazon Simple Storage Service (Amazon S3) pour le préfixe. Une exception 503 ne signifie pas toujours qu'un échec se produira. Toutefois, l'atténuation du problème peut améliorer les performances de votre application.

Pour plus d'informations, consultez Pourquoi ma tâche Spark ou Hive sur Amazon EMR échoue-t-elle avec une exception AmazonS3Exception HTTP 503 « Slow Down » ?

HTTP 403 « Access Denied »

Les erreurs HTTP 403 sont causées par des informations d'identification incorrectes ou non valides, telles que :

  • Les informations d'identification ou rôle spécifiés dans votre code d'application.
  • La politique associée au rôle de profil d'instance Amazon EC2.
  • Les points de terminaison Amazon Virtual Private Cloud (Amazon VPC) pour Amazon S3.
  • Les stratégies de compartiment source et de destination S3.

Pour résoudre les erreurs 403, assurez-vous que le rôle ou la politique AWS Identity and Access Management (IAM) approprié autorise l'accès à Amazon S3. Pour plus d'informations, consultez Pourquoi mon application Amazon EMR échoue-t-elle avec une exception AmazonS3Exception HTTP 403 « Access Denied » ?

HTTP 404 « Not Found »

Les erreurs HTTP 404 indiquent que l'application s'attendait à trouver un objet dans S3, mais qu'au moment de la requête, l'objet était introuvable. Les causes courantes incluent :

  • Des chemins S3 incorrects (par exemple, un chemin mal saisi).
  • Le fichier a été déplacé ou supprimé par un processus extérieur à l'application.
  • Un opération qui a entraîné d'éventuels problèmes de cohérence, tels qu'un remplacement.

Pour plus d'informations, consultez Pourquoi mon application Amazon EMR échoue-t-elle avec une exception AmazonS3Exception HTTP 404 « Not Found » ?


AWS OFFICIEL
AWS OFFICIELA mis à jour il y a un an