Backfill: qué es y cómo rellenar histórico sin romper nada
Un backfill es la ejecución retroactiva de un proceso de datos sobre periodos ya pasados, para rellenar lo que falta o para recalcular lo que se calculó mal. Es una operación rutinaria en cualquier plataforma de datos y, a la vez, una de las que más incidentes provoca.
Los tres motivos habituales para lanzar uno:
- Un hueco. El pipeline falló varios días y hay fechas sin datos.
- Una corrección. Se descubre un error en la lógica de transformación y lo ya cargado está mal.
- Una ampliación. Se añade una métrica o una columna nueva y hay que calcularla también hacia atrás para que la serie histórica sea comparable.
Por qué es peligroso
Un proceso diario normal escribe un día de datos sobre un sistema en reposo. Un backfill escribe meses o años, a menudo mientras el proceso diario sigue corriendo. Eso cambia tres cosas a la vez:
- El volumen. Lo que en un día ocupa minutos, multiplicado por seiscientas fechas, satura la base de datos o el clúster y afecta a los usuarios que están consultando.
- La concurrencia. Si el backfill y la carga diaria tocan la misma partición al mismo tiempo, el resultado depende de quién acabe último.
- El contexto. La lógica de hoy se aplica a datos de hace dos años, que pueden tener catálogos distintos, monedas antiguas o campos que entonces no existían.
La condición que lo hace seguro: idempotencia
Un backfill solo es una operación tranquila si el pipeline es idempotente: ejecutarlo dos veces sobre la misma fecha debe dejar exactamente el mismo resultado que ejecutarlo una vez.
En la práctica eso significa sobrescribir la partición completa en lugar de añadir filas. Si el
proceso hace insert sin borrar antes, cada reintento duplica los datos y el backfill acaba siendo
peor que el problema que venía a resolver. Si el proceso reemplaza la partición entera, se puede
relanzar tantas veces como haga falta sin consecuencias.
Esta es la razón por la que la idempotencia deja de ser una elegancia de diseño y pasa a ser un requisito operativo en cuanto el sistema lleva un tiempo en producción.
Cómo se ejecuta en la práctica
- Por lotes acotados, no de golpe. Se procesa por tramos —un mes cada vez— para poder parar, revisar y reanudar. Un backfill de dos años lanzado en una sola ejecución no se puede supervisar ni cancelar sin dejar el estado a medias.
- Fuera de la ventana de carga habitual. Para no competir por recursos con el proceso diario ni con las consultas de los usuarios.
- Con el orquestador, no a mano. Herramientas como Airflow permiten relanzar rangos de fechas concretos, lo que deja registro de qué se reprocesó y cuándo. Un script suelto ejecutado desde un portátil no deja rastro y nadie sabe después qué se tocó.
- Verificando contra un recuento previo. Antes de sobrescribir conviene guardar los totales de lo que había, para poder comparar y detectar si el reproceso ha cambiado más de lo esperado.
El caso que no se resuelve con un backfill
Hay un límite importante: el backfill reconstruye lo que se puede recalcular, no lo que no se guardó. Si el sistema origen solo expone el estado actual y no conserva historia, ningún reproceso recuperará cómo estaban las cosas hace seis meses.
Es la diferencia entre un error de cálculo, que se corrige, y una pérdida de información, que no. De ahí que los diseños que necesitan historia la capturen desde el principio, con dimensiones de cambio lento o con captura de cambios en origen, en lugar de confiar en poder reconstruirla más adelante.
En el directorio de herramientas de integración de datos de Dataprix hay fichas y análisis de las herramientas que se usan para este tipo de operaciones, y el tratamiento del histórico dentro del diseño general está en la guía de arquitectura de datos.