Formatos de Tabela Aberta Explicados: Iceberg vs. Delta vs. Hudi

Formatos de tabela abertos são camadas de metadados que ficam sobre os arquivos de dados no armazenamento de objetos, adicionando transações ACID, evolução de esquema e time travel aos dados armazenados em um data lake. Apache Iceberg, Delta Lake e Apache Hudi são os três principais formatos de tabela abertos em uso de produção hoje, e cada um transforma uma coleção de arquivos Parquet ou ORC em uma tabela que se comporta como um banco de dados: os leitores veem resultados consistentes, os gravadores podem atualizar e excluir linhas com segurança, e cada alteração é rastreada para que as versões anteriores permaneçam consultáveis.

Esta visão geral explica como os principais formatos de tabela abertos funcionam, como eles se comparam no suporte a transações ACID e evolução de esquema, e como eles se relacionam com a arquitetura de data lakehouse — baseando-se em inovações da camada de armazenamento, como transações coordenadas por catálogo, linhagem de linha e metadados unificados para mostrar onde o Delta Lake e o Apache Iceberg estão convergindo.

O que é um data lake e por que os formatos de tabela abertos são importantes?

Um data lake é um repositório centralizado construído em armazenamento de objetos de baixo custo — Amazon S3, Azure Data Lake Storage ou Google Cloud Storage — que contém dados estruturados, semiestruturados e não estruturados em formato bruto e nativo. As organizações adotaram data lakes porque o armazenamento de objetos escala de forma barata e separa o armazenamento do processamento, permitindo que qualquer mecanismo de consulta leia os mesmos dados. No entanto, o armazenamento de objetos nunca foi construído para garantir consistência: ele não possui um conceito nativo de tabela, esquema ou transação.

Um data lakehouse adiciona uma estrutura semelhante a tabelas, governança e desempenho a esse armazenamento bruto, combinando o baixo custo de um data lake com a confiabilidade de um data warehouse. A ponte entre os dois é o formato de tabela aberto: ele transforma arquivos soltos no armazenamento de objetos em tabelas governadas e consultáveis, sem copiar os dados para um warehouse proprietário.

Antes de existirem formatos de tabela abertos, a execução de análises em data lakes tradicionais causava problemas contínuos: gravadores simultâneos podiam corromper os dados no meio da gravação, atualizações e exclusões significavam regravar partições inteiras e não havia uma maneira confiável de saber quais arquivos representavam o estado atual e correto de uma tabela. Os formatos de tabela abertos gerenciam metadados para arquivos de dados no armazenamento de objetos, rastreando exatamente quais arquivos pertencem a uma tabela — a padronização que permitiu que os data lakes finalmente suportassem recursos semelhantes aos de bancos de dados, como atualizações em nível de registro.

Os formatos de tabela e formatos de arquivo abertos que você precisa conhecer

Apache Iceberg

O Apache Iceberg, originalmente desenvolvido na Netflix e hoje um projeto da Apache Software Foundation, foi projetado para tornar tabelas imensas e de alteração lenta rápidas de consultar e seguras de evoluir. O Apache Iceberg usa uma estrutura em árvore para um gerenciamento eficiente de metadados: arquivos de manifesto e listas de manifesto rastreiam cada arquivo de dados em uma tabela, permitindo que os mecanismos de consulta descartem dados irrelevantes antes do início de uma varredura. As tabelas do Iceberg suportam evolução de esquema e evolução de partição sem regravar os arquivos subjacentes.

Delta Lake

O Delta Lake, criado pela Databricks e lançado como código aberto, trouxe transações ACID para cargas de trabalho do Apache Spark por meio de um log de transações write-ahead. O Delta Lake se originou na Databricks e se integra ao Spark nativamente, embora agora ofereça suporte a um amplo conjunto de mecanismos por meio de conectores independentes. As tabelas do Delta Lake registram cada gravação como uma entrada de log ordenada e atômica, oferecendo aos leitores uma visão consistente mesmo enquanto novos dados estão sendo gravados.

Apache Hudi

