Cómo crear una snapshot incremental en Modelado de Datos (Kimball)

João Barros 30 de July de 2026 4 min de lectura

Este tutorial muestra cómo implementar una snapshot incremental (periodic snapshot) en un esquema Kimball para registrar el estado de un objeto a lo largo del tiempo, cubriendo por qué es útil y reduciendo almacenamiento y trabajo ETL. La snapshot incremental es útil cuando solo nos interesan versiones periódicas de una fact (p. ej.: saldo de cuenta) y queremos optimizar cargas y consultas.

Pre-requisitos

Conocimientos básicos de Modelado Kimball (fact y dimensión).
Entorno SQL (por ejemplo SQL Server, PostgreSQL o Azure SQL).
Fuente transaccional o tabla staging con registros de cambios.

Paso 1: Definir el caso de uso y granularidad

Decida qué objeto y qué periodicidad desea capturar. Ejemplo: saldo diario por cuenta bancaria. La granularidad determina las claves de la fact (account_id + snapshot_date) y qué medidas serán agregadas (balance, transactions_count).

Paso 2: Crear la estructura de la tabla de snapshot

Cree una tabla fact que almacene solo un registro por clave de granularidad por período. Incluya campos para identificar si el registro es incremental (updated_flag) y para control de fecha de extracción.

CREATE TABLE fact_account_snapshot (
  account_id INT NOT NULL,
  snapshot_date DATE NOT NULL,
  balance DECIMAL(18,2),
  transactions_count INT,
  updated_flag BIT DEFAULT 0,
  load_ts DATETIME2 DEFAULT SYSUTCDATETIME(),
  PRIMARY KEY (account_id, snapshot_date)
);

La clave primaria garantiza unicidad por período. El campo updated_flag ayuda a identificar registros modificados en una carga incremental.

Paso 3: Preparar la tabla staging con datos actuales

En la etapa ETL/ELT, traiga el estado actual de las cuentas a una staging con la misma granularidad. Puede ser una SELECT desde la fuente transaccional o una view que calcula el saldo hasta la fecha de snapshot.

-- Exemplo de staging com estado actual
CREATE TABLE stg_account_state (
  account_id INT,
  snapshot_date DATE,
  balance DECIMAL(18,2),
  transactions_count INT
);

-- Inserir dados de exemplo
INSERT INTO stg_account_state (account_id, snapshot_date, balance, transactions_count)
VALUES (1, '2026-07-01', 1250.00, 3), (2, '2026-07-01', 540.50, 1);

Paso 4: Lógica incremental (UPSERT) para cargar la snapshot

Ejecute un MERGE/UPSERT que compare staging con la fact existente por (account_id, snapshot_date). Solo actualice si existe diferencia en las medidas — esto reduce escritura y preserva el historial de snapshots anteriores.

-- Exemplo MERGE (SQL Server / Azure SQL)
MERGE INTO fact_account_snapshot AS target
USING stg_account_state AS src
  ON target.account_id = src.account_id
  AND target.snapshot_date = src.snapshot_date
WHEN MATCHED AND (
  ISNULL(target.balance,0) <> ISNULL(src.balance,0)
  OR ISNULL(target.transactions_count,0) <> ISNULL(src.transactions_count,0)
) THEN
  UPDATE SET
    target.balance = src.balance,
    target.transactions_count = src.transactions_count,
    target.updated_flag = 1,
    target.load_ts = SYSUTCDATETIME()
WHEN NOT MATCHED BY TARGET THEN
  INSERT (account_id, snapshot_date, balance, transactions_count, updated_flag)
  VALUES (src.account_id, src.snapshot_date, src.balance, src.transactions_count, 1);

Si usa PostgreSQL, sustituya MERGE por INSERT ... ON CONFLICT DO UPDATE o lógica equivalente.

Paso 5: Limpieza y retención

Defina una política de retención de las snapshots. Si no necesita todas las fechas, puede compactar (por ejemplo mantener diario 90 días, luego semanal) o eliminar snapshots duplicadas sin cambios.

-- Exemplo: eliminar snapshots sem alterações antigas
DELETE FROM fact_account_snapshot
WHERE updated_flag = 0
  AND snapshot_date < DATEADD(day, -365, CAST(GETDATE() AS date));

-- Depois da limpeza, repor updated_flag a 0 para a próxima carga
UPDATE fact_account_snapshot SET updated_flag = 0 WHERE updated_flag = 1;

Verificar el resultado

Confirme que existe un registro por (account_id, snapshot_date) y que solo los registros alterados fueron actualizados.

-- Contagem por chave
SELECT account_id, snapshot_date, COUNT(*) AS cnt
FROM fact_account_snapshot
GROUP BY account_id, snapshot_date
HAVING COUNT(*) > 1;

-- Registos marcados como actualizados na última carga
SELECT * FROM fact_account_snapshot WHERE updated_flag = 1 ORDER BY snapshot_date DESC;

Errores comunes: olvidar la clave única (genera duplicados), no comparar correctamente NULLs en las medidas, o no definir política de retención (crecimiento infinito).

Conclusión

Implementar una snapshot incremental en Modelado Kimball permite capturar estados a lo largo del tiempo con eficiencia y control. Próximos pasos: integrar la lógica en una pipeline automatizada (ETL/ELT), añadir dimensiones según necesidades analíticas y considerar compresión/particionamiento para rendimiento. Consejo: comience con una ventana pequeña de retención y monitorice el crecimiento antes de ampliar.