OpenLake:Comparação dos formatos abertos suportados

FileSystem catalog: leve para iniciar, limitado em produção

O FileSystem catalog organiza os metadados das tabelas em uma estrutura de diretórios, como warehouse/dbName.db/tableName. Por não exigir serviços externos e funcionar imediatamente após a instalação, é um ponto de partida prático.

Em ambientes de produção, porém, ele enfrenta restrições fundamentais:

• Gravações concorrentes inseguras: O sistema depende de operações de renomeação do Object Storage para simular commits. Como essas operações não são atômicas, gravações simultâneas na mesma tabela podem causar conflitos de renomeação de arquivos e perda de dados.

• Compactação vinculada aos jobs de gravação: Sem um serviço centralizado de metadados, a compactação deve ocorrer dentro dos jobs de gravação. Isso consome recursos de gravação, dificulta o planejamento de capacidade e reduz a estabilidade.

• Operações lentas no ciclo de vida da tabela: Crie, excluir ou renomear uma tabela exige percorrer um grande volume de arquivos. Esse processo é lento, propenso a erros e se agrava com o aumento da escala.

• Alta latência na leitura de metadados: A recuperação de metadados depende de operações list no Object Storage, resultando em alta latência e custos elevados para tabelas grandes.

• Falta de visibilidade e governança: Não há recursos essenciais para produção, como monitoramento, visões gerais de armazenamento, controle de acesso e gerenciamento de dados quentes e frios.

Protocolo REST padrão

FileSystem catalog: Metadados armazenados em diretórios do sistema de arquivos exigem operações list para recuperação. Essas operações são lentas, custosas e criam forte dependência do armazenamento subjacente, limitando a extensibilidade.

DLF REST catalog: Permite leituras e gravações de metadados leves e rápidas por meio de uma REST API aberta e padronizada. Os SDKs para Java e Python reduzem a complexidade de integração em ambientes multilíngues.