Pourquoi la tâche Spark dans Amazon EMR échoue-t-elle ?

Résolution

Défaillances de l'application

Exception d'exécution « Spark shuffle block fetch »

Lorsque le composant master de l'exécuteur dans Amazon EMR est dans un état non sain, le message d'erreur suivant peut s'afficher :

« 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) »

Lorsque l'utilisation du disque pour un composant master dépasse le seuil d'utilisation de 90 %, le service de santé YARN NodeManager identifie le nœud comme étant NON SAIN. Amazon EMR inclut des nœuds non sains dans les listes de refus et les conteneurs YARN ne sont pas alloués aux nœuds non sains.

Pour résoudre ce problème, procédez comme suit :

• Passez en revue les journaux du gestionnaire de ressources du nœud primaire du cluster Amazon EMR pour détecter les composants master non sains. Pour en savoir plus, consultez la section Utilisation élevée du disque en raison d'un nœud non sain dans Comment résoudre une erreur « ExecutorLostFailure: Slave lost » dans Spark sur Amazon EMR ?
• Vérifiez l'utilisation de l'espace disque des nœuds concernés, passez en revue les fichiers qui consomment de l'espace disque et effectuez une récupération des données pour ramener les nœuds à un état sain. Pour en savoir plus, consultez Pourquoi le nœud principal du cluster Amazon EMR manque-t-il d'espace disque ?

Exception d'exécution « NoSuchElementException »

En cas de problème dans le code de l'application et lors de l'initialisation de SparkContext, l'exception suivante peut s'afficher :

« 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 »

Pour résoudre ce problème, assurez-vous qu'il n'y a pas plusieurs tâches SparkContext actives au sein de la même session. Vous ne pouvez avoir qu'un seul SparkContext actif à la fois. Si vous souhaitez initialiser un autre SparkContext, vous devez alors arrêter la tâche active avant d'en créer une nouvelle.

Pour en savoir plus, consultez SparkContext sur le site Web de Spark.

Erreur « Container exit code 137 »

Lorsque la tâche dépasse sa mémoire physique allouée, un conteneur YARN arrête la tâche et l'erreur suivante s'affiche :

« Container killed on request. Exit code is 137 »

Cette erreur s'affiche lorsque vous avez des partitions de mélange, des tailles de partition incohérentes ou un grand nombre de cœurs d'exécuteur.

Passez en revue les détails de l'erreur dans les journaux du pilote Spark pour déterminer la cause de l'erreur. Pour en savoir plus, consultez Comment accéder aux journaux du pilote Spark sur un cluster Amazon EMR ?

Exemple d'erreur dans le journal du pilote :

ERROR YarnScheduler: Lost executor 19 on ip-10-109-##-###.aws.com : Container from a bad node: container_1658329343444_0018_01_000020 on host: ip-10-109-##-###.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 la pile d'erreurs précédente indique qu'il n'y a pas assez de mémoire disponible sur l'exécuteur pour continuer à traiter les données. Cette erreur peut survenir à différentes étapes de la tâche, qu'il s'agisse de transformations étroites ou étendues.

Pour résoudre ce problème, procédez comme suit :

• 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 et la mémoire de surcharge. La somme de ces éléments ne doit pas être supérieure à la taille de la JVM (machine virtuelle Java, Java Virtual Machine) et à la taille maximale du conteneur YARN.
• Ajoutez davantage de partitions Spark.
• Augmentez le nombre de partitions de mélange.
• Réduisez le nombre de cœurs d'exécuteur.

Pour en savoir plus, 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, des modifications apportées au processus du pilote Spark ou la perte de conteneurs d'exécuteur peuvent interrompre des tâches.

Les tâches Spark peuvent être bloquées lorsque l'utilisation de l'espace disque est élevée ou lorsque vous utilisez des instances Spot pour les nœuds de cluster et qu'AWS met fin à l'instance Spot. Pour en savoir plus, consultezComment résoudre une erreur « ExecutorLostFailure : Slave lost » dans Spark sur Amazon EMR ?

Pour résoudre ce problème, procédez comme suit :

• Passez en revue le pilote Spark ou les journaux du pilote pour détecter les exceptions.
• Consultez la liste des nœuds YARN pour détecter les nœuds non sains. Lorsque l'utilisation du disque dépasse le seuil d'utilisation sur un nœud principal, le service de santé YARN Node Manager marque le nœud comme étant NON SAIN. Amazon EMR ajoute les nœuds non sains aux listes de refus et empêche YARN d'allouer des conteneurs à ces nœuds.
• Surveillez l'utilisation de l'espace disque et configurez les volumes Amazon Elastic Block Store (Amazon EBS) pour maintenir l'utilisation en dessous de 90 % pour les composants master du cluster Amazon EMR.

