Warum ist mein Spark-Job plötzlich langsamer geworden, ohne Code-Änderungen?

Sie haben den Job nicht angefasst. Der DAG ist identisch. Das letzte Deployment liegt drei Wochen zurück. Und trotzdem hat der Lauf letzte Nacht 40 Minuten statt 12 gedauert. Das ist eines der häufigsten Tickets im Data Engineering, und es lässt sich fast immer auf eine von drei Ursachen zurückführen.

1. Die Daten sind gewachsen, die Konfiguration nicht

Shuffle-Partition-Anzahl, Executor-Speicher und Broadcast-Join-Schwellenwerte werden meist einmal, während der ursprünglichen Entwicklung, gegen das damals vorhandene Datenvolumen festgelegt. Sechs Monate später hat dieselbe Tabelle die vierfache Zeilenzahl, und dasselbe spark.sql.shuffle.partitions=200 erzeugt jetzt Partitionen, die nicht mehr bequem in den Speicher passen und bei jedem Shuffle-Stage auf Festplatte ausweichen. Am Code hat sich nichts geändert — an der Annahme, die die Konfiguration kodiert hat, schon.

So prüfen Sie das: Vergleichen Sie Eingabe-Zeilenzahlen und Shuffle-Lese-/Schreibbytes zwischen einem aktuellen langsamen Lauf und einem älteren schnellen, im Stages-Tab der Spark-UI. Ein großer Sprung dort, mit einer ungefähr proportionalen Verlangsamung, deutet genau darauf hin.

2. Ein Join, der mal balanciert war, ist es nicht mehr

Data Skew kündigt sich nicht an — er bedeutet nur, dass eine Handvoll Partitionen das 10- bis 100-fache der Arbeit der übrigen übernehmen, sodass die Wanduhrzeit vom langsamsten Task diktiert wird, nicht vom durchschnittlichen. Eine Key-Verteilung, die beim Start ungefähr gleichmäßig war, kann driften, wenn sich Nutzungsmuster ändern (ein Kunde, eine Region, ein Ereignistyp beginnt, das Volumen zu dominieren).

So prüfen Sie das: Sortieren Sie in der Stage-Detailansicht der Spark-UI die Tasks nach Dauer. Ein Stage, bei dem der p50-Task 4 Sekunden und der maximale Task 6 Minuten braucht, ist eindeutig skewed.

3. Der Cluster ist nicht der Cluster, auf dem Sie getestet haben

Autoscaling-Cluster, Spot-Instance-Pools und geteilte Multi-Tenant-Cluster können Ihrem Job still weniger oder langsamere Executor geben als beim letzten Mal, besonders bei Konkurrenz durch andere Jobs. Das zeigt sich als langsamere Wanduhrzeit bei identischer Pro-Task-CPU-Zeit — der Job leistet dieselbe Arbeit, wartet nur länger auf Ressourcen dafür.

So prüfen Sie das: Vergleichen Sie die tatsächlich zugewiesenen (nicht angeforderten) Executor über Läufe hinweg, und schauen Sie sich die Scheduler-Verzögerung an, nicht nur die Task-Dauer.