El escenario que todos conocen
Un pipeline corre todos los días sin problemas. Hasta que un día alguien descubre que un campo del origen cambió de formato hace tres semanas. O que una regla de negocio se actualizó y nadie avisó. O que un bug en la transformación estuvo generando valores incorrectos desde el mes pasado.
La reacción típica es tratarlo como emergencia: parches manuales, scripts ad-hoc, correcciones que se ejecutan una vez y se olvidan. El problema es que esto pasa todo el tiempo. Y si cada vez lo tratás como excepción, terminás con un cementerio de scripts de corrección que nadie entiende.
Por qué el reproceso es inevitable
Los datos están vivos. Las fuentes cambian, las reglas de negocio evolucionan, los errores se descubren tarde. Todo lo que asumiste cuando diseñaste el pipeline probablemente va a cambiar con el tiempo.
Esto forma parte de la naturaleza del trabajo con datos, no es un defecto del sistema ni una falla del equipo. Las suposiciones que hiciste al diseñar (el formato de un campo, la frecuencia de actualización, la completitud de una fuente) son válidas hasta que dejan de serlo.
Si diseñás tu pipeline asumiendo que nunca vas a tener que reprocesar, estás diseñando para un escenario que no existe. El reproceso forma parte del plan A, no del plan B.
Qué significa diseñar para reprocesar
Diseñar para reprocesar implica que el pipeline pueda volver a ejecutarse para un rango de fechas o un conjunto de datos sin romper nada ni requerir intervención manual heroica.
Esto tiene implicancias concretas:
Idempotencia: si ejecutás el mismo proceso dos veces con los mismos parámetros, el resultado tiene que ser el mismo. Si tu transformación depende de la hora del sistema o de estados externos no controlados, reprocesar va a dar resultados distintos.
Parametrización de fechas: el proceso tiene que poder recibir la fecha de cierre como parámetro, no calcularla internamente con un current_date(). Si la fecha está hardcodeada o se calcula al vuelo, no podés reprocesar el martes pasado sin modificar código.
Particionamiento coherente: si tus datos están particionados por fecha, el reproceso tiene que poder reemplazar solo las particiones afectadas sin tocar el resto. Si cada ejecución reescribe todo, reprocesar un día implica reprocesar todo el histórico.
Trazabilidad del origen: necesitás saber qué datos entraron en cada ejecución. Si no guardás esa información, cuando algo falla no sabés si el problema es del origen o de tu transformación.
El costo de no diseñar para reprocesar
Cuando el reproceso no está contemplado en el diseño, cada corrección se convierte en un proyecto:
- Hay que entender qué datos están mal y desde cuándo.
- Hay que escribir scripts específicos para ese caso.
- Hay que coordinar con consumidores para que no usen datos mientras se corrige.
- Hay que validar que la corrección no rompió otra cosa.
- Hay que documentar qué se hizo (si es que alguien lo documenta).
Multiplicá esto por cada incidente y tenés un equipo que pasa más tiempo apagando incendios que construyendo.
El otro costo es la pérdida de confianza. Si cada vez que hay un problema la corrección tarda días y requiere intervención manual, los consumidores empiezan a dudar de los datos. Y una vez que se pierde la confianza, recuperarla es difícil.
Backfill como operación estándar
El backfill (reprocesar un rango histórico) debería ser una operación estándar, no una emergencia. Esto significa que:
- El orquestador tiene que soportar ejecutar un rango de fechas sin intervención manual.
- Las transformaciones tienen que poder recibir ese rango y procesarlo correctamente.
- El destino tiene que poder absorber la reescritura sin inconsistencias.
Si tu herramienta de orquestación no soporta backfills nativamente, vas a terminar escribiendo scripts que simulan esa funcionalidad. Y esos scripts van a tener bugs, van a estar mal documentados, y van a fallar justo cuando más los necesitás.
Reintentos parciales
Relacionado con el backfill está el reintento parcial: cuando un pipeline de muchas tareas falla en la tarea 47, necesitás poder retomar desde ahí sin volver a ejecutar las 46 anteriores.
Si tu pipeline no soporta esto, cada falla implica volver a correr todo desde el principio. Con pipelines cortos no es grave. Con pipelines de horas, es un problema operativo serio.
El diseño tiene que contemplar puntos de recuperación: estados intermedios desde los cuales se puede retomar sin perder trabajo ni generar inconsistencias.
Coherencia entre capas
El reproceso no es solo un problema del orquestador. Tiene que haber coherencia entre la capa que dispara los jobs y la capa que transforma.
Si el orquestador manda una fecha de cierre pero la transformación la ignora y usa current_date(), el reproceso no va a funcionar. Si la transformación espera un parámetro que el orquestador no sabe pasar, tampoco.
Esta coherencia tiene que estar diseñada desde el principio. No es algo que se agrega después cuando aparece el primer incidente.
En resumen
El reproceso forma parte del trabajo con datos vivos, no es un accidente ni una falla. Las suposiciones del diseño cambian, los errores se descubren tarde, las fuentes evolucionan.
Diseñar para reprocesar desde el inicio (idempotencia, parametrización, particionamiento coherente, trazabilidad) evita que cada corrección se convierta en un proyecto de emergencia. El backfill y el reintento parcial deberían ser operaciones estándar, no parches heroicos.
Si tu pipeline no puede reprocesar sin intervención manual, no está listo para producción.
Cierre de la colección
A lo largo de esta colección vimos las piezas que hacen a un pipeline de datos robusto: elegir la estrategia de extracción correcta (full, incremental, CDC), mantener el orquestador liviano y enfocado en coordinar, entender que la simplicidad conceptual de orquestar no equivale a simplicidad operativa.
Todo eso converge acá: un pipeline bien diseñado es uno que puede reprocesar. Si la extracción no es repetible, si el orquestador tiene lógica embebida que no se puede parametrizar, si no hay forma de retomar desde un punto intermedio, el sistema es frágil.
El reproceso no es el último recurso. Es la prueba de que el diseño funciona.