Idempotencia en pipelines: cómo evitar la duplicación y la corrupción de datos
Un desarrollador de datos comparte técnicas para garantizar que un pipeline pueda ejecutarse varias veces sin efectos adversos, desde MERGE hasta configuraciones versionadas.
¿Te ha tocado levantarte a las tres de la madrugada porque una pipeline ha duplicado registros? Si los pipelines no son idempotentes, no están listos para producción. En entornos como fintech o el sector salud, una repetición de una carga puede suponer millones en transacciones duplicadas o corrupción de expedientes. Un desarrollador con años de experiencia en este terreno comparte los patrones que aplica para que un reproceso sea seguro y no te robe el sueño.
Nada de INSERT a ciegas
La base de todo es dejar de usar INSERT INTO sin control. En BigQuery, Snowflake o Databricks conviene usar MERGE, o sobreescribir particiones completas. Si trabajas con Spark, puedes usar mode('overwrite') y partitionOverwriteMode('dynamic') para que, si una ejecución falla, bastará con relanzar todo el lote sin efectos colaterales sobre el resto de la tabla.
IDs deterministas y sin efectos secundarios
Otro consejo: no uses autoincrementales para las claves subrogadas. Genera el ID con un hash de las claves naturales (por ejemplo, usuario+fecha). Así, cuando se repite un job, el hash coincide y se actualiza el registro en lugar de crear otro. Y ojo con los efectos colaterales: si la pipeline además de escribir datos manda avisos a Slack o actualiza una caché, eso no es idempotente. Lo correcto es que la escritura de datos sea lo único que haga el trabajo, y que las acciones externas las dispare un observador que solo se ejecuta cuando encuentra el marcador de finalización.
Borrar antes de insertar y consumir APIs con cuidado
Cuando el MERGE no es viable, porque el motor no lo soporta o se vuelve lento, queda el borrado previo dentro de una transacción: en Postgres o Snowflake, borras el rango de fechas y luego insertas el lote nuevo. Si la inserción falla, el borrado se revierte y te quedas con los datos originales. Para consumidores de API, conviene usar ETags o Last-Modified para decidir si merece la pena traerse los datos, y mantener una caché local con los registros ya procesados en la ventana actual.
Configuración versionada y monitorización de calidad
Por último, la configuración de la pipeline (fuentes, destinos, ventanas de captura) debe estar versionada en un repositorio, no en variables de un panel web. Así, cuando un trabajo falla a las 3 de la mañana, puedes ir al commit de esa hora y reproducir las mismas condiciones. Y no basta con monitorizar fallos: una pipeline puede 'funcionar' y producir datos incorrectos. Hay que vigilar la calidad de los datos, por ejemplo comparando los totales con lo esperado o comprobando que no hay duplicados.
Aplicar estas prácticas no es lujo: es asegurar que el sistema se auto-repara cuando las cosas salen mal. Y si el sistema se repara solo, no necesitas estar pegado al móvil toda la noche.
