Apache Iceberg V4 ganha chaves primárias, mas a maioria das regras começa sem enforcement
Aprofundamento CEVIU
Aprofundamento
Em 27 de outubro de 2026, a comunidade Iceberg aprovou a adição de table constraints à especificação V4, com 8 votos +1 (5 deles vinculantes) e nenhum -1. São três tipos: check, unique e primary-key. As regras ficam nos metadados da tabela, separadas do schema, e apontam para as colunas pelo field ID. Renomear uma coluna, portanto, não quebra a constraint. A unique segue o padrão SQL para nulos (linha com nulo na chave não entra na comparação). A primary key exige valores distintos e nunca nulos, e só pode haver uma por tabela.
O ponto que mais confunde é o flag enforced. Ele é uma promessa sobre gravações futuras, não sobre o histórico: uma constraint pode estar enforced numa tabela que já contém violações. Quem diz se a regra vale para os dados de hoje é o constraint-statuses, registrado em cada snapshot, com quatro listas (validated, valid, invalid e unvalidated). Validated significa checagem completa. Valid significa que a regra vale por indução: o pai estava bom e as mudanças do commit foram checadas. Constraint ausente de todas as listas conta como unvalidated. Os status são imutáveis, então o time travel mostra o veredito da época. Uma validação posterior vira novo snapshot com a operação replace.
Há custos operacionais. Num retry de commit, as constraints enforced precisam valer contra o novo snapshot pai, e os status são recalculados. Em tabelas com muitos writers concorrentes, isso repete a checagem de unicidade a cada tentativa. A spec também não traz chaves estrangeiras, e proíbe float, double, geometry e geography em chaves unique e primary-key.
Por que isso importa
Para quem opera pipelines de migração de warehouse para Iceberg, a leitura é que a chave primária passa a ter lugar declarado, mas não vira garantia automática. Na prática, vale tratar o status do snapshot como a fonte de verdade e o enforced como política de escrita. Para planners e quem modela dados, só faz sentido confiar em uma chave (para remover um DISTINCT, por exemplo) quando o status for validated ou valid.
Linha do tempo
Apache Iceberg V4 ganha chaves primárias, unicidade e checks, mas a maioria das regras começa sem enforcement.
Perguntas frequentes
O que significa uma constraint enforced no Iceberg V4?
Significa que os writers devem garantir que as linhas que gravam respeitem a regra, e uma escrita que viole falha. Isso não obriga ninguém a corrigir linhas já existentes. Uma tabela pode ter constraint enforced e ainda conter violações antigas.
Como saber se uma chave primária está realmente única?
Olhe o constraint-statuses do snapshot. Se a constraint está em validated ou valid, a regra vale para aquele snapshot. Se está em unvalidated ou invalid, não dá para confiar nela.
Qual a diferença entre validated e valid?
Validated indica que uma checagem completa rodou contra as linhas do snapshot. Valid indica que a regra vale por indução: o snapshot pai era válido e as mudanças do commit foram checadas. Esse segundo caminho é o que viabiliza streaming, sem reescanear a tabela a cada commit.
O Iceberg V4 terá chaves estrangeiras?
Não nesta proposta. Integridade referencial exige leituras entre tabelas na hora da escrita e uma visão compartilhada de snapshots de duas tabelas. A spec deixa esse problema de fora e cobre apenas regras por tabela.
Fontes
- iceberglakehouse.comfonte original
- Categoria
- CEVIU Dados
- Publicado
- 02 de novembro de 2026
- Editoria
- CEVIU Dados