Erreur « Heartbeat communication »

Les exécuteurs Spark envoient des signaux de battement de cœur au pilote Spark à des intervalles spécifiés par la propriété spark.executor.heartbeatInterval. Lorsque de longues pauses du récupérateur de mémoire se produisent, les exécuteurs peuvent ne pas envoyer de signaux de battement de cœur. Le pilote arrête les exécuteurs qui ne parviennent pas à envoyer un signal de battement de cœur au-delà de la valeur spécifiée et l'erreur suivante s'affiche :

« WARN Executor: Issue communicating with driver in heartbeater org.apache.spark.rpc.RpcTimeoutException: Futures timed out after [10000 milliseconds]. This timeout is controlled by spark.executor.heartbeatInterval »

Les contraintes de mémoire ou les problèmes de mémoire insuffisante (OOM) provoquent des exceptions d'exécution lorsque l'exécuteur traite les données. Ces problèmes influent également sur le processus du récupérateur de mémoire et peuvent créer des retards supplémentaires.

Pour résoudre les erreurs de communication du battement de cœur, utilisez l'une des options suivantes :

• Augmentez la mémoire de l'exécuteur. En outre, en fonction du processus de l'application, répartissez les données.
• Réglez le récupérateur de mémoire. Pour en savoir plus, consultez la section Réglage du récupérateur de mémoire sur le site Web d'Apache Spark.
• Augmentez l'intervalle pour spark.executor.heartbeatInterval.
• Spécifiez une période spark.network.timeout plus longue.

Erreur « ExecutorLostFailure »

Lorsqu'une utilisation élevée du disque entraîne l'arrêt d'un nœud principal ou d'un nœud de tâches, l'erreur suivante peut s'afficher :

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

L'erreur précédente peut également s'afficher lorsqu'un nœud ne répond plus en raison d'une utilisation du processeur élevée prolongée ou d'une faible quantité de mémoire disponible. Pour les étapes de résolution des problèmes, consultez Comment résoudre l'erreur « 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 les nœuds de cluster et qu'AWS met fin à une instance Spot. Le cluster Amazon EMR fournit une instance à la demande pour remplacer l'instance Spot arrêtée et l'application peut récupérer d'elle-même. Pour en savoir plus, consultez Améliorations de Spark apportées à l'élasticité et à la résilience sur Amazon EMR.

Erreur « SQL connection timeout »

Lorsqu'une tentative de connexion à la base de données échoue en raison d'une exécution réseau, l'erreur suivante s'affiche :Pour résoudre ce problème, vérifiez que l'hôte de la base de données peut recevoir les connexions entrantes sur le port 1433 depuis les groupes de sécurité du cluster Amazon EMR.

Passez également en revue 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 l'utilisation est élevée, passez alors en revue la configuration de la base de données et le nombre de connexions autorisées. Pour en savoir plus, consultez Nombre maximal de connexions à la base de données.

Exceptions Amazon S3

HTTP 503 « Slow Down »

Les exceptions HTTP 503 se produisent lorsque vous dépassez le taux de demandes Amazon Simple Storage Service (Amazon S3) pour le préfixe. Une exception 503 ne signifie pas toujours qu'une défaillance peut survenir. Toutefois, si vous résolvez l'exception, vous pouvez alors améliorer les performances de l'application.

Pour en savoir plus, consultez Pour quelle raison ma tâche Spark ou Hive sur Amazon EMR échoue-t-elle avec une exception HTTP 503 « Slow Down » AmazonS3Exception ?

HTTP 403 « Access Denied »

Les erreurs HTTP 403 sont provoquées par des informations d'identification incorrectes ou non valides, notamment les informations d'identification suivantes :

• Informations d'identification ou rôles que vous n'avez pas spécifiés dans le code de l'application
• Politique qui est jointe au rôle de profil d'instance Amazon Elastic Compute Cloud (Amazon EC2)
• Points de terminaison Amazon Virtual Private Cloud (Amazon VPC) pour Amazon S3
• Politiques relatives aux compartiments source et de destination Amazon S3

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

HTTP 404 « Not Found »

Lorsque l'application s'attend à trouver un objet dans Amazon S3, mais que l'objet n'a pas été trouvé au moment de la demande, l'erreur « HTTP 404 Not found » s'affiche.

L'erreur peut être due aux raisons suivantes :

• Chemins Amazon S3 incorrects.
• Un processus extérieur à l'application a déplacé ou supprimé le fichier.
• Une opération a entraîné d'éventuels problèmes de cohérence comme un écrasement.

Pour en savoir plus, consultez Pour quelle raison l'application Amazon EMR échoue-t-elle avec une Exception HTTP 404 « Not Found » AmazonS3Exception ?