Restaurar tabelas Delta

Com o Delta Lake, você pode usar o RESTORE comando para tornar um estado de tabela mais antigo atual novamente. RESTORE restaura uma tabela Delta para uma versão anterior da tabela ou para o estado da tabela em um timestamp específico.

Use RESTORE quando precisar se recuperar rapidamente de uma alteração incorreta sem recriar manualmente a tabela. Como as tabelas Delta mantêm o histórico de transações, muitas vezes você pode reverter para um estado válido conhecido com um único comando.

O que o RESTORE faz

RESTORE altera o estado atual de uma tabela Delta para que ela corresponda a uma versão confirmada anteriormente.

Você pode restaurar uma tabela quando precisar:

  • Recuperação após exclusões ou atualizações acidentais
  • Desfazer uma operação inválida de MERGE, sobrescrita ou acréscimo
  • Reverter uma alteração de esquema que divide cargas de trabalho downstream
  • Recuperar-se de corrupção introduzida por uma gravação com falha ou uma etapa do pipeline com falha

Ao contrário de uma consulta histórica apenas de leitura, RESTORE altera o estado da tabela ativa vista por novos leitores.

Sintaxe

Use qualquer um desses formulários para restaurar uma tabela Delta.

Restaurar para uma versão específica da tabela Delta:

RESTORE TABLE schema_name.table_name TO VERSION AS OF 5

Restaurar a tabela para o estado em um timestamp específico:

RESTORE TABLE schema_name.table_name TO TIMESTAMP AS OF '2026-05-01 12:00:00'

Antes de restaurar, inspecione o histórico da tabela para que você possa escolher a versão correta:

DESCRIBE HISTORY schema_name.table_name

Um fluxo de trabalho de restauração comum tem esta aparência:

DESCRIBE HISTORY dbo.orders;
RESTORE TABLE dbo.orders TO VERSION AS OF 42

Os métodos PySpark DeltaTable executam a mesma operação lógica que o comando SQL RESTORE TABLE .

O que acontece durante a restauração

Quando você executa RESTORE, o Delta Lake não sobrescreve a versão de destino no mesmo local. Em vez disso, ele cria uma nova versão no log Delta que aponta de volta para os arquivos de dados associados à versão ou carimbo de data/hora selecionado.

Esse comportamento tem algumas consequências importantes:

  • RESTORE cria uma nova versão atual da tabela.
  • Os arquivos do ponto restaurado ficam ativos novamente.
  • Os arquivos do estado atual de pré-restauração não são excluídos imediatamente.
  • Esses arquivos agora não referenciados podem ser limpos posteriormente com VACUUM.
  • A restauração em si é registrada como uma alteração de tabela versionada.

Como RESTORE é versionada, você pode inspecioná-la no histórico da tabela:

DESCRIBE HISTORY schema_name.table_name

RESTORE, viagem no tempo e VACUUM

RESTORE e viagens no tempo usam o mesmo histórico do Delta, mas resolvem problemas diferentes.

  • Use a viagem no tempo quando você só precisa ler dados mais antigos sem alterar o estado atual da tabela.
  • Use RESTORE quando quiser que o estado mais antigo se torne o estado atual para todas as novas leituras e gravações.

VACUUM afeta a recuperação porque remove arquivos não referenciados do armazenamento. Após uma restauração, os arquivos do estado anteriormente atual geralmente ficam sem referência. Se você não precisar mais deles, você pode limpá-los com VACUUM.

O inverso também é importante: VACUUM pode impedir uma restauração futura. Se VACUUM já tiver removido os arquivos necessários para a versão que você deseja recuperar, RESTORE falhará porque o histórico da tabela não tem mais acesso a esses arquivos físicos.

Limitações

RESTORE só funciona quando a versão de destino ainda tem todos os arquivos de dados necessários disponíveis.

Tenha esses limites em mente:

  • Você pode restaurar apenas para versões cujos arquivos de dados ainda existem.
  • Se VACUUM esses arquivos forem removidos, a operação de restauração falhará.
  • O histórico de restauração é determinado pelas configurações de retenção Delta, incluindo delta.logRetentionDuration, e pela retenção real dos arquivos de dados no armazenamento.
  • Na prática, tanto a retenção do log de transações quanto a retenção de arquivos afetam até que ponto no tempo você pode restaurar.

Práticas recomendadas

Use estas práticas para reduzir o risco:

  • Execute DESCRIBE HISTORY antes de restaurar para confirmar a versão ou o carimbo de data/hora correto.
  • Use as consultas de viagem no tempo primeiro se você só precisar inspecionar dados mais antigos e não quiser alterar o estado atual da tabela.
  • Execute VACUUM após uma restauração quando quiser limpar arquivos não referenciados do estado de pré-restauração.
  • Teste o caminho de restauração em uma tabela clone primeiro quando estiver trabalhando com dados críticos de produção.

Conteúdo relacionado

  • Last updated on