¿Por qué la ejecución adaptativa de consultas de Spark no está ayudando realmente a mi job?

Dos configuraciones deciden si AQE hace algo en absoluto, y ambas pueden quedar puestas de forma que lo anulen sin un error, sin advertencia, ni ninguna señal en la Spark UI.

Qué cambia realmente AQE a mitad de la consulta

Después de que termina cada etapa de shuffle, AQE tiene tamaños de partición reales con los que trabajar - no la estimación inicial del planificador. Usa eso para fusionar muchas particiones de shuffle pequeñas en menos y más grandes, cambiar un sort-merge join a un broadcast join si un lado resulta ser lo bastante pequeño, y dividir una partición desproporcionadamente grande (skew) en varias tareas más pequeñas.

Por qué silenciosamente no hace nada

Los dos culpables habituales: spark.sql.adaptive.enabled puesto explícitamente en false en algún config compartido, o spark.sql.shuffle.partitions fijado junto con coalescePartitions.enabled=false - que deshabilita el único mecanismo que AQE aplica automáticamente en casi todo job. Ninguno de los dos aparece como error; el job simplemente corre exactamente como lo haría en Spark 2.x.

Dónde AQE no puede salvarlo

AQE solo se adapta después de un límite de shuffle - un job de una sola etapa sin shuffle no obtiene nada de él, y un job cuyo particionado inicial es malo mucho antes de cualquier shuffle igual paga ese costo por adelantado. AQE arregla lo que pasa después de un shuffle, no si la lectura en sí estaba particionada de forma sensata.