Puedes leer todo sin registrarte. Solo crearemos un perfil anónimo cuando decidas guardar tu progreso.
Lección 5 de 5
Retries, timeout y notificaciones
Run history, repairs y alertas convierten un DAG fallido en una recuperación auditable.
- Duración
- 17 min aprox.
- Objetivo
- Run history, repairs y alertas convierten un DAG fallido en una recuperación auditable.
- Siguiente paso
- Continuar con el laboratorio
Ver detalles del módulo
Lakeflow Jobs: DAG, tareas y triggers
Convierte ejecuciones manuales en workflows parametrizados, idempotentes y observables.
- Diseñar un DAG con paralelismo seguro
- Configurar tareas, parámetros y dependencias
- Elegir triggers temporales o dirigidos por datos
05Decisión de diseñoRetries, timeout y notificaciones
Run history, repairs y alertas convierten un DAG fallido en una recuperación auditable.
+
Retries, timeout y notificaciones
Run history, repairs y alertas convierten un DAG fallido en una recuperación auditable.
Mostrar prerrequisitos
- Dificultad
- Associate + Professional
- Prerrequisitos
- m09
Repair run reejecuta tareas fallidas y dependientes sin repetir éxitos innecesarios; parameter override permite corregir una partición.
Las alertas deben indicar owner, run y acción. Spark UI atiende ejecución; run history atiende tendencia y estado del workflow.
Modelo mental
Run history explica el estado del workflow; Spark UI explica la ejecución distribuida dentro de tareas Spark; alertas movilizan a un owner; repair run recupera un subconjunto conservando éxitos previos. Estas superficies responden preguntas diferentes y deben formar un runbook. Primero se identifica job, run, task e intento; después se clasifica si el fallo es de orquestación, dependencia, datos, compute o plan. Repair no corrige una causa y no debe pulsarse antes de verificar idempotencia. Las system tables de Lakeflow permiten analizar tendencias y SLA más allá de la retención visual disponible. Una alerta útil incluye impacto, enlace, owner y primera acción, no solo el texto FAILED.
Reejecución selectiva de tareas fallidas o elegidas y de sus dependientes dentro de un run existente.
Reduce tiempo y riesgo al conservar trabajo exitoso, siempre que las fronteras de tareas sean idempotentes.Registro de ejecuciones, estados, parámetros, intentos y tiempos de Jobs disponible para diagnóstico y auditoría.
Localiza dónde falló el workflow antes de investigar detalles de compute o datos.Procedimiento operativo versionado que conecta síntomas, evidencia, owner, decisión de recuperación y criterios de cierre.
Hace que una alerta se convierta en una respuesta consistente en lugar de improvisación personal.SELECT job_id, run_id, result_state, period_start_time
FROM system.lakeflow.job_run_timeline
ORDER BY period_start_time DESC;Une jobs para obtener nombre y segmenta por workspace.
Puntos clave
- Repair preserva éxitos
- Override corrige el run
- Alertas deben ser accionables
Evita
- Relanzar todo tras una única tarea fallida
- Alerta sin enlace al run
Recuerdo activo