Início
topics
Apache Iceberg
O que é Apache Iceberg?
Publicado em: 26 de fevereiro de 2024
Colaboradores: Dave Bergmann
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 IBM watsonx.data, Netezza e Db2 warehouse.
Um armazenamento de dados projetado para escalar cargas de trabalho de IA, baseado em uma arquitetura de data lakehouse aberta, para todos os seus dados, em qualquer lugar.
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.
Apache Iceberg vs. Delta Lake vs. Apache Hudi
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 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 suporta 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.
Catálogo do Iceberg
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.
Camada de metadados
A camada de metadados do Iceberg é composta, em ordem decrescente, por arquivos de metadados, listas de manifestos e arquivos de manifestos.
Arquivo de metadados
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.
Lista de manifesto
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.
Arquivo de manifesto
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.
Camada de dados
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.
Particionamento oculto
O Iceberg lida com todos os detalhes de particionamento e consulta nos detalhes técnicos. 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.
Evolução de esquema
O Iceberg oferece suporte nativo para evolução de esquema. 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.
Viagem no tempo
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.
Compactação e filtragem de dados
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.
Soluções relacionadas
Acesse seus dados e otimize cargas de trabalho caras com o watsonx.data, um armazenamento de dados projetado para escalar cargas de trabalho de IA, em uma arquitetura de data lakehouse aberta, para todos os seus dados, em qualquer lugar.
Execute análises e cargas de trabalho de IA de missão crítica com todos os tipos de dados, em qualquer lugar: o IBM Db2 Warehouse atende aos seus objetivos de preço e desempenho para cargas de trabalho sempre ativas, fornecendo acesso simples e controlado a todos os seus dados e eliminando silos de dados em toda a nuvem híbrida.
Escalone análises e IA com um data warehouse na nuvem unificado, governado e econômico. Com suporte para formatos abertos como Parquet e Apache Iceberg, além de integração nativa com seu data lake e IBM watsonx.data lakehouse, o Netezza capacita engenheiros de dados, cientistas de dados e analistas de dados a executar cargas de trabalho complexas sem ETL adicional ou movimentação de dados sobre o armazenamento de objetos em nuvem.
Potencialize suas aplicações, análises e IA com qualquer dado em um data lakehouse aberto. Ao contrário dos data warehouses tradicionais, os data lakehouses podem processar vídeos, áudios, logs, textos, mídias sociais, dados de sensores e documentos para impulsionar aplicativos, análises e IA. Eles podem ser construídos como parte de uma arquitetura de malha de dados para fornecer os dados certos, no momento certo, independentemente de onde residam.
Recursos do Apache Iceberg
Saiba mais sobre o particionamento no Apache Iceberg e acompanhe um exemplo para ver como o Iceberg facilita a evolução de partições.
Criado por diretores de dados, líderes de dados e outros especialistas da IBM e de fora, este guia ajudará você a implementar a estratégia, tecnologias e cultura certas para liderar uma organização orientada por dados e impulsionada pela IA.
Diante do aumento dos custos de dados, da proliferação de silos de dados e do aumento dos requisitos regulatórios, a urgência nunca foi maior para as empresas alavancarem a IA para obter vantagem competitiva.
Notas de rodapé
Todos os links levam para fora do site ibm.com.
1 "Apache Iceberg: The Hub of an Emerging Data Service Ecosystem?" (link fora de ibm.com), Datanami, 8 de fevereiro de 2021
2 "Clash of ACID Data Lakes: Comparing Data Lakehouse Formats" (link fora de ibm.com), Data Insights, 9 de agosto de 2022