Comment résoudre l'erreur « Espace insuffisant sur le périphérique » dans une tâche ETL AWS Glue ?

Brève description

Vous pouvez recevoir les types d'erreurs suivants lorsque vous exécutez une tâche Extraction, transformation et chargement (ETL) AWS Glue :

• Tâche interrompue en raison de l'échec d'une étape : La tâche 68 de l'étape 158.0 a échoué 4 fois, échec le plus récent : Tâche 68.3 perdue à l'étape 158.0 (TID 28820, 10.102.100.111, exécuteur 17) : org.apache.spark.memory.SparkOutOfMemoryError : erreur lors de l'appel de spill () sur org.apache.spark.shuffle.sort.shuffleExternalSorter @55f6dabb : Espace insuffisant sur le périphérique

-ou-

• Tâche interrompue en raison de l'échec d'une étape : ResultStage 7 a atteint le nombre maximum d'échecs autorisé : 4. Raison de l'échec le plus récent : org.apache.spark.shuffle.MetadataFetchFailedException : Absence d'un emplacement de sortie pour shuffle 2

Pendant l’exécution des flux AWS Glue, Apache Spark utilise le disque local pour extraire des données de la mémoire qui dépasse l'espace de mémoire défini par le paramètre de configuration spark.executor.memory.

Les transformations exigeantes telles que groupByKey(), reduceByKey(), et join() peuvent provoquer un mélange. Pendant l'étape de tri ou de mélange, Spark écrit les données intermédiaires sur un disque local avant de pouvoir échanger ces données entre les différents workers. À ce stade, vous pouvez recevoir le message d'erreur « Espace insuffisant sur le périphérique » ou une erreur MetadataFetchFailedException. Spark génère cette erreur lorsqu'il ne reste plus assez d'espace disque sur l'exécuteur et qu'aucune restauration n'est possible.

Résolution

Ces types d'erreurs se produisent généralement lorsque la tâche de traitement observe une asymétrie considérable dans le jeu de données. Cette section répertorie quelques anomalies de surveillance et de débogage fréquentes ainsi que les moyens de les corriger.

Les métriques de tâches AWS Glue et l'interface utilisateur d'Apache Spark sont de puissants outils permettant de surveiller l'asymétrie des données dans les exécuteurs d'Apache Spark. En surveillant la chronologie de l'implémentation, l'outil vous permet de cerner aisément les problèmes susceptibles d'entraîner une distorsion de données. Il vous aide à comprendre en détail le comportement de chaque étape, tâche, travail et exécuteur.

Décomposer le calcul et le stockage

Cette approche permet d'adapter le stockage pour les mélanges importants au lieu d'écrire les données sur le disque local du worker AWS Glue.

**Utilisez un stockage sans serveur dédié :**La version AWS Glue 2.0 ou ultérieure vous permet d'utiliser Amazon Simple Storage Service (Amazon S3) pour stocker le trop plein de données mélangées de Spark.

AWS Glue 2.0 se sert des paramètres de travail suivants pour utiliser Amazon S3 shuffle dans AWS Glue. Pour plus d'informations, consultez la section Plug-in de mélange AWS Glue Spark avec Amazon S3.

• Clé : --write-shuffle-files-to-s3
  Valeur : VRAI
• Clé : --write-shuffle-spills-to-s3
  Valeur : VRAI
• Clé : --conf
  Valeur : spark.shuffle.glue.s3ShuffleBucket=s3://custom_shuffle_bucket
  **Remarque :**L'indicateur facultatif spark.shuffle.glue.s3ShuffleBucket indique le compartiment Amazon S3 dans lequel vous écrivez les fichiers de mélange. Remplacez custom_shuffle_bucket par le nom de votre compartiment S3.

AWS Glue 3.0/4.0 se sert des paramètres de travail suivants pour utiliser le plug-in de stockage de mélanges cloud pour Apache Spark. Pour plus d'informations, consultez la section Plug-in de stockage de mélange pour Apache Spark.

• Clé : --write-shuffle-files-to-s3
  Valeur : VRAI
