Puedes leer sin crear un espacio. Créalo solo cuando quieras guardar.
Guardar progresoLección 5 de 5
Retries, timeout y notificaciones
Run history, repairs y alertas convierten un DAG fallido en una recuperación auditable.
17 min aprox.
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.
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.
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.
¿Qué evita repetir tareas ya correctas?
Profundiza
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.Resumen
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