Voltar

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

  1. 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

Avalie este artigo:
Categoria
CEVIU Dados
Publicado
02 de novembro de 2026
Editoria
CEVIU Dados

Quer receber mais sobre CEVIU Dados?

Conteúdo curado diariamente, direto no seu e-mail.

Conteúdo curado diariamenteDiversas categoriasCancele quando quiser