Projetar e implementar uma tabela temporal (histórico) para registrar alterações ao longo do tempo

Os pipelines de dados geralmente exigem acompanhamento não apenas dos valores atuais, mas de todas as alterações que ocorrem ao longo do tempo. As tabelas temporais fornecem um mecanismo para registrar alterações em nível de linha de forma automática, habilitando consultas pontuais e trilhas de auditoria completas. Ao contrário das dimensões de alteração lenta que se concentram no histórico de dados de negócios, as tabelas temporais capturam o histórico técnico para rastreamento operacional e depuração.

Entender tabelas temporais versus SCD Tipo 2

As tabelas temporais e as dimensões SCD Tipo 2 atendem a diferentes finalidades, embora ambas acompanhem as alterações históricas. Entender quando usar cada abordagem ajuda você a criar soluções apropriadas.

O SCD Tipo 2 acompanha as alterações nas entidades de negócios ao longo do tempo para relatórios analíticos. Quando um cliente muda de Seattle para Portland, você deseja atribuir vendas históricas à localização do cliente no momento de cada transação. O SCD Type 2 mantém versões significativas para os negócios com datas de início e término explícitas.

Tabelas de histórico temporal capturam alterações técnicas para necessidades operacionais. Ao solucionar por que os dados foram carregados incorretamente, você precisa ver exatamente quais valores existiam em cada ponto no tempo, quais arquivos foram processados e quando ocorreram alterações. As tabelas temporais fornecem essa funcionalidade forense automaticamente.

Considere usar tabelas temporais quando precisar:

• Depurar problemas de ingestão de dados examinando o estado da tabela em timestamps específicos
• Auditar todas as alterações para conformidade ou requisitos regulatórios
• Reproduzir análises ou relatórios de um ponto específico no tempo
• Rastrear metadados operacionais, como tempos de carga e informações do arquivo de origem

Ativar feed de dados de alterações para rastreamento em nível de linha

O feed de dados de alteração do Delta Lake captura automaticamente todas as mudanças em nível de linha. Quando habilitado, os registros de runtime alteram eventos com metadados que indicam se cada linha foi inserida, excluída ou atualizada. O feed de dados de alteração é desabilitado por padrão, portanto, você deve habilitá-lo explicitamente em tabelas em que você precisa dessa funcionalidade.

Para habilitar o feed de dados de alterações em uma nova tabela:

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 tabelas existentes, habilite o feed de dados de alteração com um comando ALTER TABLE:

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

Consultar histórico da tabela

Depois que o feed de dados de alterações estiver habilitado, você poderá consultar o histórico de alterações para ver exatamente quais modificações ocorreram. O feed de dados de alteração adiciona três colunas de metadados aos seus dados:

Alterações de consulta dentro de um intervalo de tempo 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;

Essa consulta ajuda a identificar quando registros específicos foram modificados, o que é valioso para depurar problemas de qualidade de dados.

Usar a viagem no tempo para consultas em um ponto específico no tempo

O Delta Lake mantém um log de transações que permite consultar dados como eles existiam em qualquer ponto do histórico. Essa funcionalidade dá suporte a cenários de depuração em que você precisa comparar dados atuais com um estado anterior.

Consultar dados em um timestamp específico.

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

Consultar dados em uma versão específica:

SELECT * FROM bronze.sales_transactions
VERSION AS OF 42;

Para exibir o histórico completo de operações executadas em uma tabela:

DESCRIBE HISTORY bronze.sales_transactions;

A saída do histórico inclui o tipo de operação, o carimbo de data/hora, o usuário e métricas detalhadas para cada alteração.

Manter o histórico de alterações para auditoria de longo prazo

Como a viagem no tempo do Delta Lake tem limites de retenção, você deve manter dados de alteração em uma tabela de histórico separada para atender aos requisitos de auditoria de longo prazo. Essa abordagem cria um registro permanente de todas as alterações.

Use o Streaming Estruturado para capturar continuamente as alterações:

(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")
)

A opção readChangeFeed orienta o Spark a ler o feed de dados de alterações, que retorna eventos de mudança em nível de linha, incluindo inserções, atualizações e deleções. A ignoreDeletes opção controla se as operações de exclusão estão incluídas no fluxo. Defini-lo como false garante que os registros de exclusão sejam capturados na tabela de histórico, fornecendo um registro completo de todas as alterações de dados.

A tabela de histórico contém todos os eventos de alteração com metadados completos, permitindo consultas durante todo o tempo de vida de seus dados, não apenas a janela de retenção.

Configurar retenção para requisitos de conformidade

Para tabelas temporais que dão suporte a conformidade ou necessidades regulatórias, defina as configurações de retenção para corresponder aos seus requisitos:

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

Ambas propriedades devem ser definidas juntas. Os logRetentionDuration controlam quanto tempo os metadados de histórico são mantidos, enquanto deletedFileRetentionDuration controla por quanto tempo os arquivos de dados deletados são preservados antes que VACUUM os remova.

Períodos de retenção mais longos aumentam os custos de armazenamento, mas fornecem acesso de viagem por tempo estendido e alteram a disponibilidade do feed de dados para auditoria.

Com tabelas temporais devidamente configuradas, você consegue rastrear cada alteração em seus dados desde a ingestão até a transformação, apoiando tanto a depuração operacional quanto os requisitos de conformidade às normas regulatórias.