Puedes leer todo sin registrarte. Solo crearemos un perfil anónimo cuando decidas guardar tu progreso.
Lección 5 de 5
Estrategias de join y broadcast
El diagnóstico eficaz separa fallos de arranque, librerías, driver y ejecutores.
- Duración
- 17 min aprox.
- Objetivo
- El diagnóstico eficaz separa fallos de arranque, librerías, driver y ejecutores.
- Siguiente paso
- Continuar con el laboratorio
Ver detalles del módulo
Catalyst, particiones, joins y shuffles
Razona sobre el plan lógico y físico antes de ajustar configuraciones o añadir cómputo.
- Leer explain formatted
- Detectar Exchange, skew y spill
- Elegir broadcast, repartition o coalesce con evidencia
05Decisión de diseñoEstrategias de join y broadcast
El diagnóstico eficaz separa fallos de arranque, librerías, driver y ejecutores.
+
Estrategias de join y broadcast
El diagnóstico eficaz separa fallos de arranque, librerías, driver y ejecutores.
Mostrar prerrequisitos
- Dificultad
- Associate + Professional
- Prerrequisitos
- m04
Un cluster que no inicia se investiga en eventos de compute y configuración; un import error en logs de tarea apunta a dependencias; driver OOM suele relacionarse con collect o metadatos.
Parte del mensaje exacto, correlaciona run, task y cluster, y reproduce con el menor input. Cambiar simultáneamente runtime, nodos y código destruye la evidencia.
Modelo mental
Diagnosticar empieza por localizar la fase del fallo: aprovisionamiento, inicialización, carga de dependencias, planificación, ejecución distribuida o commit de salida. Un cluster que nunca alcanza RUNNING no tiene todavía stages útiles; se investiga en eventos y configuración. Un ModuleNotFoundError pertenece al entorno de la tarea. Driver OOM y executor OOM apuntan a memorias y patrones distintos. Una consulta lenta exige plan, Spark UI o Query Profile. El mensaje exacto, run_id, task_key, compute y timestamp forman la evidencia mínima. Cambiar runtime, tamaño y código a la vez destruye causalidad. El método reproduce con el menor input que conserva el síntoma y modifica una variable por experimento.
Etapa concreta del ciclo del workload en la que deja de progresar correctamente.
Dirige hacia la superficie de evidencia adecuada y evita cambios irrelevantes.Agotamiento de memoria en el proceso coordinador, a menudo por resultados locales o metadatos excesivos.
Requiere un diagnóstico diferente del fallo de una tarea en executor.Caso más pequeño que mantiene la causa y condiciones esenciales del fallo.
Permite probar hipótesis rápidamente sin perder causalidad.# Evita: rows = large_df.collect()
summary = large_df.groupBy("status").count()
display(summary)Agrega de forma distribuida antes de devolver un resultado pequeño.
Puntos clave
- Localiza primero la fase del fallo
- Driver y executor tienen causas distintas
- Cambia una variable por experimento
Evita
- Reinstalar librerías sin leer el error
- Aumentar el driver para un problema de skew
Recuerdo activo