Puedes leer sin crear un espacio. Créalo solo cuando quieras guardar.
Guardar progresoLección 5 de 5
Estrategias de join y broadcast
El diagnóstico eficaz separa fallos de arranque, librerías, driver y ejecutores.
17 min aprox.
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.
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.
# Evita: rows = large_df.collect()
summary = large_df.groupBy("status").count()
display(summary)Agrega de forma distribuida antes de devolver un resultado pequeño.
¿Dónde empiezas ante un cluster que nunca arrancó?
Profundiza
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.Resumen
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