O Apache Hudi, abreviação de Hadoop Upserts Deletes and Incrementals, é construído em torno de atualizações rápidas e frequentes em nível de registro. O Apache Hudi otimiza para atualizações frequentes e dados em streaming mantendo índices que localizam o arquivo exato que contém um determinado registro, permitindo atualizações eficientes em nível de registro sem uma varredura completa da tabela. Esse design torna o Hudi uma escolha comum para pipelines de captura de dados alterados (CDC) e ingestão em tempo quase real.

Parquet e ORC

Parquet e ORC são formatos de arquivo colunares, não formatos de tabela: eles definem como os arquivos de dados individuais são organizados, não como os arquivos se tornam uma tabela governada. Iceberg, Delta Lake e Hudi são todos construídos em arquivos Parquet — o Iceberg e o Hudi também suportam ORC — usando estatísticas em nível de arquivo que o Parquet armazena para descartar dados antes que um mecanismo de consulta os leia. Essa distinção, formato de arquivo versus formato de tabela, esclarece a maior parte da confusão corporativa sobre onde começam as responsabilidades de cada camada.

Iceberg vs. Delta Lake vs. Hudi: Comparação rápida

Os três principais formatos de tabela abertos agora compartilham mais recursos do que diferem, mas a tabela abaixo destaca onde o histórico de design ainda se faz presente.

Por dentro do Apache Iceberg: tabelas e metadados

A árvore de metadados do Iceberg

Uma tabela do Iceberg é definida por uma árvore de metadados, não por um único arquivo: um arquivo de metadados aponta para uma lista de manifestos, que aponta para arquivos de manifesto que listam os arquivos de dados reais que compõem um snapshot. Essa estrutura em camadas permite que um mecanismo de consulta descarte manifestos e arquivos de dados irrelevantes usando estatísticas de coluna armazenadas sem abrir um único arquivo, melhorando o desempenho da consulta em tabelas com milhões de arquivos.

Snapshots e time travel

Cada gravação em uma tabela do Iceberg cria um novo snapshot — um registro imutável de quais arquivos de dados existiam naquele momento — e a árvore de metadados mantém um histórico de snapshots anteriores. Isso possibilita o recurso de time travel: os mecanismos podem consultar uma tabela como ela existia em um ID de snapshot ou timestamp específico, oferecendo suporte a auditoria, conjuntos de treinamento de ML reproduzíveis e reversão (rollback) para o último estado estável após uma gravação incorreta.

Evolução de partição

O Iceberg desacopla o particionamento físico de uma tabela de seus padrões de consulta por meio da evolução de partição, permitindo que as equipes alterem como os novos dados são particionados sem regravar os arquivos existentes ou quebrar as consultas no esquema antigo. O particionamento oculto significa que os analistas não precisam fazer referência direta às colunas de partição física para obter o descarte de partições (partition pruning).

Funcionamento interno e manutenção de tabelas do Iceberg

Como cada gravação produz um novo snapshot com sua própria lista de manifestos, uma tabela do Iceberg gravada ativamente pode acumular milhares de pequenos arquivos de manifesto e de dados se não for gerenciada. Os mecanismos de consulta ainda precisam abrir e avaliar cada arquivo de manifesto relevante, de modo que a proliferação de manifestos corrói os ganhos de desempenho de consulta que a árvore de metadados foi criada para oferecer.

A solução padrão é a compactação agendada: um trabalho de manutenção que regrava pequenos arquivos de dados em menos arquivos maiores e consolida os manifestos, executado todas as noites ou a cada hora, dependendo do volume de ingestão. Associar a compactação à expiração regular de snapshots — removendo metadados além de uma janela de retenção — mantém o tamanho do armazenamento e dos metadados sob controle, sem limitar o quão longe o time travel pode alcançar.

Delta Lake e transações ACID

O log de transações do Delta Lake

