Puedes leer sin crear un espacio. Créalo solo cuando quieras guardar.
Guardar progresoLección 3 de 5
Estado, CDC y calidad
Un plan de recuperación distingue reinicio, replay y rebuild, y nunca borra estado antes de capturar evidencia y delimitar el rango afectado.
30 min aprox.
03OperaciónEstado, CDC y calidad
Un plan de recuperación distingue reinicio, replay y rebuild, y nunca borra estado antes de capturar evidencia y delimitar el rango afectado.
+
Estado, CDC y calidad
Un plan de recuperación distingue reinicio, replay y rebuild, y nunca borra estado antes de capturar evidencia y delimitar el rango afectado.
Un fallo transitorio del executor suele resolverse reanudando desde el mismo checkpoint. Un cambio incompatible de estado requiere checkpoint nuevo y reconstrucción desde bronze. Un error lógico publicado exige identificar versiones o tiempos afectados, corregir código y escribir de forma idempotente en un destino aislado antes del cutover.
La retención de Kafka, CDF, archivos y Delta debe cubrir el RTO y el máximo tiempo de detección. Si el origen ya eliminó datos, restaurar compute no recupera completitud. Los runbooks incluyen criterios para pausar productores o consumidores, rutas alternativas y validación posterior.
SELECT
min(event_ts) AS first_affected,
max(event_ts) AS last_affected,
count(*) AS affected_rows,
count(DISTINCT event_id) AS affected_events
FROM main.silver.web_events
WHERE pipeline_version = '2026.07.20-bad'
AND event_date BETWEEN DATE '2026-07-20' AND DATE '2026-07-21';Repara primero en una tabla sombra y compara claves/conteos antes de reemplazar o hacer `MERGE` en producción.
¿Cuándo es apropiado conservar el checkpoint durante la recuperación?
Profundiza
Recuperar no siempre significa reiniciar. Un reinicio restaura el mismo plan desde un checkpoint compatible tras un fallo transitorio. Un replay vuelve a procesar un intervalo conservando una fuente durable, normalmente hacia staging o una versión nueva. Un rebuild reconstruye estado y destino completos cuando cambió la semántica o se perdió compatibilidad. Elegir mal puede ocultar pérdida o duplicar efectos. Antes de actuar se inmoviliza evidencia: error, batch, offsets, versiones Delta, estado de sinks y métricas. Borrar checkpoint convierte recuperación en consulta nueva y elimina la frontera que permitía razonar. El runbook debe indicar condiciones de entrada, autoridad, RPO/RTO, validaciones y rollback. Un replay no se publica directamente sobre producción sin reconciliar claves, secuencias, conteos e invariantes; además debe evitar efectos externos hasta aprobar el resultado.
Continuación del mismo plan lógico desde el último checkpoint compatible después de un fallo operativo.
Es la opción de menor impacto cuando código, estado y datos siguen siendo válidos.Reprocesamiento deliberado de un intervalo histórico desde una fuente durable con límites explícitos.
Corrige resultados sin destruir el progreso de la consulta activa y ofrece comparación antes de publicar.Reconstrucción completa o sustancial del estado y salida con un checkpoint nuevo.
Es necesaria ante cambios incompatibles o corrupción, pero exige planificación de corte, coste y reconciliación.Resumen
Puntos clave
- Reinicio conserva checkpoint; replay usa un rango y estado aislados; rebuild reconstruye una tabla completa.
- Captura `lastProgress`, offsets, versión de código y error antes de mutar estado.
- La retención de origen es un requisito de recuperación, no solo una decisión de coste.
Evita
- Borrar checkpoint como primer paso y perder el punto exacto del incidente.
- Reprocesar todo el histórico en el mismo destino sin aislar escrituras ni evitar duplicados.