Formato de tabela Iceberg, uma boa ideia - especificação mal definida - Parte 2 de 2

Problemas da especificação do Iceberg

• Problema grave da especificação do Iceberg: a especificação do Iceberg não é uma tentativa séria de resolver os problemas de metadados de data lakes em larga escala.
• Lição histórica: na primeira parte, o autor voltou à história para aprender com as lições do passado e apresentou o “problema de gerenciamento de espaço” que os bancos de dados precisam resolver.
  • Elementos do problema:
    1. fragmentação do espaço
    2. controle de concorrência granular
    3. atomicidade entre vários objetos
    4. incompatibilidade de impedância entre linhas e arquivos
    5. acesso de baixa latência e alta taxa de transferência aos metadados
• Importância dos formatos abertos: há apoio de 100% ao uso de formatos abertos em toda a stack, com entusiasmo especial pelo uso do Parquet como formato comum de armazenamento para dados tabulares.
• Diferença entre arquivos Parquet e tabelas de banco de dados: um conjunto de arquivos Parquet não se torna uma tabela de banco de dados só por existir. Uma tabela de banco de dados é mais do que um simples conjunto de linhas.

Resumo do problema de metadados

• Problema de gerenciamento de espaço: o texto reforça vários problemas que os bancos de dados precisam resolver.
• Necessidade de metadados: para fazer vários arquivos Parquet parecerem uma tabela de banco de dados, são necessários os seguintes metadados:
  1. lista de localização de todos os arquivos que compõem a tabela
  2. metadados aproximados de cada arquivo
  3. mecanismo de controle transacional para adicionar ou remover arquivos
  4. forma de evoluir o schema da tabela
• Encontrar a localização dos arquivos: para tratar um conjunto de arquivos Parquet como uma única tabela, é necessário um mecanismo para localizar os arquivos.
• Importância dos metadados: cada arquivo precisa de metadados adicionais para localizar rapidamente as linhas relevantes.

Arquivos Parquet e tabelas de banco de dados

• Definição de arquivo Parquet: Parquet fornece um formato de dados tabular, autodescritivo.
• Definição de tabela de banco de dados: uma tabela de banco de dados não é apenas um conjunto de linhas; ela exige vários metadados e controle transacional.
• Condições para usar arquivos Parquet como se fossem tabelas:
  1. lista de localização dos arquivos
  2. metadados de cada arquivo
  3. mecanismo de controle transacional para adição e remoção de arquivos
  4. forma de evoluir o schema da tabela
• Diferença entre arquivos e tabelas: o fato de arquivos Parquet terem o mesmo layout de colunas não faz com que pareçam uma tabela de banco de dados.

Arquivos de manifesto e listas

• Processo de adição de dados: para que um cliente Iceberg adicione dados a uma tabela, ele deve seguir estas etapas:
  1. gravar um ou mais arquivos Parquet em um local específico, como o S3
  2. gravar um arquivo de manifesto apontando para os arquivos escritos na etapa 1
  3. gravar uma nova lista de manifestos
• Formato dos arquivos de manifesto: os arquivos de manifesto e suas listas estão em formato AVRO, que é compactado e autodescritivo.
• Conteúdo dos arquivos de manifesto: os arquivos de manifesto incluem ponteiros para arquivos Parquet e metadados sobre cada coluna.
• Problema de tamanho dos metadados: armazenar os metadados dessa forma os torna maiores do que o necessário e não permite compactação ao reconhecer valores de string comuns entre arquivos.

Aumento da carga sobre o cliente

• Responsabilidade do cliente: em toda a especificação do Iceberg, o cliente precisa fazer uma quantidade enorme de bookkeeping para mudanças simples.
• Problema de exatidão dos metadados: se o cliente gravar alguma parte incorretamente, o commit do novo snapshot precisa ser verificado minuciosamente para garantir que os dados do manifesto foram escritos corretamente.
• Problema de segurança: como o cliente precisa gravar a lista de manifestos que aponta para todos os arquivos de manifesto, a localização de todos os arquivos no S3 acaba sendo exposta.
• Importância da segurança dos dados: como os dados têm alto valor, é legítimo questionar por que a especificação não trata segurança como prioridade máxima.

Falhas de segurança em nível de linha

• Necessidade de segurança em nível de linha: mesmo em países com regulação mais frouxa, como os Estados Unidos, é necessário ter segurança em nível de linha para proteger dados sensíveis.
• GDPR na UE: na Europa, leis como o GDPR exigem ainda mais cuidado com o acesso a dados.
• Problema de acesso do cliente aos dados: o cliente pode adicionar dados à tabela, mas não é possível restringir seu acesso aos dados que já existem.
• Gravidade do problema de segurança: o fato de a especificação não priorizar segurança levanta dúvidas sobre como ela enxerga o valor das informações em data lakes.

Papel do arquivo de metadados

• Criação do arquivo de metadados: depois de gravar arquivos Parquet, o cliente precisa gerar o arquivo de manifesto correspondente, ler a lista de manifestos existente, criar uma nova lista de manifestos e então fazer o commit dos dados.
• Processo de commit: o commit é feito gravando um arquivo de metadados (<prefix>.metadata.json).
• Escolha do formato JSON: não está claro por que o arquivo de metadados usa JSON, o que dá uma sensação de “design por comitê”.
• Repetição de metadados: o arquivo de metadados lista todos os snapshots, desperdiçando espaço por repetição de informação.

