Como usar Time Travel numa tabela Delta no Databricks

João Barros 12 de July de 2026 5 min de leitura

O Time Travel numa tabela Delta no Databricks permite consultar os dados tal como estavam numa versão anterior ou num momento específico do passado, sem backups manuais. É a rede de segurança certa para quando um MERGE corre mal, um pipeline duplica linhas ou alguém pergunta que números existiam na semana passada. Com SQL e PySpark consegue inspecionar o histórico, ler uma versão antiga e restaurar a tabela em poucos minutos.

Pré-requisitos

Acesso a um workspace Databricks com um cluster ou SQL Warehouse ativo.
Uma tabela em formato Delta (por exemplo vendas) com pelo menos duas escritas feitas.
Permissões de leitura na tabela e, para restaurar, permissões de escrita (MODIFY no Unity Catalog).
Noções básicas de SQL. O PySpark é opcional.

Passo 1: Confirmar que a tabela é mesmo Delta

O Time Travel só existe em tabelas Delta. Antes de mais, confirme o formato num notebook ou no editor SQL:

DESCRIBE DETAIL vendas;

Na coluna format deve aparecer delta. Se aparecer parquet ou csv, não há histórico de versões e este exemplo não se aplica.

Passo 2: Ver o histórico de versões da tabela

Cada escrita (INSERT, UPDATE, DELETE, MERGE, OPTIMIZE) cria uma nova versão. O comando seguinte mostra essa lista:

DESCRIBE HISTORY vendas;

As colunas mais úteis são:

version: o número da versão (0, 1, 2, ...), que vai usar no Time Travel.
timestamp: quando a versão foi criada.
operation: o que aconteceu (WRITE, MERGE, DELETE...).
operationMetrics: quantas linhas foram inseridas, atualizadas ou apagadas.

Anote o número da última versão boa, ou seja, a anterior ao erro.

Passo 3: Consultar uma versão antiga com Time Travel

Há duas formas de viajar no tempo: por número de versão ou por data/hora.

-- Por versão
SELECT * FROM vendas VERSION AS OF 12;

-- Por data e hora
SELECT * FROM vendas TIMESTAMP AS OF '2026-07-11 09:00:00';

O mesmo em PySpark, útil quando quer trabalhar com o resultado num DataFrame:

df_antigo = (spark.read
    .format("delta")
    .option("versionAsOf", 12)
    .table("vendas"))

df_antigo.count()

Um erro comum aqui é pedir um TIMESTAMP AS OF mais antigo do que a primeira versão da tabela. O Databricks devolve um erro a dizer que a versão não existe: nesse caso use DESCRIBE HISTORY para escolher um timestamp válido.

Passo 4: Comparar duas versões para perceber o estrago

Antes de restaurar, vale a pena saber exatamente o que mudou. Comece pelas contagens:

SELECT
  (SELECT count(*) FROM vendas VERSION AS OF 12) AS antes,
  (SELECT count(*) FROM vendas) AS agora;

E depois veja as linhas que existem agora mas não existiam antes:

SELECT * FROM vendas
EXCEPT
SELECT * FROM vendas VERSION AS OF 12;

Se o resultado for exatamente o conjunto de linhas duplicadas ou erradas, já confirmou o diagnóstico.

Passo 5: Restaurar a tabela para uma versão anterior

Com a versão correta identificada, o restauro é uma linha:

RESTORE TABLE vendas TO VERSION AS OF 12;

-- Alternativa por data e hora
RESTORE TABLE vendas TO TIMESTAMP AS OF '2026-07-11 09:00:00';

Repare que o RESTORE não apaga o histórico: cria uma nova versão cujo conteúdo é igual ao da versão 12. Ou seja, o restauro também é reversível. Se preferir não mexer na tabela original, crie uma cópia:

CREATE TABLE vendas_backup
DEEP CLONE vendas VERSION AS OF 12;

Passo 6: Saber até quando pode viajar no tempo

O Time Travel depende dos ficheiros antigos ainda existirem. O comando VACUUM apaga ficheiros que já não são referenciados (por omissão, com mais de 7 dias), e o log de transações tem a sua própria retenção. Para alargar a janela numa tabela crítica:

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

Retenções maiores significam mais ficheiros guardados e mais custo de armazenamento. Ajuste apenas nas tabelas onde o histórico tem valor real.

Verificar o resultado

Depois do restauro, corra outra vez o histórico:

DESCRIBE HISTORY vendas;

Deve ver uma nova linha com operation = RESTORE no topo. Confirme então que os dados voltaram ao esperado:

SELECT count(*) FROM vendas;

Se a contagem coincide com a da versão 12 e a consulta do Passo 4 (EXCEPT) já não devolve linhas, o Time Travel fez o seu trabalho.

Conclusão

Com DESCRIBE HISTORY, VERSION AS OF e RESTORE TABLE tem um mecanismo simples de auditoria e recuperação para qualquer tabela Delta. O passo seguinte natural é automatizar: um teste de qualidade no fim do pipeline que, ao detetar uma anomalia, guarda o número da versão anterior para um restauro rápido. Uma dica final: antes de qualquer carga arriscada, corra DESCRIBE HISTORY e anote a versão atual — é o equivalente Delta a apertar o cinto. Já sabe qual é a janela de Time Travel das suas tabelas mais críticas?