As tabelas do Delta Lake armazenam um log de transações ordenado e somente de anexação (append-only) — uma sequência de entradas JSON que registra cada adição, remoção e alteração de metadados — junto com arquivos de checkpoint periódicos que resumem o log para leituras mais rápidas. Historicamente, o próprio sistema de arquivos agia como coordenador de commits, o que significa que qualquer cliente com acesso em nível de arquivo podia gravar diretamente em uma tabela Delta, sem passar por um catálogo regulador.

Como as transações ACID se comportam no Delta Lake

As transações ACID garantem a consistência dos dados durante gravações simultâneas, exigindo que cada gravador verifique a versão atual do log, gere uma nova entrada e faça o commit apenas se nenhuma alteração conflitante tiver ocorrido nesse intervalo; se um conflito for detectado, o gravador tenta novamente. A conformidade com o ACID evita a corrupção de dados porque um leitor nunca vê uma tabela do Delta Lake em um estado parcialmente gravado, e as transações ACID permitem operações de dados complexas sem conflitos em partições sobrepostas.

Do nativo do Spark ao suporte multimecanismo

Como o modelo de commit original do Delta Lake dependia do acesso ao sistema de arquivos, mecanismos de terceiros fora do Apache Spark precisavam acessar as tabelas por meio de caminhos de arquivo estáticos, em vez de um catálogo regulador — deixando esses acessos sem governança e capazes de quebrar silenciosamente as relações de esquema. A Databricks resolveu isso com commits de catálogo, um padrão aberto que permite que um catálogo como o Unity Catalog atue como coordenador de commits, de modo que cada solicitação de leitura, gravação e descoberta seja autorizada centralmente. Os commits de catálogo agora estão geralmente disponíveis, alinhando o Delta Lake com a abordagem orientada a catálogo que o Iceberg usa desde o início e liberando transações multitabela.

Fundamentos do formato de arquivo: como o Parquet permite o descarte de dados

Um arquivo Parquet organiza dados tabulares por coluna em vez de por linha, agrupando valores da mesma coluna em blocos contíguos chamados grupos de linhas (row groups). O armazenamento colunar permite que um mecanismo de consulta leia apenas as colunas referenciadas por uma consulta, ignorando o restante — um dos principais motivos pelos quais o Parquet supera os formatos orientados a linhas em cargas de trabalho com uso intenso de leitura.

Cada grupo de linhas carrega estatísticas — valores mínimos e máximos, contagens de nulos e distribuições de valores por coluna — gravadas no rodapé de metadados do arquivo. Essas estatísticas permitem que um mecanismo determine, sem descompactar nenhum dado, se um grupo de linhas pode corresponder ao filtro de uma consulta.

Formatos de tabela abertos estendem esse princípio a um nível superior: os arquivos de manifesto do Iceberg e o log de transações do Delta Lake armazenam em cache estatísticas no nível do Parquet na camada de metadados, para que um mecanismo possa ignorar arquivos de dados inteiros antes de listá-los no armazenamento de objetos. Esse data skipping em dois níveis contribui significativamente para melhorar o desempenho das consultas em tabelas grandes. A Databricks também estendeu o modelo com o tipo de dados Variant — que agora faz parte do Parquet, Delta Lake e Iceberg —, armazenando cargas úteis (payloads) semiestruturadas em formato binário tipado em vez de JSON bruto, para que os mecanismos extraiam campos aninhados sem a necessidade de uma análise (parsing) complexa.

Versionamento de dados, Time Travel e processamento incremental

O versionamento de dados é a capacidade de um formato de tabela aberto de reter um registro de cada estado anterior da tabela em vez de sobrescrever os dados localmente, e o Time Travel lê qualquer uma dessas versões anteriores por número de versão, ID de snapshot ou carimbo de data/hora (timestamp). Os formatos de tabela abertos permitem o Time Travel e o versionamento de conjuntos de dados por padrão, já que cada gravação já cria um novo snapshot ou entrada de log endereçável de forma independente.

