Idempotencia: qué es y por qué importa en los pipelines de datos

Una operación es idempotente cuando ejecutarla varias veces produce el mismo resultado que ejecutarla una sola vez. Aplicado a los datos: si un proceso de carga se lanza dos veces por error, la tabla de destino tiene que quedar igual que si se hubiera lanzado una.

Por qué importa

Un pipeline falla. Falla la red, falla el origen, alguien relanza un proceso sin mirar. La pregunta no es si va a ocurrir, sino qué pasa cuando ocurra. Sin idempotencia, un reintento duplica filas, infla métricas y obliga a limpiar a mano; con ella, el reintento es gratis y se puede automatizar.

Esto cambia la forma de operar. Un equipo que confía en que sus cargas son idempotentes puede relanzar un día concreto sin auditar antes qué quedó a medias, y puede reprocesar un mes entero para corregir un error de lógica sin miedo a contar dos veces.

Cómo se consigue

• Sustituir en lugar de añadir. Una carga que borra la partición del día y la vuelve a escribir es idempotente por construcción. Una que hace insert sin más, no.
• Claves de negocio estables. Si cada fila tiene un identificador determinista, una operación de merge actualiza lo existente en vez de duplicarlo.
• Nada de valores no deterministas en las claves. Generar el identificador con la hora de ejecución o un aleatorio rompe la idempotencia: el mismo dato produce claves distintas en cada pasada.
• Ventanas de reproceso explícitas. Definir que cada ejecución se hace cargo de un rango temporal concreto y lo reescribe entero evita las zonas grises entre ejecuciones.

Las transformaciones declarativas ayudan: en dbt un modelo describe el estado final deseado en lugar de los pasos para llegar a él, lo que empuja de forma natural hacia cargas repetibles. En los modelos incrementales conviene revisar la clave única, que es donde se pierde la propiedad sin darse cuenta.

No confundir con “no hacer nada”

Idempotente no significa que la segunda ejecución se salte el trabajo, sino que el estado final no cambia. El proceso puede volver a leer, transformar y escribir; lo que no puede es dejar el destino distinto que la primera vez.

Es una de las propiedades que separan un pipeline que aguanta en producción de uno que exige vigilancia constante, y por eso aparece pronto en cualquier discusión seria sobre calidad del dato.

La aplicación más frecuente de esta propiedad es el backfill: sin idempotencia, una recarga de histórico duplica datos en lugar de corregirlos.

En la guía de arquitectura de datos de Dataprix tienes el análisis completo de este tipo de decisiones de diseño.