Desbloqueando a portabilidade de dados: evitando o aprisionamento de catálogo com as APIs REGISTER e UNREGISTER

À medida que as organizações adotam a arquitetura lakehouse, os dados estão migrando de data warehouses proprietários para formatos abertos de tabela e armazenamento, onde podem ser acessados em vários mecanismos, como Spark e Trino, sem duplicação.

No entanto, os formatos abertos são apenas uma parte da equação de abertura. A verdadeira abertura também exige interoperabilidade e flexibilidade na forma como os dados são gerenciados e governados. Para que um lakehouse cumpra totalmente sua promessa, as organizações precisam de liberdade para escolher e migrar entre catálogos à medida que sua arquitetura evolui.

Para dar suporte a essa portabilidade, os endpoints REGISTER e UNREGISTER permitem que os usuários transfiram uma tabela entre catálogos sem regravar, exportar ou copiar um único arquivo. O REGISTER anexa uma tabela existente a qualquer catálogo IRC. Ao mover uma tabela, você não pode simplesmente usar o comando DROP no catálogo antigo, pois isso limparia seus dados e metadados subjacentes. Adicionamos o endpoint UNREGISTER à especificação de catálogo REST do Apache Iceberg™ para que você possa instruir o catálogo antigo a esquecer a tabela e retornar o ponteiro exato que o próximo catálogo precisa para assumir o controle.

Neste post, examinaremos mais de perto como o ecossistema de formatos de tabela abertos está evoluindo, os principais desafios que essas adições resolvem e como o REGISTER e o novo comando UNREGISTER realmente funcionam.

Contexto: o papel do catálogo

Quando um mecanismo consulta uma tabela, ele primeiro solicita ao catálogo que carregue a tabela para garantir que ela tenha o estado mais recente. O catálogo retorna os metadados atuais da tabela, incluindo a localização dos dados da tabela no armazenamento de objetos. A partir daí, o mecanismo usa esses metadados para encontrar o esquema e lê o Parquet diretamente do armazenamento de objetos.

Essa coordenação é essencial para formatos de tabela abertos porque todos os metadados importantes (esquema, histórico, estatísticas) e os próprios dados residem no armazenamento, totalmente desacoplados da computação. Ao agir como a autoridade central para esse estado mais recente, o catálogo coordena os commits e garante que dois gravadores nunca gravem por cima um do outro silenciosamente.

Figura 1: O caminho de leitura

1. O mecanismo solicita ao catálogo que carregue a tabela.
2. O catálogo retorna os metadados atuais da tabela e sua localização no armazenamento de objetos.
3. O mecanismo lê os metadados e os arquivos de dados diretamente do seu bucket.

Como funciona o endpoint REGISTER

Anexar uma tabela existente a um catálogo é simplesmente uma questão de entregar a localização dos metadados a partir do carregamento da tabela. É exatamente isso que o REGISTER faz por meio do endpoint já definido na especificação REST do Iceberg.

Figura 2: A operação REGISTER

• Um cliente envia uma solicitação POST com o nome da tabela desejada e o URI de sua localização de metadados existente.
• Após a validação básica, o catálogo grava um único registro vinculando o nome da tabela ao metadata.json existente. Nenhum arquivo de dados é copiado, movido ou alterado.

O problema é que o REGISTER sozinho criaria um cenário de "split-brain" (divisão cerebral), no qual dois catálogos acham que são donos da tabela e coordenarão os commits. Como os catálogos do Iceberg são independentes e não se comunicam, o REGISTER sozinho adiciona uma entrada ao novo catálogo enquanto deixa o antigo totalmente ativo. Se ambos os catálogos acreditarem que são os únicos proprietários da tabela, nenhum deles apresentará um erro, mas a primeira operação de gravação bifurcará a tabela, levando a resultados de consulta inconsistentes e perda silenciosa de dados.

Figura 3: O cenário de split-brain

• Uma gravação feita por meio do Catálogo A será totalmente invisível para o Catálogo B, destruindo permanentemente sua única fonte de verdade.

A peça que faltava era o UNREGISTER

Historicamente, o ecossistema carecia de uma forma padrão de encerrar de forma limpa o gerenciamento de uma tabela por um catálogo. Executar DROP TABLE não funciona porque exclui os dados e metadados da tabela! Sem o UNREGISTER, faltava a segunda metade da equação de transferência para o REGISTER. Contribuímos com o UNREGISTER para a especificação de catálogo REST do Apache Iceberg™ para remover a entrada da tabela do catálogo gerenciador sem tocar em um único arquivo de dados subjacente.

Crucialmente, ele retorna a localização dos metadados mais recentes da tabela — o ponteiro exato que o próximo catálogo precisa para assumir a coordenação de commits. Ao garantir que o catálogo original ceda explicitamente o controle, isso elimina o risco de um cenário de split-brain.

A solicitação é um POST vazio para o recurso de tabela:

POST <uc-iceberg-rest-base>/v1/{prefix}/namespaces/{namespace}/tables/{table}/unregister

A resposta é o ponteiro de que o próximo catálogo precisa:

Figura 4: O processo de transferência

1. O UNREGISTER remove a entrada da tabela do Catálogo A (os arquivos permanecem exatamente onde estão).
2. A resposta retorna a localização dos metadados mais recentes da tabela.
3. O Catálogo B obtém o ponteiro usando o endpoint REGISTER. O Catálogo B agora é o único catálogo gerenciador da tabela.

Ao combinar essas três etapas — cancelar o registro (unregister), receber a localização e registrar (register) —, a transferência garante que a tabela tenha exatamente um catálogo gerenciador em todos os momentos. (Observação: uma migração de produção ainda envolve etapas operacionais, como interromper gravadores com segurança e redirecionar jobs, o que abordaremos em um post futuro.)

Primeiros passos

Com o REGISTER e o UNREGISTER, agora você tem a liberdade de mover suas tabelas para outros catálogos. Estamos adicionando esse recurso porque a portabilidade de código aberto é essencial para nossos clientes. O Unity Catalog continua sendo o lakehouse mais aberto para gerenciar seus dados, fornecendo a governança unificada que a era dos agentes exige. Ele fornece a camada de contexto para sua ontologia, oferece o melhor controle de acesso e observabilidade da categoria em dados e agentes, além de proporcionar flexibilidade em nuvens, regiões e computação.

Para testar o REGISTER e o UNREGISTER no Unity Catalog em private preview, entre em contato com sua equipe de conta.

(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original