• Clé : --conf
  Valeur : spark.shuffle.storage.path=s3://custom_shuffle_bucket
  **Remarque :L'indicateur facultatif ** spark.shuffle.storage.path indique le compartiment Amazon S3 dans lequel vous écrivez les fichiers de mélange. Remplacez custom_shuffle_bucket par le nom de votre compartiment S3.

Montée en puissance

La montée en puissance fait référence à l'augmentation du nombre de worker par le biais d'une mise à l'échelle horizontale ou à la mise à niveau du type de worker par une mise à l'échelle verticale. Toutefois, la mise à l'échelle peut ne pas toujours fonctionner, par exemple si vos données sont fortement biaisées sur certaines touches. Pour remédier à l'asymétrie des données, pensez à modifier la logique de l'application Apache Spark en mettant en œuvre la technique de salage.

Réduire et filtrer les données d'entrée

Pré-filtrez autant que possible les données d'entrée afin de minimiser le remaniement des données et l'utilisation du réseau lors d'opérations de grande envergure. Utilisez les techniques suivantes pour un filtrage efficace des données :

• Prédicats de refoulement d'AWS Glue
• Partitionnement, avec exécution limitée, de la charge de travail AWS Glue
• Exclusions AWS Glue pour le filtrage

Diffusion de petites tables

La fusion des tables dans Apache Spark peut déclencher le mélange des données et le transfert d'énormes quantités de données entre les exécuteurs de différents workers. Cela peut entraîner une saturation de la mémoire du système et la propagation des données sur le disque du worker. Pour minimiser la surcharge du réseau, Spark prend en charge l'utilisation de tables plus petites pour la diffusion. Ces tables ne dépassent pas des dizaines de Mo (mégaoctets) et empêchent le partitionnement et le mélange de données. Utilisez une table plus petite pour la diffusion en fournissant un indice à Spark. Pour plus d'informations, consultez Diffusion de petites tables sur le blog AWS Optimize memory management in AWS Glue.

Utiliser AQE

La fonction Adaptive Query Execution (AQE) de Databricks est une technique d'optimisation de Spark SQL. Elle utilise les statistiques d'exécution pour choisir le plan d’implémentation des requêtes le plus efficace afin de résoudre l'asymétrie des données et les partitions de mélanges dynamiques à chaque étape. AQE est disponible par défaut dans AWS Glue 3.0/4.0.

L'AQE assure les fonctions suivantes :

• Fusionne dynamiquement les partitions de mélange
  Fusionne automatiquement les partitions, si nécessaire, après chaque étape de requête, et résout les problèmes de gestion des partitions. Pour plus d'informations, consultez Fusion dynamique de partitions de mélanges dans Adaptive Query Execution : Accélération de Spark SQL lors de l’exécution sur le site Web de Databricks.
  **—Partitions insuffisantes :**Divise automatiquement les partitions contenant des données supplémentaires qui causent un dépassement de capacité sur le disque local.
  **—Partitions en surnombre :**Associe automatiquement les partitions, selon les besoins. Les partitions sont fusionnées lorsque la taille des données de chaque partition est faible et nécessite de petites extractions de données réseau pour lire les blocs de mélanges.

• Changement dynamique des stratégies de jointure
  Convertit la Sort-Merge en jointure de hachage par diffusion, suivant des statistiques sur la taille des tables à chaque étape.

• Optimisation dynamique des jointures asymétriques
  Détecte et optimise automatiquement les jointures asymétriques à partir des statistiques du fichier de mélange. AQE divise les partitions asymétriques en sous-partitions plus petites. Elle joint ensuite ces petites partitions à la partition correspondante de l'autre nœud. Pour plus d'informations, consultez la section Optimisation dynamique des jointures asymétriques du blog Adaptive Query Execution : Accélération de Spark SQL lors de l’exécution sur le site Web de Databricks.

Configurer AQE

Utilisez les paramètres de tâche suivants pour activer AQE :

• Clé : --conf
  Valeur : spark.sql.adaptive.enabled=true --conf spark.sql.adaptive.coalescePartitions.enabled=true --conf spark.sql.adaptive.skewjoin.enabled=true