Iceberg, Delta e Hudi: table formats abertos
- ⬜📨 Kafka fundamentos: partições, consumer groups, exactly-once(Data Engineering Moderna)
Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.
O problema que os três resolvem
Arquivos num repositório de objetos não formam uma tabela. Falta tudo o que um banco entrega de graça: se um trabalho escreve enquanto outro lê, a leitura enxerga estado parcial; não há como acrescentar coluna sem reescrever tudo; não há como consultar o estado de ontem; e apagar uma linha significa reescrever o arquivo inteiro que a contém.
Formato de tabela é a camada de metadados que devolve essas garantias sobre os mesmos arquivos, sem servidor de banco. É o que transforma um lago de dados — pasta com arquivos — em algo que suporta consulta concorrente e confiável.
# O que existe fisicamente, nos três formatos
s3://lake/vendas/
data/ ← arquivos colunares, imutáveis
part-0001.parquet
part-0002.parquet
metadata/ ← a camada que faz virar tabela
v1.json quais arquivos compõem a tabela na versão 1
v2.json idem na versão 2 (após um append)
snapshot-log histórico → é daqui que sai a consulta ao passado
# Escrever = criar arquivos novos e publicar um metadado novo,
# atomicamente. Quem está lendo continua na versão anterior,
# inteira e consistente. Nenhum leitor vê estado pela metade.Por que isso destrava o lagohouse
Com transação e evolução de esquema sobre arquivos em bucket, some a razão de copiar o dado para um armazém proprietário só para consultá-lo com segurança. O dado fica onde está, em formato aberto, e vários motores de consulta o leem.
O que os três têm em comum, e onde divergem
As capacidades essenciais são as mesmas nos três. Comparar por lista de recursos leva a empate — e é por isso que a decisão real se dá em outro eixo.
- Transação: publicação atômica, com leitores isolados de escritas em curso.
- Consulta ao passado: ler a tabela como ela estava num instante anterior — o que torna auditoria e reprocessamento operações comuns, não projetos.
- Evolução de esquema: acrescentar, renomear e remover coluna sem reescrever os dados existentes.
- Compactação: juntar arquivos pequenos em segundo plano, porque escrita frequente gera muitos arquivinhos e leitura de muitos arquivinhos é lenta.
- Remoção lógica: registrar o que foi apagado em vez de reescrever o arquivo, o que torna viável atender pedido de exclusão de dado pessoal.
| Eixo real de decisão | O que perguntar |
|---|---|
| Neutralidade de fornecedor | Quantos motores de consulta diferentes leem este formato hoje, sem camada de compatibilidade? É o que protege a decisão daqui a três anos |
| O que sua plataforma já usa | Se a plataforma de processamento do time tem um formato nativo, ir contra a corrente custa integração e suporte todo dia |
| Perfil de escrita | Ingestão em lote e leitura analítica é o caso comum. Atualização de linha em alta frequência é um perfil diferente, e nem todos os formatos foram desenhados para ele |
| Serviço gerenciado disponível | Compactação e limpeza de arquivos antigos são trabalho contínuo. Quem vai operar isso — o time, ou o provedor? |
A recomendação padrão, e o critério por trás dela
Para projeto novo sem plataforma já definida, escolha o formato com o ecossistema mais amplo e independente de fornecedor: a portabilidade é a única propriedade que você não consegue acrescentar depois. Já operando sobre outra plataforma com formato nativo, manter o nativo costuma ser mais barato que migrar — e existem camadas de compatibilidade que reduzem o custo de conviver com os dois.
Qual capacidade esses formatos de tabela trazem que diretórios de arquivos não têm?
O que mais quebra na prática
- Arquivos pequenos demais. Ingestão a cada minuto gera milhares de arquivos minúsculos, e a consulta passa mais tempo abrindo arquivo do que lendo dado. Compactação não é opcional — é manutenção obrigatória.
- Metadados que crescem sem limite. Cada escrita cria uma versão, e o histórico completo acaba maior que o dado. É preciso expirar versões antigas, e essa política precisa ser decidida por alguém.
- Escritores concorrentes de motores diferentes. Funciona, mas exige que todos respeitem o mesmo protocolo de publicação — e versões antigas de biblioteca costumam ser a fonte do problema.
- Remoção lógica acumulada. Muitos registros de exclusão sem reescrita tornam a leitura progressivamente mais lenta, porque cada consulta precisa aplicar todos eles.
A conta que ninguém faz antes de adotar
Compactação e expiração de versões consomem computação recorrente. Não é custo de migração — é custo mensal permanente, e precisa entrar no orçamento antes da decisão, não depois da primeira fatura.
Perguntas frequentes
❓ O que formato de tabela acrescenta ao formato de arquivo?
❓ Como escolher entre os formatos abertos?
❓ Viagem no tempo serve para quê na prática?
Fixando
Por que a evolução de esquema é tratada como recurso de primeira classe nesses formatos?
O que a compactação periódica de arquivos pequenos resolve?
Terminou de ler?
Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.
Próximos passos sugeridos
Temas deste módulo
Discussão
Carregando comentários…