Puedes leer todo sin registrarte. Solo crearemos un perfil anónimo cuando decidas guardar tu progreso.
Lección 3 de 5
Corrección de código y layout
Recupera fiabilidad respetando idempotencia, checkpoints, contratos Delta y límites exactos del backfill.
- Duración
- 30 min aprox.
- Objetivo
- Recupera fiabilidad respetando idempotencia, checkpoints, contratos Delta y límites exactos del backfill.
- Siguiente paso
- Continuar con la siguiente lección
Ver detalles del módulo
Proyecto de fiabilidad y coste
Recupera un workload degradado equilibrando SLA, capacidad, layout, código y presupuesto.
- Resolver un incidente con método
- Demostrar mejora con métricas
- Definir prevención y alertas
03OperaciónCorrección de código y layout
Recupera fiabilidad respetando idempotencia, checkpoints, contratos Delta y límites exactos del backfill.
+
Corrección de código y layout
Recupera fiabilidad respetando idempotencia, checkpoints, contratos Delta y límites exactos del backfill.
Antes de reintentar, determina el efecto parcial: qué commits Delta existen, qué tarea falló y si el sink externo recibió operaciones. Un `MERGE` con clave estable puede repetirse; un append sin deduplicación puede duplicar. En streaming, borrar un checkpoint cambia el progreso y el estado y rara vez es una reparación segura. Usa repair run para tareas fallidas cuando sus dependencias y outputs sean reutilizables.
Un backfill debe declarar rango, versión de código, tabla destino, estrategia de overwrite/merge y validaciones. Aísla el proceso de la ingesta viva para evitar carreras y conserva una tabla de control de lotes. La recuperación termina cuando reconcilias conteos, claves únicas, freshness y consumidores, no sólo cuando el run aparece verde.
Modelo mental
Recuperar fiabilidad significa reanudar desde una frontera conocida sin perder ni duplicar efectos. En Delta, una transacción hace atómica una escritura, pero no vuelve idempotente todo un pipeline: llamadas externas, múltiples tablas o claves de negocio deficientes pueden repetir resultados. En streaming, el checkpoint vincula progreso de fuente, estado y configuración; borrarlo equivale a olvidar lo procesado y exige un plan explícito. Un backfill es una nueva ejecución sobre un intervalo delimitado, no una excusa para releer toda la historia. El diseño seguro define claves, deduplicación, merge condition, versión de código, snapshot de entrada, orden con el stream activo y pruebas de reconciliación antes de publicar.
Propiedad por la que repetir una operación con la misma entrada produce el mismo estado observable sin efectos adicionales.
Permite retries y backfills seguros cuando fallos parciales hacen incierto qué parte llegó a completarse.Punto verificable de offsets, versión, timestamp o commit desde el que puede reanudarse procesamiento de forma coherente.
Evita reinicios arbitrarios que crean huecos, duplicados o mezclan código e input de periodos distintos.Reejecución selectiva de tareas fallidas y dependientes dentro de un run, preservando resultados válidos cuando el grafo lo permite.
Reduce tiempo, coste y riesgo comparado con repetir un workflow completo ya parcialmente correcto.MERGE INTO prod.silver.orders AS target
USING staging.backfill_orders AS source
ON target.order_id = source.order_id
WHEN MATCHED AND source.updated_at > target.updated_at THEN
UPDATE SET *
WHEN NOT MATCHED THEN
INSERT *;
SELECT order_id, COUNT(*) AS copies
FROM prod.silver.orders
GROUP BY order_id
HAVING COUNT(*) > 1;La segunda consulta es una evidencia mínima; añade reconciliación de importes y rango temporal según el contrato.
Puntos clave
- Inspecciona commits y efectos externos antes de reintentar.
- No borres checkpoints para resolver un fallo de código o calidad.
- Acota y valida cada backfill con una clave de lote.
Evita
- Borrar checkpoint y reprocesar toda la fuente sin conocer retención ni idempotencia.
- Ejecutar backfill y pipeline vivo sobre el mismo rango sin coordinación.
Recuerdo activo