Cargas incrementales de datos: cómo actualizar sin perder cambios por el camino

Copiar todos los datos cada noche puede funcionar al principio. Con el crecimiento, la ventana se alarga, aumenta la carga sobre el origen y cualquier fallo obliga a repetir demasiado trabajo. Una ingestión incremental procesa lo que ha cambiado desde una referencia conocida. Parece sencillo hasta que aparecen actualizaciones tardías, borrados o una interrupción a mitad del lote. Diseñar esas situaciones desde el principio evita informes que se actualizan con rapidez pero van perdiendo coherencia con el sistema original.

Define qué significa un cambio

La primera pregunta es qué operaciones admite la fuente. Si solo añade eventos inmutables, un identificador creciente puede bastar. Si modifica registros existentes, hace falta una fecha fiable de modificación o un mecanismo que capture los cambios. También hay que saber cómo representa las eliminaciones. Consultar únicamente filas nuevas deja fuera correcciones y bajas. Documenta estas capacidades con el propietario del origen antes de elegir una herramienta, porque ningún conector puede reconstruir información que la fuente no conserva ni expone.

Elige una referencia que puedas recuperar

Una marca de agua registra hasta dónde se ha procesado con éxito. Puede ser una fecha, una secuencia o una posición en un registro de cambios. Debe guardarse de manera duradera y avanzar después de confirmar la aplicación del lote, no al empezar a leerlo. Si se utiliza una fecha, considera registros con la misma marca y relojes de sistemas distintos. Una pequeña ventana de solapamiento puede capturar modificaciones tardías, siempre que el destino sepa reconocer y aplicar nuevamente un registro sin duplicarlo.

La captura de cambios desde el registro de la base de datos ofrece otra opción. PostgreSQL, por ejemplo, documenta mecanismos de replicación lógica basados en publicaciones y suscripciones. Su existencia no elimina el diseño operativo: hay que revisar compatibilidad, permisos, retención, modificaciones del esquema y recuperación. No conviene activar una solución de este tipo únicamente porque parece más moderna si una carga por lotes satisface las necesidades con menos complejidad.

Separa recepción y publicación

Guardar primero el lote recibido en un área de trabajo facilita comprobarlo antes de modificar las tablas que consumen los informes. Valida estructura, claves, volúmenes y límites temporales; después aplica el resultado de forma controlada. Si el proceso se interrumpe, debería ser posible identificar qué lote quedó pendiente y repetirlo. Conserva metadatos del origen y de la ejecución para investigar diferencias. No almacenes datos adicionales indefinidamente por comodidad: acuerda también su periodo de conservación y acceso.

• Identifica cada ejecución y registra su rango de lectura.
• Valida los registros recibidos antes de publicarlos al consumidor.
• Aplica altas, cambios y bajas con una clave estable del origen.
• Confirma el punto de control después de completar el lote.
• Prepara un procedimiento para repetir un rango y verificar el resultado.

Trata los borrados como parte del contrato

Un registro eliminado puede seguir apareciendo durante meses en analítica si solo se consultan altas y modificaciones. Algunas fuentes ofrecen una marca de baja; otras publican eventos de eliminación o requieren comparar conjuntos. Decide si el destino debe eliminar el registro, conservarlo como histórico o excluirlo de determinadas métricas. La respuesta depende del uso autorizado y del proceso, no de una preferencia del desarrollador. Incluye casos de borrado en las pruebas de aceptación y en los controles posteriores.

Reconcilia incluso cuando todo termina en verde

Una ejecución correcta demuestra que el programa terminó, pero no que los dos sistemas coincidan. Programa comparaciones de recuentos, sumas de control o muestras por periodos cerrados. Si aparece una diferencia, reduce el intervalo hasta localizar su origen. Un ejemplo hipotético es una corrección aplicada con una fecha antigua que no actualiza el campo de modificación: la carga incremental puede ignorarla, mientras una reconciliación mensual la detectaría. Estos controles permiten revisar supuestos que dejaron de cumplirse.

Mide la antigüedad que percibe el usuario

Controla cuándo se produjo el último cambio incorporado, cuánto tarda en llegar y si existen lotes pendientes. Un informe que se refresca cada cinco minutos puede seguir mostrando datos de ayer si falló la extracción. Presenta la fecha de la última carga validada y define qué sucede cuando supera el límite acordado. Para cerrar el diseño, simula una interrupción, un lote duplicado y una modificación tardía. La ingestión está preparada cuando el equipo puede recuperar cada caso sin improvisar ni reconstruir todo el histórico.