Backfills: qué pasado estamos recalculando

El viernes llega un fichero que debería haber llegado el martes. El equipo lo incorpora, recalcula la semana y el dashboard queda corregido. Entonces aparece una pregunta que el nuevo gráfico ya no permite contestar: ¿por qué el miércoles decidimos enviar más mercancía a aquella tienda?

Con los datos actuales, la decisión parece absurda. Con los que teníamos el miércoles, quizá era perfectamente razonable. El escenario es hipotético, pero la dificultad es muy real: podemos mejorar la historia de los datos y, al mismo tiempo, perder la historia de lo que sabíamos.

Un backfill crea o reconstruye resultados para periodos anteriores. Su aceptación exige algo más preciso que «ya están todos los días»: debemos acordar si queremos corregir el pasado, reproducir una decisión o calcular una alternativa que nunca ocurrió. Las tres tareas pueden procesar las mismas fechas y producir respuestas distintas sin que ninguna haya fallado técnicamente.

Qué cambia cuando recalculamos datos históricos

Recalcular cambia el resultado disponible hoy. No demuestra por sí solo cuál estaba disponible entonces. En el ejemplo de la tienda hay al menos dos momentos relevantes: cuándo se produjo el movimiento de mercancía y cuándo entró en nuestro sistema la información que lo describía.

Esta distinción tiene antecedentes claros. En Bitemporal History, publicado en 2021, Martin Fowler separa la historia efectiva de la historia de lo registrado. Su ejemplo de una actualización salarial conocida después de preparar una nómina muestra por qué ambas perspectivas pueden ser necesarias. La distinción conceptual es suya; aquí la utilizamos para discutir qué resultado debemos aceptar tras un reprocesamiento.

Volvamos a la mercancía. Si preguntamos cuántas unidades se movieron realmente el martes, querremos incorporar el fichero tardío. Si preguntamos qué información justificó el envío del miércoles, introducir ese fichero en la reconstrucción puede dar al responsable un conocimiento que todavía no tenía. Y si preguntamos qué habría decidido otra política de reposición, estamos construyendo una simulación.

Las cifras pueden coincidir en algún caso. Las preguntas siguen siendo diferentes. Conservar esa diferencia evita presentar como fallo humano lo que era información ausente, o vender como rendimiento histórico el resultado de una regla evaluada con datos del futuro.

El orquestador decide qué ejecutar, no qué significa el pasado

La documentación de backfills de Apache Airflow describe la creación de ejecuciones para fechas pasadas y distingue comportamientos de reprocesamiento según existan ejecuciones previas y su estado. También permite controlar la concurrencia del backfill. Son capacidades operativas útiles: ayudan a decidir qué trabajo se intentará ejecutar.

No responden a qué entradas debe ver ese trabajo ni qué versión de la lógica representa la pregunta del negocio. Una ejecución correcta puede consultar una clasificación de clientes actualizada hoy y aplicarla a ventas antiguas. Quizá eso sea justamente lo solicitado. Quizá arruine una comparación histórica. El estado final de la tarea no resuelve la ambigüedad.

Por eso resulta insuficiente conservar solo el rango de fechas. Para interpretar el resultado necesitamos saber qué información podía entrar y con qué criterio se calculó. La fecha del dato, la disponibilidad de la información y la versión de la transformación son dimensiones relacionadas, pero intercambiarlas cambia la pregunta.

Una ficha de reconstrucción histórica

La ficha de reconstrucción histórica que propongo es un artefacto propio para acordar el significado de un backfill antes de aceptar sus resultados. No exige una arquitectura concreta ni sustituye las comprobaciones de calidad.

Pregunta y perspectiva

Expresar si buscamos la mejor historia corregida con lo conocido hoy, la información disponible en una fecha pasada o una simulación con reglas alternativas.

Entrada admisible

Precisar qué datos, correcciones y referencias pueden participar. Si la disponibilidad histórica no está conservada, registrar que la reconstrucción de decisiones será parcial.

Lógica aplicable

Identificar la versión del cálculo y sus dependencias. Mantener la fórmula mientras cambia una tabla de referencia puede cambiar el resultado igualmente.

Destino del resultado

Decidir si reemplaza una versión, convive con ella o sirve solo para comparar. Los consumidores deben distinguir una corrección de una hipótesis.

Criterio de aceptación

Acordar quién explica las diferencias y qué evidencia permite usar la nueva historia. Terminar sin errores es una comprobación necesaria en muchos procesos, pero no justifica cualquier variación.

Podemos aplicar la ficha al caso de la tienda sin convertirlo en un proyecto desmesurado. Para corregir el movimiento real, admitimos el fichero tardío y conservamos la identificación de la versión sustituida. Para reconstruir la decisión del miércoles, lo excluimos si aún no estaba disponible. Para evaluar otra política, presentamos el resultado como simulación y explicamos qué información habría podido utilizar.

Una diferencia numérica necesita una explicación

Supongamos, solo como ejemplo ilustrativo, que el resultado anterior mostraba 1.000 unidades y el fichero tardío añade 80 correspondientes al mismo periodo. Si no hay otros cambios ni solapamientos, el total corregido será 1.080: un 8 % más respecto de las 1.000 iniciales. El cálculo es sencillo. La aceptación depende de comprobar esas condiciones.

Si obtenemos 1.140, necesitamos explicar las otras 60. Podrían proceder de otra corrección válida, de una nueva clasificación o de un duplicado. Un umbral que admita automáticamente cualquier diferencia inferior a cierto porcentaje escondería la pregunta que importa: qué parte del cambio tiene una causa conocida.

Esta revisión conecta con el significado compartido de las métricas. A veces el dato está bien y lo que cambió es el perímetro del cálculo. En otras ocasiones falta evidencia para decidir. Mantener el resultado anterior y el candidato separados hasta entender la diferencia puede ser más útil que sustituir una cifra y confiar en que nadie pregunte.

El reprocesamiento también consume recursos y puede competir con el trabajo del día. Su urgencia depende del uso: una corrección necesaria para una decisión inmediata tiene un compromiso distinto del recálculo exploratorio de varios años. Esa prioridad debería acompañar al alcance, sin convertir todos los históricos en emergencias.

Un backfill bien aceptado permite decir qué historia estamos ofreciendo y por qué cambió. Si además necesitamos explicar decisiones antiguas, tendremos que preservar qué se sabía entonces. Recalcular mejor el pasado no nos concede el derecho de atribuir ese conocimiento a quienes actuaron sin él.