Errores, Checkpoints y recuperación en Lakeflow

Objetivo: saber qué hacer cuando falla un pipeline, cuándo basta con reiniciarlo y por qué un Full Refresh puede provocar pérdida de datos.

1. ¿Qué guarda realmente un checkpoint?

Un checkpoint no es únicamente el último offset de Kafka. Puede almacenar tres tipos de información:

• Progreso: hasta qué offset o versión se ha procesado.

• Estado: información de agregaciones, joins y deduplicación.

• Metadatos: información necesaria para recuperar la ejecución.

Lakeflow administra estos checkpoints internamente para cada flow de streaming. Databricks on AWS

Supongamos que el pipeline falla procesando los offsets 801–900.

Al reiniciarlo, Lakeflow puede recuperar el último estado confirmado y reintentar el lote fallido sin duplicar sus efectos en la tabla gestionada.

Esto es posible gracias a la combinación de checkpoints, recuperación de Spark y escrituras transaccionales. No significa que cualquier operación externa —por ejemplo, llamar a una API— tenga automáticamente garantías exactly-once. Databricks on AWS

2. Cuatro incidentes de producción

Databricks documenta distintas alternativas de recuperación, como Full Refresh, reconstrucción con backup/backfill y reset selectivo de checkpoints. Databricks on AWS

3. Full Refresh: ¿qué hace exactamente?

Comparemos las operaciones.

En una Materialized View, Full Refresh recalcula el resultado completo.

Un reset de checkpoint no es equivalente a un Full Refresh: conservar datos y volver a procesar eventos puede crear duplicados si la operación no es idempotente. Databricks on AWS

4. Experimento: el peligro de Kafka con retención corta

Imagina esta situación:

• Event Hubs conserva los eventos durante 24 horas.

• Bronze tiene 30 días de histórico.

• Lanzas Full Refresh sobre Bronze.

Por eso, en una arquitectura con Kafka, Bronze debería diseñarse para no necesitar Full Refresh habitual. Es más seguro mantener el histórico raw en Delta y reconstruir Silver desde ese histórico cuando sea necesario. Databricks on AWS

5. Práctica: diagnosticar un pipeline fallido

Cuando falle un pipeline, sigue este procedimiento:

1. Abre Jobs & Pipelines y selecciona la ejecución fallida.

2. Consulta Issues, el DAG y el mensaje de error del flow afectado.

3. Identifica si el problema es transitorio, de calidad, de código o del checkpoint.

4. Corrige la causa y utiliza Validate cuando sea un cambio de código o configuración.

5. Utiliza Refresh failed tables si corresponde. Reserva Full Refresh para los casos que realmente lo requieren.

Databricks permite reejecutar únicamente las tablas fallidas y sus dependientes, evitando reprocesar todo el pipeline. Databricks on AWS

Consultar errores con SQL

SELECT
    timestamp,
    event_type,
    message,
    error
FROM event_log('<pipeline-id>')
WHERE level = 'ERROR'
ORDER BY timestamp DESC
LIMIT 20;

Esto te permite investigar el error con mayor detalle que el mensaje resumido de la interfaz.

6. Un concepto avanzado: Rewind

Databricks dispone también de Pipeline Rewind, actualmente una funcionalidad Beta con requisitos específicos.

Permite volver a un punto anterior y reprocesar datos preservando la coherencia entre tablas, offsets y estado, en los casos compatibles.

Pero no sirve para solucionar checkpoints corruptos o cambios incompatibles en operadores con estado. Databricks on AWS

Lo estudiaremos en profundidad más adelante; por ahora, quédate con que Rewind y Full Refresh son operaciones diferentes.

7. Mini ejercicio: incidente real

Qué debes recordar:

• Los checkpoints permiten recuperar una ejecución sin empezar desde cero.

• Los errores transitorios normalmente requieren reintentos, no Full Refresh.

• Los cambios incompatibles de estado necesitan una recuperación planificada.

• Nunca reconstruyas Bronze desde Kafka sin verificar primero la retención y la posibilidad de recuperar el histórico.

Próxima lección: desplegaremos Lakeflow como código utilizando Databricks Asset Bundles y Unity Catalog, pasando el mismo pipeline por DEV, UAT y PROD.