Puedes leer sin crear un espacio. Créalo solo cuando quieras guardar.
Guardar progresoLecció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.
17 min aprox.
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.
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.
¿Qué vista usarías para demostrar que cinco tareas concentran el shuffle de una etapa?
Profundiza
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.Resumen
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.