O Apache Iceberg é um formato de código aberto de alto desempenho para tabelas analíticas massivas, facilitando o uso de tabelas SQL para big data e a integração segura dessas tabelas com motores como Apache Spark, Trino, Flink, Presto, Hive e Impala.
Além de sua especificação de formato de tabela aberta, o Iceberg também inclui um conjunto de APIs e bibliotecas que permitem que motores de armazenamento, de consulta e de execução interajam de maneira fluida com tabelas que seguem esse formato.
O formato de tabela Iceberg se tornou uma parte essencial do ecossistema de big data, principalmente devido à sua capacidade de fornecer funcionalidades que normalmente não estão disponíveis com outros formatos de tabela. Usando uma série de metadados mantidos em cada tabela, o Iceberg permite a evolução de esquemas, a evolução de partições e o rollback de versões de tabela sem a necessidade de regravações ou migrações de tabela custosas. É totalmente independente do sistema de armazenamento, com suporte para várias fontes de dados e sem dependências de sistema de arquivos.
Originalmente criado por engenheiros de dados da Netflix e Apple em 2017 para resolver as limitações do Apache Hive, o Iceberg foi disponibilizado como código aberto e doado à Apache Software Foundation no ano seguinte. Ele se tornou um projeto de nível superior da Apache em 2020.
A velocidade, eficiência, confiabilidade e facilidade de uso do Apache Iceberg ajudam a simplificar e coordenar o processamento de dados em qualquer escala. Esses pontos fortes o tornaram o formato de tabela preferido por vários data warehouses, data lakes e data lakehouses líderes de mercado, incluindo o IBM® watsonx.data, Netezza e Db2 warehouse.
Mantenha-se atualizado sobre as tendências mais importantes (e intrigantes) do setor em IA, automação, dados e muito mais com o boletim informativo Think. Consulte a Declaração de privacidade da IBM.
O Iceberg é um dos poucos formatos de tabela de código aberto que permite transações ACID: trocas de dados que preservam a precisão, garantindo atomicidade, consistência, isolamento e durabilidade.
A origem do Iceberg foi um esforço para lidar com as limitações práticas das tabelas do Apache Hive em um ambiente de data lake de grande escala. De acordo com Ryan Blue, presidente do PMC do projeto Apache Iceberg e (antigo) engenheiro sênior da Netflix, "muitos serviços e mecanismos diferentes estavam usando as tabelas Hive. Mas o problema era que não tínhamos essa garantia de correção. Não tínhamos transações atômicas", disse ele em uma conferência de 2021. "Às vezes, mudanças de um sistema faziam com que outro sistema obtivesse dados incorretos, e esse tipo de problema nos levou a nunca usar esses serviços, a não fazer mudanças em nossas tabelas, apenas para garantir a segurança"1.
O próprio Apache Hive surgiu como uma forma de fazer com que clusters do Apache Hadoop operassem de maneira semelhante a bancos de dados relacionais acessíveis por SQL. Embora funcione efetivamente para dados estáticos, ele se adapta mal a conjuntos de dados dinâmicos: as alterações precisam ser coordenadas manualmente entre diferentes aplicações e usuários, sob o risco de corrupção e posterior imprecisão de grandes conjuntos de dados.
Para garantir a precisão em um ambiente dinâmico, o Iceberg foi projetado para assegurar que qualquer transação de dados exiba todas as quatro propriedades ACID:
Todas as alterações nos dados são realizadas como se fossem uma única operação, ou seja, ou todas as alterações são executadas, ou nenhuma delas é. Por exemplo, em uma transação financeira, a atomicidade garante que qualquer débito feito em uma conta tenha um crédito correspondente na outra conta.
Não há contradições entre o estado geral dos dados antes da transação e o estado dos dados após a transação. Continuando o exemplo da transação financeira, a consistência garante que os fundos combinados entre as duas contas permaneçam os mesmos após a transação, assim como eram antes da transação.
O estado intermediário de qualquer transação é invisível para outras transações; transações concorrentes, que operam simultaneamente no mesmo conjunto de dados, são tratadas como se fossem serializadas. Nesse exemplo financeiro, o isolamento garante que qualquer outra transação possa ver os fundos transferidos na conta debitada ou na conta creditada, mas não em ambas (nem em nenhuma delas).
Após uma transação bem-sucedida, quaisquer alterações nos dados persistirão mesmo no caso de uma falha do sistema. Em nosso exemplo financeiro, isso significa que a transação permanecerá completa, mesmo que haja uma queda de energia logo após sua execução.
O formato de tabela Apache Iceberg é frequentemente comparado a duas outras tecnologias de dados de código aberto que oferecem transações ACID: Delta Lake, uma camada de armazenamento otimizada originalmente criada pela Databricks, que estende os arquivos de dados Parquet com um log de transações baseado em arquivo e manipulação escalável de metadados, e Apache Hudi, abreviação de "Hadoop Upserts Deletes and Incrementals", que foi originalmente desenvolvido pela Uber em 2016.
Um estudo de 2022 conduzido pela Synvert gerou dados aleatórios e os armazenou no formato JSON em um bucket AWS S3 para usar como benchmarking das três tecnologias. Os testes demonstraram que o formato de tabela otimizado do Iceberg apresentou desempenho superior tanto ao Delta Lake quanto ao Apache Hudi em todas as métricas testadas2.
Armazenamento: o tamanho dos arquivos resultantes das tabelas do Iceberg foi significativamente menor do que os do Delta Lake ou Hudi, o que proporciona uma grande vantagem na otimização de armazenamento.
Operações de inserção: nas operações de inserção, o Iceberg também teve o melhor desempenho, ou seja, o tempo de execução mais curto. Tanto o Iceberg quanto o Delta Lake foram significativamente mais rápidos que o Hudi.
Operações de atualização: nas operações de atualização, o Iceberg foi drasticamente mais rápido que ambos, Delta Lake e Hudi. Notavelmente, ao contrário de seus equivalentes, o tempo de execução do Iceberg não aumentou significativamente com o número total de registros: nas cargas de trabalho máximas testadas no estudo (500 milhões de registros), o Iceberg foi quase 10 vezes mais rápido que o Delta Lake.
Operações de remoção: da mesma forma, o Iceberg foi várias vezes mais rápido que ambas as alternativas nas operações de remoção.
O Iceberg implementa uma hierarquia de três camadas de arquivos de metadados para garantir a correção e a coordenação dos dados das tabelas em vários formatos de arquivo e em constantes mudanças.
Desenvolvido em Java e Python e também oferecido em uma API Scala, o Iceberg é compatível com uma variedade de formatos de arquivo para big data, incluindo Apache Parquet, Apache Avro e Apache ORC. Ele oferece funcionalidade semelhante às tabelas SQL em bancos de dados tradicionais, de maneira independente de formato de arquivo e fornecedor, permitindo que vários mecanismos operem no mesmo conjunto de dados.
A arquitetura de uma tabela Iceberg é composta por três camadas: o catálogo Iceberg, a camada de metadados e a camada de dados.
O catálogo Iceberg fica no topo da camada de metadados e da camada de dados, assim como a ponta de um iceberg fica acima da superfície da água. Ele armazena os ponteiros de metadados atualizados (ou "atuais") que mapeiam o nome de uma determinada tabela para a localização de seu(s) arquivo(s) de metadados atual(is). Além de seu catálogo interno, o Iceberg suporta outros frameworks de catálogos, como Hive MetaStore ou AWS Glue.
As operações no nível do catálogo Iceberg são atômicas, o que é essencial para garantir a correção das transações subsequentes.
Assim, um mecanismo de consulta começa qualquer consulta SELECT no catálogo Iceberg, que fornece a localização do arquivo de metadados atual da tabela que o mecanismo de consulta deseja ler.
A camada de metadados do Iceberg é composta, em ordem decrescente, por arquivos de metadados, listas de manifestos e arquivos de manifestos.
Os arquivos de metadados armazenam os metadados de uma tabela, incluindo o esquema da tabela, informações de partição, seu snapshot atual e snapshots de estados anteriores. Após ser direcionado ao arquivo de metadados atual a partir da entrada da tabela no catálogo Iceberg, o mecanismo de consulta usa o valor [current-snapshot-id] para encontrar sua entrada na matriz [snapshots]. A partir daí, ele pode localizar e abrir a lista de manifestos da tabela.
A lista de manifestos é simplesmente uma lista de arquivos de manifesto e informações importantes para cada arquivo de dados contido nela, como sua localização, o snapshot com o qual está associado e as partições às quais pertence. Certas otimizações e funções de filtragem estão disponíveis neste estágio.
Os arquivos de manifesto rastreiam os arquivos de dados e seus detalhes associados, metadados e estatísticas. Isso conduz uma das vantagens fundamentais do formato de tabela Iceberg em relação ao formato de tabela Hive: sua capacidade de rastrear dados no nível do arquivo. Neste estágio, os valores [file-path] para cada objeto [data-file] podem ser usados para localizar e abrir esse arquivo.
A camada de dados, como o nome sugere, reside abaixo da camada de metadados e contém os próprios arquivos finais.
O Apache Iceberg oferece uma série de recursos úteis para melhorar e simplificar o gerenciamento de dados.
O Iceberg lida com todos os detalhes técnicos do particionamento e consultas. O particionamento oculto do Iceberg poupa os usuários do trabalho de fornecer informações sobre a disposição das partições ao consultar tabelas. Os usuários não precisam manter colunas de partição por conta própria, nem mesmo entender a disposição física da tabela, para obter resultados precisos de consulta.
Isso não apenas torna o particionamento do Iceberg muito amigável ao usuário, como também permite que os layouts de partição sejam alterados ao longo do tempo sem quebrar consultas preexistentes. Quando as especificações de partição evoluem, os dados da tabela (e seus metadados) não são afetados. Apenas os novos dados, gravados na tabela após a evolução, são particionados com a nova especificação, e os metadados para esses novos dados são mantidos separadamente.
O Iceberg fornece compatibilidade nativa com evolução de esquemas. Isso permite que os usuários modifiquem os esquemas das tabelas sem a necessidade de migração de dados complexa, simplificando muito a adaptação a estruturas de dados em evolução.
O Iceberg permite que os usuários façam uma viagem no tempo através dos snapshots dos dados do Iceberg em diferentes pontos do tempo. Isso é valioso para uma variedade de casos de uso, incluindo auditorias, depuração e verificações de conformidade.
O Iceberg oferece uma série de recursos de indexação que ajudam a otimizar o desempenho das consultas, como opções de compactação para mesclar arquivos menores em arquivos maiores, reduzindo a sobrecarga de metadados, e filtros Bloom para reduzir a leitura de dados desnecessários durante a execução da consulta.
Coloque seus dados para trabalhar, onde quer que estejam, com o data lakehouse aberto e híbrido para IA e análise de dados.
Resolva os desafios de dados atuais com uma arquitetura lakehouse. Conecte-se a dados em minutos, obtenha insights confiáveis com rapidez e reduza os custos de seu data warehouse.
Libere o valor dos dados empresariais com a IBM® Consulting, construindo uma organização orientada por insights, que proporciona vantagem comercial.
1 “Apache Iceberg: The Hub of an Emerging Data Service Ecosystem?”, Datanami, 8 de fevereiro de 2021
2 “Clash of ACID Data Lakes: Comparing Data Lakehouse Formats”, synvert, a GlobalLogic company, 9 de agosto de 2022