Diseñar e implementar una tabla temporal (historial) para registrar los cambios a lo largo del tiempo

Las canalizaciones de datos suelen requerir el seguimiento no solo de los valores actuales, sino de todos los cambios que se producen con el tiempo. Las tablas temporales proporcionan un mecanismo para registrar los cambios de nivel de fila automáticamente, lo que permite realizar consultas a un momento dado y completar seguimientos de auditoría. A diferencia de las dimensiones de variación lenta que se centran en el historial de datos empresariales, las tablas temporales capturan el historial técnico para la rastreabilidad operativa y la depuración.

Comprender las tablas temporales frente a las tablas SCD Tipo 2

Las tablas temporales y las dimensiones de tipo 2 de SCD sirven para diferentes propósitos, aunque ambas realizan un seguimiento de los cambios históricos. Comprender cuándo usar cada enfoque le ayuda a diseñar soluciones adecuadas.

SCD Type 2 realiza un seguimiento de los cambios en las entidades empresariales a lo largo del tiempo para los informes analíticos. Cuando un cliente se mueve de Seattle a Portland, quiere atribuir las ventas históricas a la ubicación del cliente en el momento de cada transacción. SCD Type 2 mantiene versiones significativas para la empresa con fechas de inicio y finalización explícitas.

Las tablas temporales (historial) capturan los cambios técnicos para las necesidades operativas. Al solucionar problemas de por qué los datos se cargaron incorrectamente, debe ver exactamente qué valores existían en cada momento, qué archivos se procesaron y cuándo se produjeron cambios. Las tablas temporales proporcionan esta funcionalidad forense automáticamente.

Considere la posibilidad de usar tablas temporales cuando necesite:

• Solución de problemas de la ingesta de datos mediante el examen del estado de la tabla en momentos específicos en el tiempo
• Auditar todos los cambios de cumplimiento o requisitos normativos
• Reproducir análisis o informes desde un momento dado específico
• Seguimiento de metadatos operativos, como los tiempos de carga y la información del archivo de origen

Habilitar el flujo de datos de cambios para el seguimiento a nivel de fila

El flujo de datos de cambios de Delta Lake captura automáticamente todos los cambios a nivel de fila. Cuando está habilitada, el tiempo de ejecución registra eventos de cambio con metadatos que indican si cada fila se insertó, eliminó o actualizó. La fuente de datos de cambio está deshabilitada de manera predeterminada, por lo que debe habilitarla explícitamente en las tablas donde necesita esta capacidad.

Para habilitar el flujo de datos de cambios en una nueva tabla:

CREATE TABLE bronze.sales_transactions (
    transaction_id STRING,
    customer_id STRING,
    amount DECIMAL(10,2),
    transaction_date TIMESTAMP,
    source_file STRING,
    load_timestamp TIMESTAMP
)
USING DELTA
TBLPROPERTIES (delta.enableChangeDataFeed = true);

Para las tablas existentes, habilite la fuente de datos de cambio con una ALTER TABLE declaración:

ALTER TABLE bronze.sales_transactions 
SET TBLPROPERTIES (delta.enableChangeDataFeed = true);

Historial de tablas de consulta

Una vez habilitada la fuente de distribución de datos de cambios, puede consultar el historial de cambios para ver exactamente qué modificaciones se produjeron. El flujo de datos de cambios agrega tres columnas de metadatos a tus datos:

Consulta de cambios dentro de un intervalo de tiempo específico:

SELECT 
    transaction_id,
    amount,
    _change_type,
    _commit_version,
    _commit_timestamp
FROM table_changes('bronze.sales_transactions', '2026-01-01', '2026-01-31')
WHERE _change_type IN ('insert', 'update_postimage')
ORDER BY _commit_timestamp;

Esta consulta ayuda a identificar cuándo se modificaron registros específicos, lo que resulta útil para depurar problemas de calidad de datos.

Uso del viaje en el tiempo para consultas en un momento específico

Delta Lake mantiene un registro de transacciones que permite consultar datos tal como existían en cualquier punto del historial. Esta funcionalidad admite escenarios de depuración en los que es necesario comparar los datos actuales con un estado anterior.

Consulta de datos en una marca de tiempo específica:

SELECT * FROM bronze.sales_transactions
TIMESTAMP AS OF '2026-01-15 14:30:00';

Consulta de datos en una versión específica:

SELECT * FROM bronze.sales_transactions
VERSION AS OF 42;

Para ver el historial completo de operaciones realizadas en una tabla:

DESCRIBE HISTORY bronze.sales_transactions;

La salida del historial incluye el tipo de operación, la marca de tiempo, el usuario y las métricas detalladas de cada cambio.

Conservar el historial de cambios para la auditoría a largo plazo

Debido a que el viaje en el tiempo integrado de Delta Lake tiene límites de retención, debe conservar los datos modificados en una tabla de historial separada para los requisitos de auditoría a largo plazo. Este enfoque crea un registro permanente de todos los cambios.

Use Structured Streaming para capturar continuamente los cambios:

(spark.readStream
    .option("readChangeFeed", "true")
    .option("ignoreDeletes", "false")
    .table("bronze.sales_transactions")
    .writeStream
    .option("checkpointLocation", "/checkpoints/sales_history")
    .trigger(availableNow=True)
    .toTable("audit.sales_transactions_history")
)

La readChangeFeed opción indica a Spark que lea el flujo de datos de cambios, que devuelve eventos de cambio a nivel de fila, incluidas inserciones, actualizaciones y eliminaciones. La ignoreDeletes opción controla si las operaciones de eliminación se incluyen en el flujo. Si se establece en false , se garantiza que los registros de eliminación se capturan en la tabla de historial, lo que proporciona una pista de auditoría completa de todos los cambios de datos.

La tabla de historial contiene todos los eventos de cambio con metadatos completos, lo que permite realizar consultas durante toda la duración de los datos, no solo la ventana de retención.

Configurar la conservación de datos para los requisitos de cumplimiento

Para las tablas temporales que admiten el cumplimiento o las necesidades normativas, configure las opciones de retención para que coincidan con sus requisitos:

ALTER TABLE bronze.sales_transactions 
SET TBLPROPERTIES (
    delta.logRetentionDuration = 'interval 90 days',
    delta.deletedFileRetentionDuration = 'interval 90 days'
);

Ambas propiedades deben establecerse juntas. Controla logRetentionDuration cuánto tiempo se conservan los metadatos del historial, mientras que deletedFileRetentionDuration controla cuánto tiempo se conservan los archivos de datos eliminados antes VACUUM de quitarlos.

Los períodos de retención más largos aumentan los costos de almacenamiento, pero brindan mayor acceso en el tiempo y cambian la disponibilidad de la fuente de datos para auditoría.

Con las tablas temporales configuradas correctamente, puede realizar un seguimiento de todos los cambios en los datos desde la ingesta hasta la transformación, apoyando tanto la solución de problemas operativos como los requisitos de cumplimiento normativo.