Étape Spark longue avec une seule tâche

Une phase de longue durée avec une seule tâche n’a pas de parallélisme. Pendant que la tâche s’exécute, un CPU fait le travail, et le reste du cluster peut rester inactif. Ajouter des workers n’aide pas, car Spark ne peut pas répartir le travail entre eux.

Utilisez cette page lorsque l’étape la plus longue n’a qu’une seule tâche. Si l’étape comporte plusieurs tâches, vérifiez si elle présente une asymétrie ou un déversement. Voir Asymétrie et déversement.

Causes et correctifs courants

Une étape à tâche unique a le plus souvent l’une de ces causes. Trouvez celui qui correspond à votre code, puis appliquez la solution :

• Un UDF coûteux sur de petits volumes de données. De petites entrées peuvent se retrouver dans une seule partition, donc une tâche exécute tout le UDF. Réécrivez le UDF en utilisant des fonctions natives si possible. Sinon, utilisez repartition() sur le DataFrame avant d’appliquer la fonction définie par l’utilisateur (UDF). Voir les UDF lents.
• Une fonction fenêtre sans PARTITION BY. Sans clause PARTITION BY , la fenêtre couvre tout le jeu de données, donc une tâche traite chaque ligne. Ajoutez une PARTITION BY clause si votre logique le permet.
• Un type de fichier non scindable. Spark ne peut pas lire des fichiers comme des fichiers gzip en plusieurs parties, donc une grosse tâche lit chaque fichier. Si vous lisez les mêmes fichiers à répétition, ingérez-les une fois dans une table Delta Lake et interrogez la table à la place.
• L’option multiLine sur les lectures JSON ou CSV. Définissez multiLine uniquement lorsque les enregistrements couvrent plusieurs lignes. Voir Lire les fichiers JSON multiligne.
• Inférence de schéma sur un grand fichier. Spécifiez le schéma au lieu de l’inférer. Voir Spécifier un schéma.
• repartition(1) ou coalesce(1). Cela force toutes les données dans une seule partition. Supprimez-les, ou utilisez plus de partitions, sauf si vous avez besoin d’un seul fichier de sortie.