Iceberg - Time Travel, Deletes e Manutenção

Time travel

Time travel consulta um snapshot histórico ainda disponível. A leitura precisa dos metadados e arquivos que compõem aquele estado. Uma data sozinha não recupera dados cujos snapshots e arquivos já foram eliminados.

Exemplo em Spark SQL com integração Iceberg, substituindo o identificador por um snapshot real da tabela:

SELECT * FROM lake.vendas.eventos VERSION AS OF 123456789;

Tabelas de metadados ajudam a inspecionar snapshots e histórico. A sintaxe e a cobertura dessas consultas dependem do motor. Referência: consultas históricas e metadados.

Exclusão lógica e arquivos físicos

Apagar uma linha de uma tabela não precisa significar editar bytes no meio de um Parquet. Duas estratégias comuns nas integrações são:

No formato v2, arquivos de exclusão podem identificar posições em um arquivo ou valores de campos que identificam linhas. Recursos de versões posteriores e suporte dos motores precisam ser verificados: “lê Iceberg” não descreve todas as capacidades. Referência: especificação de row-level deletes.

Três operações de manutenção diferentes

Compactação: combina arquivos pequenos ou reorganiza dados para melhorar leitura. Produz uma nova versão; arquivos substituídos podem continuar necessários a snapshots antigos.

Expiração de snapshots: reduz o histórico retido. Pode permitir remover arquivos que deixaram de ser necessários às referências preservadas.

Remoção de órfãos: procura arquivos não referenciados pelos metadados válidos, por exemplo depois de uma escrita que não conseguiu publicar seu commit. Referência: manutenção.

Exemplo de um erro perigoso

Um upload grande começa às 10h. Às 10h05, uma limpeza considera órfão todo arquivo que não aparece no snapshot atual, sem prazo de segurança. O arquivo ainda em preparação pode ser apagado antes do commit das 10h10.

A limpeza precisa tolerar escritas em andamento e considerar as referências corretas. Do mesmo modo, uma regra genérica do bucket que apaga Parquet por idade não conhece a estrutura da tabela. O arquivo mais antigo pode continuar pertencendo ao snapshot atual.

Curiosidade: histórico e privacidade podem competir

Um DELETE pode retirar a linha do estado atual enquanto snapshots antigos ainda permitem consultá-la. O ciclo de retenção precisa considerar dados históricos, réplicas, backups e mecanismos do armazenamento. A semântica SQL de exclusão não descreve sozinha o momento em que todos os bytes deixam de existir.

Como o custo aparece

Arquivos pequenos aumentam o trabalho de planejamento e abertura. Muitos arquivos de exclusão podem aumentar a combinação na leitura. Reter snapshots por muito tempo conserva versões de dados. Compactação excessiva também custa: ela lê e escreve dados para beneficiar consultas futuras.

Aprofundamento aplicado

Retenção precisa considerar referências e leitores

Um arquivo substituído no snapshot atual pode continuar necessário a snapshots antigos, branches, tags ou consultas em andamento. Compactar e expirar snapshots têm propósitos diferentes; somente considerar idade do objeto não identifica o que está seguro apagar.

A remoção de órfãos também precisa tolerar arquivos preparados por escritores ainda não publicados. A janela deve considerar duração de jobs, retries e relógios, conforme as ferramentas usadas. Referência: manutenção.

Uma sequência de decisão

1. Identifique o problema: arquivos pequenos, excesso de deletes ou histórico acumulado.
2. Escolha a operação que trata esse problema.
3. Defina as referências e o período que devem permanecer utilizáveis.
4. Observe o custo e valide consultas no snapshot atual e nos históricos preservados.

Exercício: desenhe S1 com arquivos A/B e S2 com A/C. Se S1 for retido, B ainda é necessário; se S1 expirar, A continua necessário a S2. Resultado esperado: classificar arquivos por referência, sem confundir “antigo” com “inutilizado”.

Relacionado: 1. Iceberg por Dentro - Metadados, Snapshots e Commits · 3. Multipart, Checksums e Escritas Condicionais no S3.

---

Parte de 0. MOC Apache Iceberg