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

Pipelines de dados frequentemente exigem acompanhamento não só dos valores atuais, mas de todas as alterações que ocorrem ao longo do tempo. As tabelas temporais fornecem um mecanismo para registar automaticamente alterações ao nível das linhas, permitindo consultas em ponto em tempo e registos completos de auditoria. Ao contrário das dimensões que mudam lentamente e se focam no histórico de dados empresariais, as tabelas temporais capturam o histórico técnico para rastreabilidade operacional e depuração.

Compreender tabelas temporais versus SCD Tipo 2

Tabelas temporais e dimensões SCD Tipo 2 servem propósitos diferentes, embora ambas acompanhem alterações históricas. Compreender quando usar cada abordagem ajuda-o a desenhar soluções adequadas.

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

Tabelas temporais capturam mudanças técnicas para necessidades operacionais. Ao tentar resolver porque é que os dados carregaram incorretamente, precisa de ver exatamente quais os valores que existiam em cada momento, que ficheiros foram processados e quando ocorreram alterações. As tabelas temporais fornecem esta capacidade forense automaticamente.

Considere usar tabelas temporais quando precisar:

• Depurar problemas de ingestão de dados examinando o estado da tabela em carimbos temporais específicos
• Auditar todas as alterações quanto à conformidade ou requisitos regulamentares
• Reproduzir análises ou relatórios de um momento específico no tempo
• Acompanhar metadados operacionais, como tempos de carregamento e informação do ficheiro de origem,

Ativar o feed de dados de alterações para o rastreamento ao nível da linha

O feed de dados de alterações do Delta Lake capta automaticamente todas as alterações ao nível da linha. Quando ativados, os registos de execução alteram os eventos com metadados a indicar se cada linha foi inserida, eliminada ou atualizada. O feed de alterações de dados está desativado por defeito, por isso tens de o ativar explicitamente nas tabelas onde precisas desta funcionalidade.

Para ativar a transmissão de dados de alteração 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, ative o fluxo de dados de alteração com uma instrução ALTER TABLE.

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

Histórico da tabela de consultas

Depois de ativado o feed de dados de alterações, pode consultar o histórico de alterações para ver exatamente que 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;

Esta consulta ajuda a identificar quando registos específicos foram modificados, o que é valioso para depurar questões de qualidade dos dados.

Utilize versões temporais para consultas de ponto no tempo

A Delta Lake mantém um registo de transações que permite consultar dados tal como existiam em qualquer momento da história. Esta capacidade suporta cenários de depuração nos quais precisa de comparar dados atuais com um estado anterior.

Consultar dados numa marca temporal específica:

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

Consultar dados numa versão específica:

SELECT * FROM bronze.sales_transactions
VERSION AS OF 42;

Para ver o histórico completo das operações realizadas numa tabela:

DESCRIBE HISTORY bronze.sales_transactions;

O registo de histórico inclui o tipo de operação, data e hora, utilizador e métricas detalhadas de cada alteração.

Persistir o histórico de alterações para auditorias de longo prazo

Como a viagem temporal incorporada da Delta Lake tem limites de retenção, deve guardar os dados das alterações numa tabela de histórico separada para atender aos requisitos de auditoria a longo prazo. Esta abordagem cria um registo permanente de todas as alterações.

Use o Structured Streaming para captar continuamente as mudanças:

(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 instrui o Spark a ler o feed de dados de alteração, que devolve eventos de alteração ao nível da linha, incluindo inserções, atualizações e eliminação. A ignoreDeletes opção controla se as operações de eliminação estão incluídas no fluxo. Configurar para false assegura que os registos de eliminação são capturados na tabela de histórico, proporcionando um rasto completo de auditoria 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 ao longo de toda a vida útil dos seus dados — não apenas na janela de retenção.

Configurar a retenção para os requisitos de conformidade

Para tabelas temporais que suportam necessidades de conformidade ou regulatórias, configure as definições de retenção para corresponderem aos seus requisitos:

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

Ambas as propriedades devem ser definidas em conjunto. Controla logRetentionDuration durante quanto tempo os metadados de histórico são mantidos, enquanto deletedFileRetentionDuration controla quanto tempo os ficheiros de dados apagados são preservados antes VACUUM de os remover.

Períodos de retenção mais longos aumentam os custos de armazenamento, mas proporcionam acesso prolongado a viagens no tempo e alteram a disponibilidade do feed de dados para auditoria.

Com tabelas temporais devidamente configuradas, pode rastrear todas as alterações nos seus dados desde a ingestão até à transformação, suportando tanto a depuração operacional como os requisitos de conformidade regulatória.