Puedes leer todo sin registrarte. Solo crearemos un perfil anónimo cuando decidas guardar tu progreso.
Lección 1 de 5
Spark UI: jobs, stages y executors
Lee Spark UI de arriba abajo: job, stage, task y executor, manteniendo una hipótesis que conecte tiempo con datos y recursos.
- Duración
- 17 min aprox.
- Objetivo
- Lee Spark UI de arriba abajo: job, stage, task y executor, manteniendo una hipótesis que conecte tiempo con datos y recursos.
- Siguiente paso
- Continuar con la siguiente lección
Ver detalles del módulo
Spark UI, Query Profile y system tables
Combina señales de ejecución, plataforma y datos para reducir el tiempo de diagnóstico.
- Localizar cuellos en Spark UI y Query Profile
- Consultar historial de Jobs y auditoría
- Usar CLI y REST para automatizar diagnóstico
01Modelo mentalSpark UI: jobs, stages y executors
Lee Spark UI de arriba abajo: job, stage, task y executor, manteniendo una hipótesis que conecte tiempo con datos y recursos.
+
Spark UI: jobs, stages y executors
Lee Spark UI de arriba abajo: job, stage, task y executor, manteniendo una hipótesis que conecte tiempo con datos y recursos.
Spark UI es la herramienta de detalle para compute clásico. Empieza por la timeline y el job más largo, entra en su stage crítico y compara tareas. Scheduling delay señala falta de slots o overhead; shuffle read/write muestra movimiento; spill, GC y duración extrema orientan a memoria o skew. Los executors permiten comprobar si el trabajo se distribuyó y si hubo pérdidas.
No conviertas cada métrica en una receta. Un stage con 90 % de tiempo en una tarea no mejora con más workers; una etapa I/O-bound puede necesitar mejor layout o pruning. Conserva IDs de job, stage y run, captura percentiles y anota el plan o commit analizado para que otra persona reproduzca el diagnóstico.
Modelo mental
Spark UI es una reconstrucción causal de una ejecución. Un job nace de una acción; cada job contiene stages separados por exchanges; cada stage ejecuta tareas equivalentes sobre particiones; los executors aportan procesos, memoria y cores. Leer de arriba abajo evita saltar a una métrica llamativa sin contexto. Primero se identifica el camino crítico, después la etapa dominante, luego la distribución por tarea y finalmente el recurso que explica esa distribución. El plan SQL conecta esas métricas con operadores y datos de negocio. Una hipótesis completa suena así: este join produce un shuffle, una clave concentra bytes, cinco tareas derraman a disco y determinan la duración. No basta decir que el clúster está lento.
Conjunto de tareas que pueden ejecutarse sin un nuevo shuffle y comparten el mismo plan físico local.
Sitúa la frontera donde cambian distribución y dependencia, permitiendo localizar el camino crítico.Ejecución concreta de una tarea, incluida una repetición tras fallo o especulación.
Mezclar intentos puede inflar métricas y ocultar que la fiabilidad, no el volumen, causa el tiempo.Cadena de etapas y tareas que determina el tiempo mínimo de finalización del job.
Optimizar trabajo paralelo fuera de esa cadena puede no mejorar el SLA.spark.sparkContext.setJobGroup(
"daily-margin-2026-07-21",
"Daily margin aggregation · release 4f2c9ab",
)
result = build_daily_margin(spark.table("prod.silver.order_lines"))
result.write.mode("overwrite").saveAsTable("prod.gold.daily_margin")El job group facilita localizar la ejecución correcta; no registres secretos ni datos personales en la descripción.
Puntos clave
- Navega desde la duración global hasta la tarea que explica el cuello.
- Correlaciona tiempo, bytes, registros, spill y ejecutor.
- Guarda identificadores y baseline para reproducibilidad.
Evita
- Mirar sólo la página Executors y perder la etapa concreta que causa el problema.
- Comparar una ejecución fría con otra caliente sin registrar caché y volumen.
Recuerdo activo