Qual problema formatos de tabela como Iceberg e Delta Lake resolvem que Parquet puro em object storage não resolve?

Arquivos Parquet soltos em um bucket não dão transação nenhuma, então um leitor pode ver um diretório escrito pela metade e um job que falhou deixa dados parciais. Formatos de tabela adicionam uma camada de metadados com commits atômicos e isolamento por snapshot, então as escritas aparecem de uma vez só. Eles também trazem evolução de schema, updates e deletes em nível de linha, viagem no tempo para snapshots anteriores e poda de arquivos por estatísticas em vez de listagem de diretório.

Com Parquet puro a tabela é na verdade só uma convenção de diretório, então não existe atomicidade. Se um job morre no meio, os leitores enxergam dados parciais, e não tem como atualizar ou apagar uma única linha sem reescrever partições inteiras na mão. Formatos de tabela resolvem isso com uma camada de metadados. Um commit troca o ponteiro para um novo snapshot de forma atômica, então os leitores veem ou o estado antigo ou o novo, nunca uma mistura, e você ganha viagem no tempo quase de graça porque os snapshots antigos continuam existindo. Essa última parte nos salvou uma vez, quando uma transformação ruim sobrescreveu um mart e recuperamos consultando o snapshot anterior em vez de restaurar de backup. A outra coisa que eu gosto no Iceberg especificamente é o particionamento oculto, em que a própria tabela rastreia a transformação de partição, então um analista que filtra por um timestamp ganha poda sem saber do layout. O custo é manutenção: você precisa de compactação agendada de arquivos pequenos e de expiração de snapshots, ou os metadados crescem sem limite.