Un backfill vuelve a procesar un periodo histórico para incorporar datos que faltaban o aplicar una regla corregida. El riesgo aparece cuando esa reconstrucción compite con la carga diaria, mezcla versiones o sustituye resultados antes de comprobarlos.
Este procedimiento utiliza un ejemplo ficticio: corregir el cálculo de una categoría comercial en varios meses de ventas. El objetivo no es ejecutar el mayor número posible de tareas, sino publicar un histórico cuya procedencia y diferencias puedan explicarse.
Antes de ejecutar: define qué vas a reconstruir
Escribe el periodo, la entidad afectada, la regla que cambia y los consumidores que utilizarán el resultado. Distingue fecha de negocio, fecha de recepción y fecha de ejecución del proceso.
En el ejemplo, un pedido de enero recibido en febrero puede pertenecer a la partición de enero si esa es la definición del modelo. Seleccionar solo archivos que llegaron durante enero dejaría fuera ese pedido.
Identifica también las entradas necesarias. Si el origen conserva únicamente el estado actual, quizá no puedas reproducir cómo se clasificaba cada producto en el pasado. Esa limitación debe resolverse antes de presentar el resultado como una reconstrucción histórica.
Paso 1. Fija entradas y versión de la transformación
Conserva una referencia a los lotes u objetos que vas a consumir y a la versión de la lógica. Si existen correcciones concurrentes del origen, decide si el backfill las incorpora o si trabaja sobre un corte identificable.
Una marca de tiempo escrita en una hoja no congela los datos. Necesitas un mecanismo de versión, copia o consulta que ofrezca la consistencia prevista.
La salida debe indicar qué ejecución la produjo. Relaciona partición, versión de entrada y versión de transformación con el resultado. Esa información permite reanudar el trabajo y distinguir dos reconstrucciones del mismo periodo.
Paso 2. Ejecuta primero una partición representativa
Elige una partición que incluya los casos difíciles: cambios de categoría, devoluciones, fechas de llegada tardías o registros cuyo valor falta. No selecciones únicamente el periodo más pequeño si no representa el problema.
Escribe inicialmente en una ubicación de validación separada del conjunto que consumen los informes. Compara el resultado con la versión anterior y explica las diferencias esperadas.
| Control | Pregunta que responde |
|---|---|
| Cobertura de claves | ¿Faltan o sobran operaciones? |
| Unicidad según el grano | ¿Una operación aparece más veces de las previstas? |
| Totales por agrupaciones relevantes | ¿La corrección desplaza importes de forma explicable? |
| Distribución de valores ausentes | ¿Se ha perdido información necesaria? |
| Casos de negocio reconstruidos | ¿La nueva regla produce el resultado acordado? |
Un total global idéntico puede ocultar compensaciones entre errores. Utiliza controles por partición y casos identificables además de sumas generales.
Paso 3. Limita el trabajo que compite con la carga diaria
Define concurrencia, recursos y horario del backfill. Reserva una forma de pausar nuevas particiones sin perder el estado de las que ya se confirmaron.
El mecanismo de backfill de Apache Airflow permite gestionar ejecuciones históricas y su concurrencia. El orquestador organiza el trabajo; la consistencia de las escrituras y la aceptación del resultado pertenecen al pipeline.
Observa el efecto sobre los procesos habituales: retraso de actualización, espera de consultas y errores del origen. Establece criterios de pausa antes de comenzar. Si la operación diaria se degrada, no debería hacer falta improvisar qué tareas detener.
Paso 4. Registra progreso después de confirmar el resultado
Una partición marcada como completada debe corresponder a una salida disponible y validada según su contrato. Evita avanzar el registro de control antes de confirmar la escritura.
Si una tarea se interrumpe después de escribir pero antes de registrar su finalización, podría repetirse. La idempotencia del pipeline permite que esa repetición no añada duplicados ni mezcle resultados parciales.
Mantén estados operativos comprensibles: pendiente, en ejecución, escrita, validada y publicada, si tu flujo necesita distinguirlos. Registra el fallo y la decisión tomada al reanudar; no conviertas un reintento en una nueva ejecución de negocio sin relación con la anterior.
Paso 5. Promueve un conjunto coherente
Decide si los consumidores pueden ver particiones de versiones diferentes. En algunos informes puede ser aceptable; en una serie comparativa puede producir una lectura engañosa.
Cuando sea necesaria coherencia del conjunto, termina las particiones y valida su cobertura antes de cambiar la referencia que utiliza el consumidor. El mecanismo puede ser una versión publicada, una vista o una sustitución controlada compatible con el sistema.
Comprueba también cachés, extractos e informes derivados. Cambiar la tabla principal no garantiza que todas las vistas hayan dejado de utilizar el cálculo anterior.
Paso 6. Conserva una reversión utilizable
La reversión debe indicar qué referencia restaurar, qué salidas dependientes regenerar y durante cuánto tiempo se conserva la versión anterior. Prueba el procedimiento sobre la partición piloto.
Volver a un resultado anterior puede recuperar disponibilidad, pero también devolver el error que motivó la corrección. Esa consecuencia debe conocerla quien decide la reversión.
El cierre del backfill incluye el inventario de particiones publicadas, las diferencias aceptadas, los controles ejecutados y las limitaciones pendientes. Si necesitas preparar una recuperación de histórico en una plataforma Big Data, comparte con Nexeus Big Data el grano, las fuentes conservadas y los informes afectados. Con ese alcance se puede diseñar una ejecución que tenga tanto criterios de aceptación como una salida ante fallos.