Puedes leer sin crear un espacio. Créalo solo cuando quieras guardar.
Guardar progresoLección 3 de 5
Broadcast y sort merge join
Comprende qué puede reoptimizar Adaptive Query Execution en tiempo de ejecución y qué decisiones siguen dependiendo del diseño del ingeniero.
17 min aprox.
03OperaciónBroadcast y sort merge join
Comprende qué puede reoptimizar Adaptive Query Execution en tiempo de ejecución y qué decisiones siguen dependiendo del diseño del ingeniero.
+
Broadcast y sort merge join
Comprende qué puede reoptimizar Adaptive Query Execution en tiempo de ejecución y qué decisiones siguen dependiendo del diseño del ingeniero.
AQE usa estadísticas disponibles después de exchanges para cambiar una estrategia sort-merge a broadcast hash, combinar particiones post-shuffle demasiado pequeñas, dividir particiones sesgadas y propagar relaciones vacías. En Databricks está habilitado por defecto para consultas batch compatibles con exchanges o subconsultas. El plan adaptativo final puede diferir del plan inicial mostrado antes de ejecutar.
AQE no reordena dinámicamente todos los joins ni arregla un modelo de datos deficiente. Una relación que parece pequeña en catálogo puede superar el límite real, y determinados tipos de join no admiten broadcast en uno de sus lados. Usa `explain('formatted')`, el plan final de Spark UI y métricas de ejecución para demostrar qué regla se aplicó; evita copiar configuraciones antiguas que anulen los defaults optimizados.
print(spark.conf.get("spark.sql.adaptive.enabled"))
result = (
facts.join(dimensions, "product_id")
.groupBy("category")
.count()
)
result.explain("formatted")
result.count() # materializa el plan para revisarlo en Spark UILa acción materializa la consulta; revisa después el plan final y no deduzcas la estrategia sólo del plan inicial.
¿Qué ventaja tiene un broadcast planeado estáticamente frente a uno elegido tarde por AQE?
Profundiza
Catalyst prepara una ruta con estimaciones; AQE actúa como un navegador que recalcula cuando ya conoce el tráfico real después de ciertos cruces. Esos cruces son query stages separados por exchanges o subconsultas. Al materializarse una etapa, Spark obtiene tamaños y distribuciones más fiables que las estadísticas previas y puede cambiar algunas decisiones físicas sin alterar la consulta lógica. AQE no es un optimizador omnisciente: no corrige semántica, no rediseña el modelo ni reordena libremente toda cadena de joins. Su valor está en adaptar particiones post-shuffle, tratar skew, propagar relaciones vacías y, cuando procede, sustituir un sort-merge por broadcast con evidencia runtime.
Fragmento del plan adaptativo delimitado por exchanges cuya salida puede materializar estadísticas runtime.
AQE toma nuevas decisiones con información precisa al terminar cada etapa materializable.Combinación dinámica de particiones pequeñas producidas por un shuffle.
Reduce overhead de tareas diminutas sin imponer un número estático adecuado para todos los volúmenes.Plan físico efectivo después de aplicar o descartar reglas AQE durante la ejecución.
Es la evidencia para saber qué estrategia se usó; el plan inicial no basta.Resumen
Puntos clave
- AQE decide con estadísticas posteriores al shuffle, más precisas que muchas estimaciones previas.
- Puede coalescer particiones y tratar skew sin alterar el resultado lógico.
- No sustituye el orden lógico de joins ni una buena reducción temprana de datos.
Evita
- Suponer que AQE reordena automáticamente una cadena de joins mal diseñada.
- Desactivar AQE para reproducir una configuración heredada sin comparar resultados y métricas.