Datos incrementales e idempotencia
Carga completa frente a incremental
La carga completa vuelca todo cada vez: simple y auto-corregible, pero cara y lenta al crecer. La incremental trae solo las filas nuevas o modificadas, escalando con el cambio y no con el histórico.
Cómo detectar el delta
- Por marca temporal de creación o actualización en el origen.
- Por un número de versión o registro de cambios creciente.
- Por captura de cambios de datos que registra inserciones, modificaciones y borrados.
Borrados y la trampa
Lo incremental se olvida de los borrados si solo miras altas y cambios. Sin una señal de supresión, una fila eliminada en el origen sobrevive para siempre en el destino: el borrado lógico suele ser la salida honesta.
Qué es idempotencia
Una operación idempotente produce el mismo resultado aplicarla una vez que cien. En cargas, relanzar el mismo lote no debe duplicar ni degradar: el destino queda como si el job hubiera corrido una sola vez y bien.
Cómo lograrla
Se escribe por fusión sobre una clave natural, reemplazando particiones completas o con un merge que actualiza o inserta. La clave está en que cada fila tenga un identificador determinista que la haga única.
Reproducibilidad
Un pipeline reproducible entrega el mismo resultado si se relanza sobre los mismos insumos, aunque lleve días parado. Exige anclar versión de código, datos de referencia y no depender del reloj del ejecutor.
Coste del backfill
Corregir el pasado con cargas incrementales es delicado: hay que reprocesar las ventanas afectadas en orden y de forma idempotente, o acabarás con histórico inconsistente entre lo viejo y lo nuevo.
Errores frecuentes
- Reprocesar todo desde cero cada día y descubrir el coste cuando el histórico ya no cabe.
- Detectar solo altas y cambios, sin señal de supresión, y dejar filas borradas vivas en el destino.
- Relanzar el lote a medias sobre una escritura no idempotente y duplicar lo ya cargado.
Ejemplo resuelto: sincronizar ventas sin duplicar
Un job nocturno trae ventas de un ERP y a mitad de ventana falla a veces. El diseño seguro:
- Definir una clave natural determinista que haga única cada fila de venta.
- Detectar el delta por marca temporal y, además, por registro de cambios que capture borrados.
- Escribir por fusión sobre la clave, o reemplazar la partición de la ventana completa.
- Propagar los borrados con una señal de supresión y borrado lógico en el destino.
- Verificar recuentos contra el origen en cada lote para detectar huecos temprano.
¿Para qué sirve en la realidad?
Toda empresa que alimenta un panel desde sistemas transaccionales necesita mover cambios, no historia completa. De ello dependen el coste de cómputo, la frescura del dato y dormir tranquilo sabiendo que un reintento no duplica ventas.
Un job incremental termina a medias por un fallo y vuelve a lanzarse sobre la misma ventana de fecha. La propiedad que evita que las filas de esa ventana se dupliquen es:
Detectar el delta solo por filas nuevas basta para reflejar correctamente los borrados del origen.
Incremental
Ordena el diseño de una carga incremental fiable:
Clave
Delta
Fusion
Verificacion
Idempotencia
Definición formal de idempotencia y su sentido en operaciones que se repiten.
Une cada necesidad de la carga con su técnica.
Solo el delta, y sin duplicar
# Incremental e idempotencia ## Completa ### simple y autocorrectiva ### cara al crecer ## Delta ### marca temporal ### registro de cambios ### ojo con borrados ## Idempotencia ### fusión por clave ### reemplazo de partición ## Garantía ### reproducible ### verificar recuentos
Replicación incremental con CDC
Guía práctica de replicación incremental y captura de cambios en conectores reales.
Tus ventas diarias corregían ayer una fila de hace tres meses. Una carga incremental por marca temporal, ¿la recogería? ¿Qué necesitas añadir al diseño para no perder correcciones tardías?