Spark
Средний уровеньПочему adaptive query execution в Spark на самом деле не помогает моей задаче?
AQE перепланирует запрос Spark, используя реальные числа из уже прошедшего shuffle — а не догадку планировщика. Но для этого ему нужно, чтобы ничего незаметно его не отключало.
Две настройки решают, делает ли AQE вообще что-либо, и обе можно выставить так, что он перестанет работать — без ошибки, предупреждения или какого-либо следа в Spark UI.
Что AQE на самом деле меняет посреди запроса
После завершения каждой shuffle-стадии у AQE появляются реальные размеры партиций — не изначальная оценка планировщика. Он использует это, чтобы объединить множество мелких shuffle-партиций в меньшее число крупных, переключить sort-merge join на broadcast join, если одна сторона оказалась достаточно маленькой, и разбить непропорционально большую партицию (skew) на несколько задач меньшего размера.
Почему он незаметно ничего не делает
Два обычных виновника: spark.sql.adaptive.enabled явно выставлен в false где-то в общем конфиге, или spark.sql.shuffle.partitions захардкожен вместе с coalescePartitions.enabled=false — это отключает единственный механизм, который AQE применяет автоматически почти на каждой задаче. Ни один из этих случаев не выглядит как ошибка — задача просто работает в точности как на Spark 2.x.
Где AQE вам не поможет
AQE адаптируется только после границы shuffle — однофазная задача без shuffle вообще ничего от него не получает, а задача с плохим начальным партиционированием задолго до любого shuffle всё равно платит эту цену заранее. AQE исправляет то, что происходит после shuffle, а не то, разумно ли было партиционировано само чтение.
Посмотрите, как это выглядит на вашем собственном пайплайне.
Загрузите реальный event log Spark, run_results.json от dbt или экспорт метрик Flink — и получите конкретные рекомендации, которые нужно одобрить, а не ещё одно эмпирическое правило.