Ein Spark-Task läuft eine Stunde, während der Rest in Sekunden fertig ist. Was passiert da und wie behebst du es?

Das ist Data Skew: ein Key hält einen unverhältnismäßigen Anteil der Zeilen, also erledigt nach dem Shuffle eine einzige Partition die meiste Arbeit. Bestätige es, indem du die Verteilung des Join- oder Group-Keys prüfst. Behebe es, indem du die Skew-Join-Behandlung von Adaptive Query Execution aktivierst, die kleine Seite broadcastest, falls sie passt, den heißen Key über mehrere Partitionen saltest oder die Ausreißer-Keys separat verarbeitest.

Ein langer Ausläufer bei einem Task heißt fast immer Skew: nach dem Shuffle ist ein Key in einer Partition gelandet und diese Partition hat die meisten Zeilen. Zuerst bestätige ich das, statt es anzunehmen, also ein Group by auf dem Join-Key mit Count und ein Blick auf den Stage in der Spark UI, wo maximale Task-Dauer und Shuffle-Read-Größe den Median weit übertreffen. Executors draufzuwerfen bringt nichts, weil die Arbeit nicht verteilt ist. Der Fix hängt von der Form ab. Ist die andere Seite des Joins klein, broadcaste sie und spar dir den Shuffle komplett. Sind beide Seiten wirklich groß, kann Adaptive Query Execution schiefe Partitionen automatisch splitten, und darüber hinaus salte ich: ein zufälliges Suffix an den heißen Key, die kleine Seite über diese Salts replizieren, joinen, dann aggregieren. Woran Leute hängen bleiben, sind Nullwerte. Wir hatten einen Join-Key, der für rund 40% der Zeilen null war, und alle hashten in dieselbe Partition. Nullwerte vor dem Join zu filtern hat es sofort behoben.