Une tâche Spark tourne pendant une heure alors que les autres finissent en quelques secondes. Que se passe-t-il et comment le corrigez-vous ?

C'est du data skew : une clé concentre une part disproportionnée des lignes, donc une seule partition fait l'essentiel du travail après un shuffle. Confirmez-le en regardant la distribution de la clé de jointure ou de regroupement. Corrigez-le en activant la gestion des jointures asymétriques d'adaptive query execution, en diffusant le petit côté s'il tient en mémoire, en salant la clé chaude sur plusieurs partitions, ou en filtrant et traitant les clés aberrantes à part.

Une longue traîne sur une seule tâche signifie presque toujours du skew : après le shuffle, une clé a atterri dans une partition et cette partition détient l'essentiel des lignes. Je commence par le confirmer plutôt que le supposer : un group by sur la clé de jointure avec un count, et un coup d'oeil au stage dans la Spark UI, où la durée max de tâche et la taille de shuffle read écrasent la médiane. Ajouter des executors ne change rien, parce que le travail n'est pas réparti. Le correctif dépend de la forme du problème. Si l'autre côté de la jointure est petit, diffusez-le et supprimez complètement le shuffle. S'il est vraiment gros des deux côtés, adaptive query execution peut découper automatiquement les partitions asymétriques, et au-delà je sale : j'ajoute un suffixe aléatoire à la clé chaude, je réplique le petit côté sur ces sels, je joins, puis j'agrège. Celui qui piège les gens, ce sont les nulls. Nous avions une clé de jointure nulle sur environ 40% des lignes, qui hachaient toutes vers la même partition, et filtrer les nulls avant la jointure a réglé le problème d'un coup.