O processamento incremental lê apenas as linhas que foram alteradas desde a última vez que uma tabela foi processada, em vez de verificar novamente todo o conjunto de dados — o padrão por trás do Change Data Capture (CDC), onde os pipelines consomem apenas as inserções, atualizações e exclusões aplicadas a uma tabela de origem. A linhagem de linha (row lineage) e os vetores de exclusão (deletion vectors), introduzidos no Delta Lake e trazidos para o Iceberg por meio do Iceberg v3, tornaram isso mais econômico: a linhagem de linha rastreia quais linhas foram alteradas desde a última varredura da tabela, e os vetores de exclusão representam as linhas excluídas como um bitmap compacto em vez de regravar os arquivos de dados.

Reter todas as versões históricas indefinidamente é caro, por isso os formatos de tabela abertos combinam o versionamento com políticas de retenção e uma operação de vacuum ou expiração de snapshots que remove dados que não são mais referenciados dentro da janela de retenção. Executar o vacuum de forma muito agressiva pode quebrar consultas de Time Travel que ainda referenciam versões mais antigas, portanto, as janelas são configuradas para corresponder à consulta de execução mais longa que possa precisar delas.

Uma cadência razoável para tabelas de produção combina o processamento incremental em intervalos alinhados com a ingestão — geralmente a cada 5 a 15 minutos para ingestão de dados em tempo real (streaming) — com a execução diária de vacuum e expiração de snapshots, fora dos horários de pico de consulta.

Gerenciamento de metadados e otimização de desempenho

Os formatos de tabela abertos melhoram o desempenho das consultas por meio do gerenciamento de metadados organizado em camadas: arquivos de manifesto ou entradas de log descrevem arquivos de dados individuais, snapshots ou versões de log descrevem o estado da tabela em um determinado momento, e um catálogo rastreia qual versão é atualmente a autoritativa. O Unity Catalog gerencia mais de 17 exabytes de dados em formatos de tabela abertos em implantações corporativas hoje — dando uma dimensão de quantos metadados um catálogo de lakehouse moderno gerencia atualmente.

À medida que as tabelas crescem, os arquivos de manifesto e os checkpoints do log de transações podem, por si só, desacelerar o planejamento de consultas. Portanto, a manutenção deve incluir a regravação de manifestos em menos arquivos e de maior tamanho, além do ajuste dos intervalos de checkpoint de acordo com a frequência de gravação. A Databricks e a comunidade de código aberto estão desenvolvendo uma estrutura de metadados unificada para o Delta Lake e o Iceberg, prevista para preview no terceiro trimestre, combinando o log de gravação rápida do Delta Lake com a árvore de manifesto de leitura rápida do Iceberg.

O cache de metadados — manter manifestos, checkpoints ou respostas de catálogo acessados recentemente na memória — reduz a latência de consultas repetidas ao evitar uma varredura completa na árvore de metadados a cada solicitação, o que é extremamente importante para cargas de trabalho de BI que realizam muitas consultas pequenas nas mesmas tabelas grandes.

Transações ACID e controle de concorrência

O Apache Iceberg, o Delta Lake e o Apache Hudi garantem isolamento serializável ou de snapshot para gravações em uma única tabela, de modo que os leitores simultâneos sempre vejam uma versão completa e consistente, e nunca uma gravação parcial. Onde eles diferem é na coordenação: o Iceberg sempre usou o catálogo como a fonte da verdade, o Hudi usa seu próprio serviço de linha do tempo (timeline service), e o Delta Lake dependia da atomicidade do sistema de arquivos antes que os commits do catálogo o alinhassem com o modelo coordenado por catálogo.

Todos os três formatos usam controle de concorrência otimista: em vez de bloquear uma tabela antes de gravar, um gravador lê a versão atual, prepara sua alteração e faz o commit apenas se nenhum outro gravador tiver feito o commit de uma alteração conflitante nesse ínterim. Se um conflito for detectado, da transação falha com segurança e tenta novamente na versão mais recente ou é abortada, nunca deixando a tabela em um estado inconsistente.

