Longue étape Spark avec une tâche

Une étape longue avec une seule tâche n'a pas de parallélisme. Pendant l'exécution de la tâche, un processeur effectue le travail, tandis que le reste du cluster peut être inactif. Ajouter des Worker ne change rien, car Spark ne peut pas répartir le travail entre eux.

Utilisez cette page lorsque l’ étape la plus longue ne comporte qu’une seule tâche. Si l’étape comporte de nombreuses tâches, recherchez les asymétries et les spill. Voir Asymétrie et spill.

Causes et corrections courantes

Une étape à tâche unique a le plus souvent l’une des causes suivantes. Trouvez celle qui correspond à votre code, puis appliquez le correctif :

• Une UDF coûteuse sur de petites données. Une petite entrée peut aboutir à une seule partition, de sorte qu’une tâche exécute la totalité de l’UDF. Réécrivez l’UDF à l’aide de fonctions natives si possible. Sinon, repartition() le DataFrame avant d’appliquer l’UDF. Consultez UDF lentes.
• Une fonction de fenêtre sans PARTITION BY. Sans clause PARTITION BY, la fenêtre couvre la totalité du dataset ; une tâche traite donc chaque ligne. Ajoutez une clause PARTITION BY si votre logique le permet.
• Type de fichier non fractionnable. Spark ne peut pas lire de fichiers tels que des fichiers gzip en plusieurs parties, donc une tâche volumineuse lit chaque fichier. Si vous lisez les mêmes fichiers de manière répétée, ingérez-les une fois dans une table Delta Lake et query plutôt la table.
• Option multiLine sur les lectures JSON ou CSV. Définissez multiLine uniquement lorsque les enregistrements s'étendent sur plusieurs lignes. Voir Lire les fichiers JSON multi-lignes.
• Inférence de schéma sur un fichier volumineux. Indiquez le schéma plutôt que de le déduire. Voir Spécifier un schéma.
• repartition(1) ou coalesce(1). Ceux-ci forcent 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.