Pourquoi ma tâche AWS Glue ETL prend-elle beaucoup de temps ?

Brève description

Les raisons courantes pour lesquelles l’exécution de vos tâches AWS Glue prend beaucoup de temps sont les suivantes :

• Jeux de données volumineux
• Répartition non uniforme des données dans les jeux de données
• Répartition inégale des tâches entre les exécuteurs
• Ressources insuffisantes

Résolution

Activer les métriques

AWS Glue fournit des métriques Amazon CloudWatch utilisables pour fournir des informations sur les exécuteurs et la quantité de travail réalisée par chaque exécuteur. Vous pouvez activer les métriques CloudWatch sur votre tâche AWS Glue en procédant de l'une des façons suivantes :

Utilisation d'un paramètre spécial : ajoutez l'argument suivant à votre tâche AWS Glue. Ce paramètre vous permet de collecter des métriques pour le profilage des tâches pour votre exécution. Ces métriques sont disponibles sur la console AWS Glue et la console CloudWatch.

Key: --enable-metrics

Utilisation de la console AWS Glue : pour activer les métriques sur une tâche existante, procédez comme suit :

1. Ouvrez la console AWS Glue.
2. Dans le panneau de navigation, choisissez Jobs (Tâches).
3. Sélectionnez la tâche pour laquelle vous souhaitez activer les métriques.
4. Choisissez Action, puis Edit job (Modifier la tâche).
5. Sous Monitoring options (Options de surveillance), sélectionnez Job metrics (Métriques de la tâche).
6. Choisissez Enregistrer.

Utilisation de l'API : utilisez l'API AWS Glue UpdateJob avec --enable-metrics comme paramètre DefaultArguments pour activer les métriques sur une tâche existante.

Remarque : AWS Glue 2.0 n'utilise pas YARN qui signale les métriques. Cela signifie qu’il est impossible d’obtenir certaines métriques de l'exécuteur, telles que numberMaxNeededExecutors et numberAllExecutor, pour AWS Glue 2.0.

Activer la journalisation continue

Si vous activez la journalisation continue dans votre tâche AWS Glue, les journaux de l'exécuteur et du pilote en temps réel sont transférés vers CloudWatch toutes les cinq secondes. Avec ces informations de journalisation en temps réel, vous obtenez plus de détails sur la tâche en cours. Pour plus d'informations, consultez la section Activation de la journalisation continue pour les tâches AWS Glue.

Vérifier les journaux du pilote et de l'exécuteur

Dans les journaux du pilote, vérifiez si l’exécution de certaines tâches a pris beaucoup de temps. Par exemple :

2021-04-15 10:53:54,484 ERROR executionlogs:128 - g-7dd5eec38ff57a273fcaa35f289a99ecc1be6901:2021-04-15 10:53:54,484 INFO [task-result-getter-1] scheduler.TaskSetManager (Logging.scala:logInfo(54)): Finished task 0.0 in stage 7.0 (TID 139) in 4538 ms on 10.117.101.76 (executor 10) (13/14)
...
2021-04-15 12:11:30,692 ERROR executionlogs:128 - g-7dd5eec38ff57a273fcaa35f289a99ecc1be6901:2021-04-15 12:11:30,692 INFO [task-result-getter-3] scheduler.TaskSetManager (Logging.scala:logInfo(54)): Finished task 13.0 in stage 7.0 (TID 152) in 4660742 ms on 10.117.97.97 (executor 11) (14/14)

Ces journaux montre qu'une seule tâche a pris 77 minutes. Utilisez ces informations pour déterminer pourquoi cette tâche spécifique prend beaucoup de temps. Vous pouvez le faire en utilisant l'interface utilisateur Web Apache Spark. L'interface utilisateur Spark fournit des informations bien structurées pour différentes étapes, tâches et exécuteurs.

Activer l'interface utilisateur Spark

Vous pouvez utiliser l'interface utilisateur Spark pour résoudre les problèmes de tâches Spark à l’exécution longue. En lançant le serveur d'historique Spark et en activant les journaux de l'interface utilisateur Spark, vous pouvez obtenir des informations sur les étapes et les tâches. Vous pouvez utiliser les journaux pour déterminer comment les tâches sont exécutées par les DPU. Vous pouvez activer l'interface utilisateur Spark à l'aide de la console AWS Glue ou depuis l'AWS Command Line Interface (AWS CLI). Pour plus d'informations, consultez Activation de l'interface utilisateur Web Apache Spark pour les tâches AWS Glue.

