Pipelines de datos idempotentes: sobrescritura de particiones, reejecuciones seguras y backfills sin doble conteo

Objetivo

Hacer que cada tarea programada sea segura de ejecutar dos veces, de modo que los reintentos, las reejecuciones manuales y los backfills históricos nunca dupliquen ni pierdan filas, y que «reprocesar el mes pasado» sea un comando en lugar de un proyecto.

Requisitos previos

Un programador que adjunta un intervalo de datos a cada ejecución. La documentación de Airflow (citada) define el intervalo como el rango de tiempo sobre el que opera una ejecución, programa una ejecución después de que su intervalo haya terminado, para que puedan recopilarse todos los datos del período, y llama backfill a la ejecución de un Dag para un período histórico especificado. Su página de buenas prácticas indica que, dado que las tareas pueden reintentarse, deberían producir el mismo resultado en cada reejecución; desaconseja el INSERT simple en una reejecución (filas duplicadas), recomienda UPSERT, e indica leer y escribir en una partición específica en lugar de «los datos disponibles más recientes».

Pasos

1. Parametrizar cada tarea por el intervalo (data_interval_start, data_interval_end); nunca por «ahora». La selección de entrada filtra por el intervalo, de modo que una reejecución ve la misma entrada, a menos que la propia fuente haya cambiado.
2. Escribir la salida como un reemplazo de la porción del intervalo: borrar y después insertar dentro de una sola transacción en un destino relacional, o una sobrescritura de partición en un destino basado en archivos. El INSERT OVERWRITE de Spark con partitionOverwriteMode=dynamic sobrescribe solo las particiones que reciben datos en la ejecución (citado); en modo estático, primero borra todas las particiones que coinciden con la especificación de partición.
3. Cuando el reemplazo sea imposible (tablas de eventos compartidas con otros escritores), hacer upsert sobre una clave determinista derivada del registro, por ejemplo el identificador de origen más el intervalo, de modo que una reejecución actualice en lugar de añadir.
4. Hacer que los agregados aguas abajo se recalculen a partir de la porción reemplazada en lugar de sumar deltas; un agregado que suma incrementos contará dos veces una partición rellenada por backfill.
5. Para un backfill, ejecutar los intervalos en orden con una concurrencia acotada, y tras cada intervalo comparar el número de filas y una suma de verificación de las columnas clave con la versión anterior de esa partición; registrar la diferencia.
6. Volver a ejecutar las tareas dependientes para los mismos intervalos; un backfill de una tabla sin sus consumidores deja el almacén internamente inconsistente.

Resultado esperado

Volver a ejecutar cualquier intervalo deja la salida idéntica a la de una única ejecución limpia. Rellenar un rango mediante backfill produce las mismas tablas que si el código corregido se hubiera ejecutado según lo programado.

Límites y base de verificación

Las fuentes que sobrescriben el historial (tablas operativas mutables) rompen el determinismo del intervalo; conviene tomar una instantánea por intervalo o usar captura de datos de cambios (CDC). Un backfill que abarca un cambio de esquema necesita el esquema nuevo para todos los intervalos. El método es un protocolo derivado de la documentación citada; no se afirma ninguna medición de su efecto.