A maneira mais eficaz de reduzir a disputa de gravação é diminuir a sobreposição entre gravadores simultâneos: particione os trabalhos de ingestão para que diferentes pipelines gravem em partições diferentes, agrupe pequenas gravações em menos commits e de maior tamanho, e limite o escopo das operações de mesclagem (merge) apenas às partições que elas afetam. Os commits de catálogo também ajudam aqui, pois as transações multitabelas permitem que atualizações relacionadas sejam confirmadas juntas, em vez de competirem como gravações separadas de múltiplos processos.

Escolhendo um formato de tabela para o seu Data Lake

O Apache Iceberg tende a ser mais adequado onde o acesso de leitura multimecanismo é mais importante — organizações que consultam as mesmas tabelas no Trino, Snowflake, Flink e Spark lado a lado. O Delta Lake é ideal para pipelines centrados no Spark que precisam de transações multitabelas e governança refinada. O Apache Hudi é mais indicado para cargas de trabalho de upsert de alta frequência no nível de registro, como a replicação de CDC, onde sua indexação personalizada supera as operações de mesclagem (merge) de uso geral.

A compatibilidade do mecanismo deve ser avaliada em relação aos mecanismos de consulta já em produção, e não apenas a uma lista de recursos — um formato tecnicamente superior que carece de um conector maduro para o mecanismo principal de uma equipe adiciona mais risco do que remove. O Delta Kernel, uma biblioteca de código aberto em Java e Rust, tornou-se uma maneira comum de os mecanismos adicionarem suporte ao Delta Lake sem reimplementar o protocolo; ele já potencializa as integrações do DuckDB e do ClickHouse, e as duas implementações estão convergindo para um núcleo compartilhado em Rust.

Antes de padronizar um formato, execute uma prova de conceito em uma tabela de produção representativa e moderadamente complexa: meça a latência de gravação sob carga simultânea, confirme se os mecanismos de destino leem o formato nativamente em vez de usar um conector lento e valide se a evolução do esquema (schema evolution) e o Time Travel se comportam conforme o esperado.

Interoperabilidade, catálogos e considerações sobre fornecedores

Opções de catálogo e interoperabilidade entre formatos

Um catálogo é o sistema de registro que rastreia quais tabelas existem, onde seus dados residem e qual snapshot é o autoritativo — as opções incluem o Hive Metastore original, o AWS Glue Data Catalog e o Unity Catalog, que gerencia tabelas do Delta Lake e do Apache Iceberg juntas sob um único conjunto de políticas de acesso. O Delta Lake UniForm vai além, permitindo que uma única cópia dos dados do Delta Lake seja lida nativamente como uma tabela do Iceberg sem duplicar o armazenamento, resolvendo a preocupação com a dependência de formato (format lock-in) que faz com que as equipes adiem a padronização.

Riscos de dependência de fornecedor (vendor lock-in) e como mitigá-los

A maneira mais clara de mitigar o risco de dependência de fornecedor (vendor lock-in) é escolher um formato com mais de uma implementação de mecanismo independente e confirmar se o acesso ao catálogo — e não apenas o acesso aos arquivos — é portátil entre as plataformas que uma equipe possa precisar no futuro. Como o Iceberg e o Delta Lake são de código aberto, o armazenamento de dados em qualquer um deles não prende, por si só, uma organização a um único mecanismo de processamento, embora as camadas de governança criadas por cima possam variar em termos de portabilidade.

Operações, monitoramento e práticas recomendadas

A manutenção de tabelas deve ser codificada como um runbook, e não como uma tarefa ad hoc: defina quais tabelas precisam de compactação e em qual limite de tamanho de arquivo, defina janelas de retenção para vacuum e expiração de snapshots com base em quão longe no passado os jobs consultam dados, e agende ambos fora das janelas de pico de consulta.

O monitoramento da integridade da tabela deve rastrear a contagem de arquivos e o tamanho médio dos arquivos por tabela, as taxas de falha de commit e a idade do arquivo de dados mais antigo em relação a um cronograma de compactação, emitindo alertas quando a contagem de arquivos pequenos ou as taxas de conflito aumentarem. Essas métricas detectam o inchaço de metadados (metadata bloat) e a disputa de gravação antes que qualquer um deles se manifeste como consultas lentas.