Une fois la tâche terminée, des journaux de pilote comme ceux-ci peuvent s'afficher :

ERROR executionlogs:128 - example-task-id:example-timeframe INFO [pool-2-thread-1] s3n.MultipartUploadOutputStream (MultipartUploadOutputStream.java:close(414)): close closed:false s3://dox-example-bucket/spark-application-1626828545941.inprogress

Après avoir analysé les journaux de la tâche, vous pouvez lancer le serveur d'historique Spark sur une instance Amazon Elastic Compute Cloud (Amazon EC2) ou à l'aide de Docker. Ouvrez l'interface utilisateur et accédez à l'onglet Executor (Exécuteur) pour vérifier si un exécuteur particulier est en cours d'exécution depuis longtemps. Si c’est le cas, la répartition inégale du travail et la sous-utilisation des ressources disponibles pourraient être dues à une asymétrie des données dans le jeu de données. Dans l'onglet Stages (Étapes), vous pouvez obtenir d’autres informations et statistiques sur les étapes qui ont pris du temps. Les informations vous permettront de déterminer si ces étapes ont impliqué des débordements aléatoires coûteux et chronophages.

Planification de capacité des unités de traitement des données (DPU)

Si bien que tous les exécuteurs contribuent de manière égale à la tâche, celle-ci prend encore beaucoup de temps, envisagez d'ajouter des DPU à votre tâches afin d'améliorer la vitesse. La planification de capacité des DPU peut vous aider à éviter ce qui suit :

• Le sous-approvisionnement qui peut entraîner un ralentissement de l'exécution
• Le sur-approvisionnement qui entraîne des surcoûts, mais fournit des résultats dans le même temps

Les métriques CloudWatch vous permettent d’obtenir des informations sur le nombre d'exécuteurs actuellement utilisés et le nombre maximal d'exécuteurs nécessaires. Le nombre de DPU nécessaires dépend du nombre de partitions en entrée et du type de DPU demandé.

Gardez à l'esprit les points suivants lorsque vous définissez le nombre de partitions en entrée :

• Si les fichiers Amazon Simple Storage Service (Amazon S3) ne sont pas fractionnables, le nombre de partitions est égal au nombre de fichiers d'entrée.
• Si les fichiers Amazon S3 sont fractionnables et si les données ne sont pas structurées/semi-structurées, le nombre de partitions est égal à la taille totale du fichier / 64 Mo. Si la taille de chaque fichier est inférieure à 64 Mo, le nombre de partitions est égal au nombre de fichiers.
• Si les fichiers Amazon S3 sont fractionnables et si les données sont structurées, le nombre de partitions est égal à la taille totale du fichier / 128 Mo.

Pour calculer le nombre optimal de DPU, procédez comme suit :

Par exemple, supposons que le nombre de partitions en entrée soit de 428. Vous pouvez ensuite calculer le nombre optimal de DPU en appliquant la formule suivante :

Nombre maximal d'exécuteurs nécessaires = Nombre de partitions d'entrée/Nombre de tâches par exécuteur = 428/4 = 107

Gardez à l'esprit les points suivants :

• Le type de DPU standard prend en charge 4 tâches par exécuteur
• G.1X prend en charge 8 tâches par exécuteur
• G.2X prend en charge 16 tâches par exécuteur

Le type de DPU standard comporte deux exécuteurs, dont un pilote, dans un nœud. L'un de ces exécuteurs est un pilote dans Spark. Vous avez donc besoin de 108 exécuteurs.

Nombre de DPU nécessaires = (Nombre d'exécuteurs/Nombre d'exécuteurs par nœud) + 1 DPU = (108/2) + 1 = 55.

---

Informations connexes

Paramètres spéciaux utilisés par AWS Glue

Surveillance des tâches à l'aide de l'interface utilisateur web Apache Spark

Surveillance de la planification de capacité des DPU