Complexidade do processo de commit

• Problema de atomicidade: é preciso tornar o novo arquivo de metadados o arquivo atual e substituir atomicamente o arquivo de metadados anterior.
• Complexidade do procedimento de commit: para fazer o commit de uma nova versão de metadados V+1, é necessário:
  1. gerar um novo arquivo de metadados da tabela com base nos metadados atuais
  2. gravar os novos metadados da tabela em um arquivo único
  3. solicitar ao metastore que troque o ponteiro de metadados da tabela de V para V+1
• Tratamento de falha no swap: se o swap falhar, isso significa que outro escritor já criou V+1, então o cliente precisa voltar à etapa 1.
• Problema de condição de corrida: quando há competição entre clientes, o cliente precisa reler o arquivo de metadados gravado anteriormente e recriar a lista de manifestos e o arquivo de metadados.

Problemas do controle de concorrência otimista

• Fato sobre concorrência: se não se espera contenção por um recurso, tanto faz qual tipo de concorrência é usado.
• Quando a contenção é esperada: se dois clientes tentam alterar o mesmo valor, é necessário usar um mecanismo de lock.
• Limitação do controle de concorrência otimista: no Iceberg, duas gravações simultâneas sempre entram em conflito, por causa da forma como a especificação foi desenhada.
• Pior semântica de lock: está sendo usada a pior semântica possível de lock para metadados, embora clientes que só queiram adicionar dados não precisem de coordenação entre si.

Limites do swap de metadados

• Centralização dos metadados: ao centralizar os metadados da tabela em um único arquivo, foi criado um único ponto de contenção para todas as escritas.
• Carga sobre o cliente em tentativas de novo: quando o cliente falha, ele precisa ler os dados gravados pelo cliente anterior e recriar a lista de manifestos e o arquivo de metadados.
• Velocidade do swap de metadados: o serviço que faz o swap de metadados precisa lidar com tentativas repetidas, o que prejudica o desempenho.
• Número limitado de commits: por causa dessa implementação simples de concorrência, o número de commits fica limitado pelo tempo necessário para a troca atômica do arquivo de metadados.

Necessidade de um banco de dados

• Localização do arquivo de metadados: um snapshot de tabela Iceberg é completamente descrito por um arquivo metadata.json.
• Contradição da ideia: o Iceberg tenta definir um formato de metadados só com arquivos, mas no fim acaba precisando de um banco de dados.
• Vantagens do banco de dados: bancos de dados modernos conseguem lidar com centenas de milhares de escritas e podem escalar de forma distribuída.
• Comparação entre sistema de arquivos e banco de dados: armazenar metadados em um banco de dados é mais eficiente do que mantê-los em arquivos.

Fragmentação e inchaço dos metadados

• Crescimento do arquivo metadata.json: o arquivo metadata.json aponta para o snapshot mais recente, e cada arquivo de metadados inclui um ponteiro reverso para o snapshot anterior.
• Aumento contínuo dos metadados: os metadados crescem continuamente, o que afeta negativamente o desempenho do data lake.
• Necessidade de limpeza periódica de metadados: se dados forem adicionados continuamente ao data lake, será necessário limpar os metadados.
• Custo das requisições HTTP: o processo de exclusão de arquivos de metadados gera requisições HTTP, o que pode trazer custo.

Leitura de dados e planejamento de consultas

• Papel dos arquivos de manifesto: os arquivos de manifesto contêm metadados sobre arquivos Parquet.
• Complexidade do planejamento de consultas: para executar uma consulta, é necessário ler em sequência a lista de manifestos e os arquivos de manifesto.
• Problema de custo: há custo de leitura no S3, o que afeta a velocidade de execução das consultas.
• Problema de fragmentação dos metadados: quando os metadados ficam fragmentados, o planejamento de consultas se torna mais complexo e o acesso aos dados fica mais difícil.

Caching e dificuldades no planejamento de consultas

• Cache de manifestos: é possível fazer cache dos manifestos, mas isso é ineficiente porque o tamanho dos metadados cresce.
• Manutenção da validade do cache: é preciso verificar se o cache continua atualizado, o que traz custo e complexidade adicionais.
• Carga sobre o cliente: todos os clientes precisam armazenar metadados em cache, o que gera milhões de requisições HTTP.
• Aumento da complexidade: o uso de data lakes se torna mais complexo e exige soluções adicionais para contornar isso.

Conclusão da ideia

• Crítica à ideia: a especificação do Iceberg não é uma especificação séria para metadados de data lakes e carrega vários problemas.
• Resumo dos problemas: o Iceberg adiciona metadados com trabalho O(n), não consegue lidar com commits entre tabelas diferentes e não resolve o problema do inchaço de metadados.
• Limites de escalabilidade: o Iceberg não é adequado para escalar e transfere complexidade demais para o cliente.
• Pergunta para a indústria: o texto levanta a questão de por que esse tipo de problema continua surgindo na indústria de TI.