Como os formatos de tabela abertos oferecem suporte à evolução do esquema (schema evolution) sem quebrar as consultas existentes, as alterações de esquema geralmente são aplicadas diretamente às tabelas de produção — mas essa facilidade torna simples ignorar os testes. As equipes devem validar as alterações em relação a consultas downstream representativas e ensaiar periodicamente um rollback para um snapshot anterior, de modo que a recuperação de uma alteração malsucedida seja um procedimento treinado, e não uma primeira tentativa sob pressão.

Conclusão: compensações dos formatos de tabela abertos e próximos passos

O Apache Iceberg, o Delta Lake e o Apache Hudi resolvem o mesmo problema central — trazer transações ACID, evolução do esquema (schema evolution) e Time Travel para dados armazenados em armazenamentos de objetos de baixo custo — por meio de designs de metadados moldados por onde cada um começou: análises multimecanismo para o Iceberg, pipelines nativos do Spark para o Delta Lake e upserts de alta frequência para o Hudi. O Parquet continua sendo o formato de arquivo comum por trás de todos os três, e inovações recentes — vetores de exclusão (deletion vectors), linhagem de linha (row lineage), Variant e commits coordenados por catálogo — estão convergindo entre os formatos em vez de permanecerem isoladas.

O próximo passo prático para a maioria das equipes é uma prova de conceito com escopo definido: escolher o formato compatível com a pilha de mecanismos existente, testá-lo com volumes de dados de produção reais e confirmar se o catálogo que o gerencia pode ser estendido para um segundo formato mais tarde. O armazenamento de lakehouse aberto e agnóstico de formato da Databricks permite que as equipes armazenem dados uma única vez e façam consultas nativas como Delta Lake ou Apache Iceberg, governados sob um único catálogo, sem duplicar dados ou ficar preso a um único formato.

Perguntas frequentes sobre formatos de tabela abertos

O que é um formato de tabela aberto?

Um formato de tabela aberto é uma camada de metadados de código aberto que fica sobre os arquivos de dados no armazenamento de objetos e adiciona recursos semelhantes aos de um banco de dados — transações ACID, evolução de esquema e viagem no tempo — a um data lake. Apache Iceberg, Delta Lake e Apache Hudi são os três principais formatos de tabela abertos em uso de produção, e cada um transforma uma coleção de arquivos Parquet ou ORC em uma tabela que qualquer mecanismo compatível pode ler e gravar com segurança.

Qual é a diferença entre um formato de tabela e um formato de arquivo?

Um formato de arquivo como Parquet ou ORC define como um arquivo de dados individual é compactado e organizado em disco, enquanto um formato de tabela como Apache Iceberg ou Delta Lake define como vários desses arquivos juntos formam uma tabela consistente e consultável. Os formatos de tabela abertos são criados com base em formatos de arquivo, adicionando a camada de metadados — manifestos, logs de transações e catálogos — que os formatos de arquivo sozinhos não fornecem.

As tabelas Delta Lake e Apache Iceberg podem funcionar juntas?

Sim. O Delta Lake UniForm permite que uma única cópia dos dados da tabela Delta Lake seja lida nativamente como uma tabela Apache Iceberg sem duplicar o armazenamento, e catálogos como o Unity Catalog podem governar ambos os formatos lado a lado sob um único conjunto de políticas de acesso. Essa interoperabilidade permite que as organizações padronizem uma governança compartilhada sem forçar cada mecanismo a usar o mesmo formato de tabela.

Qual formato de tabela aberto devo escolher?

O melhor formato de tabela aberto depende dos mecanismos de consulta e da carga de trabalho já em produção: o Apache Iceberg é adequado para análises de múltiplos mecanismos em ferramentas como Trino e Snowflake; o Delta Lake é adequado para pipelines centrados no Spark que exigem transações multitabela; e o Apache Hudi é adequado para cargas de trabalho de upsert em nível de registro de alta frequência, como replicação CDC. Uma prova de conceito com dados de produção reais confirma a escolha certa.

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