O Time Travel permite consultar dados históricos em uma tabela transacional (Delta) em qualquer limite de transação passado dentro da janela de retenção configurada. É possível ler os dados conforme existiam em um carimbo de data/hora ou ID de versão específico, além de restaurar uma tabela para um estado anterior.
Casos de uso
Recuperação de erros: Consulte a tabela em um ponto anterior a uma gravação incorreta, falha de pipeline ou exclusão acidental e utilize esses resultados para corrigir dados downstream.
Auditorias históricas: Inspecione o estado exato de um conjunto de dados em qualquer limite de transação passado para verificações de conformidade e investigações de linhagem de dados.
Comparação de dados: Compare dados em duas versões históricas diferentes para entender como os registros mudaram entre execuções de processamento.
Restauração pontual: Reverta uma tabela inteira para uma versão histórica específica a fim de desfazer um lote de alterações.
Pré-requisitos
O Time Travel é suportado apenas em tabelas transacionais. Tabelas não transacionais e tabelas externas não oferecem suporte a este recurso.
Os dados históricos ficam disponíveis somente dentro da janela de retenção configurada. Para reter dados históricos, defina a propriedade de tabela acid.data.retain.hours. Consulte Configure retenção de dados para obter detalhes.
Consultar dados históricos
Consulta por carimbo de data/hora
Utilize TIMESTAMP AS OF para ler a tabela conforme ela existia em um momento específico.
-- Query using a specific timestamp
SELECT * FROM src TIMESTAMP AS OF '2024-01-15 10:00:00';
-- Query using the timestamp of the last committed version
SELECT * FROM src TIMESTAMP AS OF get_latest_timestamp(1);
A função get_latest_timestamp aceita um parâmetro: o número de commits a serem consultados retroativamente. get_latest_timestamp(1) retorna o carimbo de data/hora da versão commitada mais recentemente.
Consulta por ID de versão
Use VERSION AS OF para ler a tabela em um ID de versão de transação específico.
-- Query using a specific version ID
SELECT * FROM src VERSION AS OF 3;
-- Query using the version ID of the last committed version
SELECT * FROM src VERSION AS OF get_latest_version(2);
A função get_latest_version recebe um parâmetro: a quantidade de commits anteriores a considerar. get_latest_version(2) devolve o ID de versão correspondente a dois commits antes da versão mais recente.
Restaurar uma tabela para uma versão histórica
Execute restore para substituir o estado atual da tabela pelos dados de uma versão histórica. Esta operação é irreversível.
-- Restore to a specific timestamp
RESTORE TABLE src TO TIMESTAMP AS OF '2024-01-15 10:00:00';
-- Restore to a specific version ID
RESTORE TABLE src TO VERSION AS OF 3;
Tipos de versão de transação
O Time Travel oferece suporte a dois tipos de versão:
|
Tipo de versão |
Descrição |
Cláusula SQL |
|
Versão temporal |
Identifica uma transação pelo carimbo de data/hora |
|
|
Versão por ID |
Identifica uma transação pelo seu ID de versão interno |
|
Utilize get_latest_timestamp e get_latest_version quando precisar referenciar uma versão relativa ao commit mais recente, em vez de usar um valor absoluto. O segundo parâmetro de ambas as funções indica quantas vezes os dados foram commitados anteriormente, informação que o MaxCompute utiliza para resolver a versão interna de dados correspondente.
Configure retenção de dados
A propriedade de tabela acid.data.retain.hours controla por quanto tempo os dados históricos são mantidos. Defina-a com ALTER TABLE:
-- Set a 48-hour retention window
ALTER TABLE src SET TBLPROPERTIES ('acid.data.retain.hours' = '48');
O período máximo de retenção é de sete dias. Escolha um valor adequado aos seus requisitos operacionais. Um período de retenção maior eleva os custos de armazenamento, pois o MaxCompute precisa preservar os arquivos Delta históricos.
Para desativar o Time Travel e reduzir custos de armazenamento, defina acid.data.retain.hours como 0:
-- Disable Time Travel for a table
ALTER TABLE src SET TBLPROPERTIES ('acid.data.retain.hours' = '0');
Definir a propriedade como 0 interrompe a retenção de dados históricos e reduz significativamente os custos de armazenamento.
Como funciona
O diagrama a seguir ilustra o processo interno de consulta para uma operação de Time Travel em uma tabela transacional.
Ao executar uma consulta de Time Travel, o MaxCompute:
Analisa a instrução SQL e identifica a versão alvo (carimbo de data/hora ou ID de versão).
Localiza o arquivo base mais recente que esteja dentro do intervalo de tempo dessa versão.
Encontra os arquivos delta gravados após a geração do arquivo base até a versão alvo.
Mescla o arquivo base e os arquivos Delta relevantes para gerar a saída da consulta.
**Exemplo: tabela transacional src**
Considere uma tabela transacional chamada src com as colunas pk e val. Cinco transações de gravação ocorrem nos momentos t1 a t5, produzindo cinco arquivos Delta. A Compactação é executada em t2 e t4, gerando os arquivos base b1 e b2, respectivamente.
Durante a compactação em t2, o registro de estado intermediário histórico (2,a) é removido do arquivo base b1, e apenas o registro de estado mais recente (2,b) permanece em b1.
|
Momento da consulta |
Arquivos lidos |
Resultado |
|
t1 |
Apenas arquivo Delta d1 |
Saída de d1 |
|
t2 |
Apenas arquivo base b1 |
Três registros |
|
t3 |
Arquivo base b1 + arquivo Delta d3 |
Saída mesclada |
|
t4, t5 |
Arquivo base b2 + arquivos Delta relevantes |
Saída mesclada |
Os arquivos base melhoram a eficiência de consultas e leituras ao fornecer um snapshot compacto e mesclado do estado da tabela em um determinado ponto. No entanto, consultas em arquivos base disparam operações de compactação que consomem muitos recursos. Escolha uma política de acionamento de compactação adequada à sua carga de trabalho.
Limitações
O Time Travel é suportado exclusivamente em tabelas transacionais (Delta). Tabelas não transacionais e externas não são compatíveis.
Dados históricos anteriores à janela de retenção configurada deixam de estar disponíveis para consulta ou restauração.
Independentemente da configuração de
acid.data.retain.hours, o período máximo de retenção é de sete dias.Definir
acid.data.retain.hourscomo0desativa o Time Travel e remove a retenção de dados históricos da tabela.