Por que a execução adaptativa de consultas do Spark não está realmente ajudando meu job?

Duas configurações decidem se o AQE faz alguma coisa, e ambas podem estar configuradas de um jeito que o anula sem erro, sem aviso, e sem nenhum sinal na Spark UI.

O que o AQE realmente muda no meio da consulta

Depois que cada estágio de shuffle termina, o AQE tem os tamanhos reais das partições para trabalhar - não a estimativa inicial do planejador. Ele usa isso para juntar muitas partições de shuffle pequenas em menos e maiores, trocar um sort-merge join por um broadcast join se um lado acabar sendo pequeno o bastante, e dividir uma partição desproporcionalmente grande (skew) em várias tasks menores.

Por que ele silenciosamente não faz nada

Os dois culpados mais comuns: spark.sql.adaptive.enabled definido explicitamente como false em algum config compartilhado, ou spark.sql.shuffle.partitions fixado junto com coalescePartitions.enabled=false - o que desativa o único mecanismo que o AQE aplica automaticamente em quase todo job. Nenhum dos dois aparece como erro; o job simplesmente roda exatamente como rodaria no Spark 2.x.

Onde o AQE não consegue te salvar

O AQE só se adapta depois de um limite de shuffle - um job de um único estágio sem shuffle não ganha nada com ele, e um job cujo particionamento inicial é ruim bem antes de qualquer shuffle ainda paga esse custo antecipadamente. O AQE conserta o que acontece depois de um shuffle, não se a leitura em si foi particionada de forma sensata.