Cómo auditar cargas de datos en ELT: paso a paso

Registrar quién cargó qué, cuándo y con qué resultado es lo que separa un pipeline ELT fiable de una caja negra. Auditar las cargas de datos en ELT te permite investigar errores con rapidez, demostrar el origen de cada número y responder a una auditoría sin adivinar.

Requisitos previos

• Una base de datos SQL Server o Azure SQL (los ejemplos usan T-SQL).
• Una tabla de destino ya existente donde cargas los datos.
• Permisos para crear y modificar tablas (CREATE TABLE, ALTER TABLE).
• Conocimientos básicos de SQL: INSERT, UPDATE y SELECT.

Paso 1: Decidir qué auditar

Antes de escribir SQL, define el mínimo útil. En una carga ELT hay cuatro preguntas que siempre importan: de dónde vinieron los datos, cuándo entraron, cuántas filas se procesaron y si la carga terminó con éxito. Vamos a responderlas todas con dos piezas sencillas: columnas de auditoría en cada tabla de destino y una tabla de log central que guarda el histórico de ejecuciones.

Mantén la tabla de log separada de los datos de negocio. Así puedes archivarla o limpiarla sin tocar tus tablas de negocio.

Paso 2: Añadir columnas de auditoría a la tabla de destino

Las columnas de auditoría acompañan a cada fila y te dicen de qué carga proviene. Añade un identificador de lote, la fecha y hora de carga y el sistema de origen.

ALTER TABLE vendas
    ADD batch_id       BIGINT,
        data_carga     DATETIME2,
        sistema_origem VARCHAR(50);

A partir de aquí, cada fila cargada queda "sellada" y puede vincularse a una ejecución concreta.

Paso 3: Crear la tabla de log de cargas

La tabla de log es el diario de tu pipeline: una fila por cada ejecución. Créala una sola vez.

CREATE TABLE etl_load_log (
    batch_id       BIGINT IDENTITY(1,1) PRIMARY KEY,
    tabela_destino VARCHAR(100),
    inicio         DATETIME2,
    fim            DATETIME2,
    linhas         INT,
    estado         VARCHAR(20)
);

Paso 4: Registrar el inicio de la carga

Al arrancar cada carga, insertamos una fila con el estado RUNNING y guardamos el batch_id generado para reutilizarlo en los pasos siguientes.

DECLARE @batch_id BIGINT;

INSERT INTO etl_load_log (tabela_destino, inicio, estado)
VALUES ('vendas', SYSDATETIME(), 'RUNNING');

SET @batch_id = SCOPE_IDENTITY();

Paso 5: Cargar los datos y sellar las filas

Ahora ejecuta la transformación y la carga habituales, rellenando las columnas de auditoría con el batch_id de la ejecución actual. Guarda también el número de filas insertadas con @@ROWCOUNT.

DECLARE @linhas INT;

INSERT INTO vendas (id, valor, batch_id, data_carga, sistema_origem)
SELECT s.id, s.valor, @batch_id, SYSDATETIME(), 'loja_online'
FROM   staging_vendas AS s;

SET @linhas = @@ROWCOUNT;

Paso 6: Cerrar el registro con el resultado

Cuando la carga termina, actualizamos la misma fila del log con la hora de fin, el número de filas afectadas y el estado final.

UPDATE etl_load_log
SET    fim    = SYSDATETIME(),
       linhas = @linhas,
       estado = 'SUCCESS'
WHERE  batch_id = @batch_id;

Si algún paso falla, envuelve la carga en un bloque TRY...CATCH y graba el estado FAILED en lugar de SUCCESS. Así distingues de inmediato las ejecuciones con problemas.

Verificar el resultado

Consulta la tabla de log para ver el histórico de las últimas cargas. Debe aparecer una fila por ejecución, con inicio, fin, número de filas y el estado SUCCESS.

SELECT batch_id, tabela_destino, inicio, fim, linhas, estado
FROM   etl_load_log
ORDER  BY batch_id DESC;

Para confirmar la trazabilidad, elige un batch_id y cuenta las filas correspondientes en la tabla de destino: el total debe coincidir con el valor guardado en el log.

SELECT COUNT(*) FROM vendas WHERE batch_id = 1;

Conclusión

Con columnas de auditoría y una tabla de log ahora sabes, para cada fila, de dónde vino y en qué carga entró: la base para investigar errores y confiar en los números que presentas. El siguiente paso natural es construir un pequeño panel sobre etl_load_log con las cargas fallidas y la duración media de cada carga. ¿Qué métrica sería más útil vigilar primero en tu pipeline: las cargas que fallan o las que tardan demasiado?