Apache Iceberg: O formato de tabela aberta para Lakehouses e Streaming de Dados

Cada organização orientada por dados possui cargas de trabalho operacionais e analíticas. Uma abordagem de melhor em sua classe surge com várias plataformas de dados, incluindo streaming de dados, lagos de dados, soluções de warehouse e lakehouse, e serviços em nuvem. Um framework de formato de tabela aberto como Apache Iceberg é essencial na arquitetura empresarial para garantir a gestão e compartilhamento confiáveis de dados, evolução sem无缝 de esquemas, manuseio eficiente de grandes conjuntos de dados, armazenamento economicamente eficiente e fornecer forte suporte para transações ACID e consultas de viagem no tempo.

Este artigo explora tendências de mercado; adoção de frameworks de formato de tabela como Iceberg, Hudi, Paimon, Delta Lake e XTable; e a estratégia de produto de alguns dos principais fornecedores de plataformas de dados, como Snowflake, Databricks (Apache Spark), Confluent (Apache Kafka/Flink), Amazon Athena e Google BigQuery.

What Is an Open Table Format for a Data Platform?

Um formato de tabela aberto ajuda a manter a integridade dos dados, otimizar o desempenho das consultas e garantir uma compreensão clara dos dados armazenados dentro da plataforma.

O formato de tabela aberto para plataformas de dados geralmente inclui uma estrutura bem definida com componentes específicos que garantem que os dados estejam organizados, acessíveis e facilmente consultáveis. Um formato de tabela típico contém um nome da tabela, nomes das colunas, tipos de dados, chaves primárias e estrangeiras, índices e restrições.

Este não é um conceito novo. Seu banco de dados favorito de décadas — como Oracle, IBM DB2 (até no mainframe) ou PostgreSQL — usa os mesmos princípios. No entanto, os requisitos e desafios mudaram um pouco para data warehouses na nuvem, data lakes e lakehouses em termos de escalabilidade, desempenho e capacidades de consulta.

Vantagens de um “Formato de Tabela Lakehouse” Como Apache Iceberg

Toda parte de uma organização torna-se orientada por dados. A consequência é conjuntos de dados extensivos, compartilhamento de dados com produtos de dados entre unidades de negócios e novas exigências para processamento de dados em tempo quase real.

Apache Iceberg oferece muitos benefícios para a arquitetura empresarial:

• Armazenamento único: Os dados são armazenados uma vez (vindos de várias fontes de dados), o que reduz custos e complexidade
• Interoperabilidade: Acesso sem esforço de integração de qualquer motor de análise
• Todos os dados: Unificar cargas de trabalho operacionais e analíticas (sistemas transacionais, registros de big data/IoT/clickstream, APIs móveis, interfaces B2B de terceiros, etc.)
• Independência de fornecedor: Trabalhar com qualquer motor de análise favorito (seja em tempo quase real, batch ou baseado em API)

Apache Hudi e Delta Lake fornecem as mesmas características. Embora, o Delta Lake é principalmente impulsionado por Databricks como um único fornecedor.

Formato de Tabela e Interface de Catálogo

É importante entender que discussões sobre Apache Iceberg ou frameworks de formato de tabela semelhantes incluem dois conceitos: formato de tabela e interface de catálogo! Como usuário final da tecnologia, você precisa dos dois!

O projeto Apache Iceberg implementa o formato, mas somente fornece uma especificação (mas não implementação) para o catálogo:

• O formato de tabela define como os dados são organizados, armazenados e gerenciados dentro de uma tabela.
• A interface de catálogo gerencia os metadados das tabelas e fornece uma camada de abstração para acessar tabelas em um data lake.

A documentação do Apache Iceberg explora os conceitos em muito mais detalhes, com base neste diagrama:

As organizações usam várias implementações para a interface de catálogo do Iceberg. Cada uma integra com diferentes armazenamentos e serviços de metadados. As principais implementações incluem:

• Catálogo Hadoop: Usa o Hadoop Distributed File System (HDFS) ou outros sistemas de arquivos compatíveis para armazenar metadados. Adequado para ambientes que já usam Hadoop.
• Catálogo Hive: Integra com o Apache Hive Metastore para gerenciar metadados de tabela. Ideal para usuários que utilizam Hive para gerenciamento de metadados.
• Catálogo AWS Glue: Usa o AWS Glue Data Catalog para armazenamento de metadados. Projetado para usuários que operam dentro do ecossistema AWS.
• Catálogo REST: Fornece uma interface RESTful para operações de catálogo via HTTP. Permite a integração com serviços de metadados personalizados ou de terceiros.
• Catálogo Nessie: Utiliza o Projeto Nessie, que oferece uma experiência semelhante ao Git para gerenciar dados.

O momentum e a crescente adoção do Apache Iceberg motivam muitos fornecedores de plataformas de dados a implementarem seu próprio catálogo Iceberg. Discuto algumas estratégias na seção abaixo sobre estratégias de plataformas de dados e fornecedores de nuvem, incluindo Polaris da Snowflake, Unity da Databricks e Tableflow da Confluent.

Suporte de Primeira Classe ao Iceberg vs. Conector Iceberg

Por favor, note que suportar o Apache Iceberg (ou Hudi/Delta Lake) significa muito mais do que apenas fornecer um conector e integração com o formato de tabela via API. Fornecedores e serviços em nuvem se diferenciam por recursos avançados como mapeamento automático entre formatos de dados, SLAs críticos, viagem no tempo, interfaces de usuário intuitivas e assim por diante.

Vamos olhar para um exemplo: Integração entre Apache Kafka e Iceberg. Vários conectores Kafka Connect já foram implementados. No entanto, aqui estão os benefícios de usar uma integração de primeira classe com Iceberg (por exemplo, Tableflow da Confluent) em comparação com usar apenas um conector Kafka Connect:

• Sem configuração de conector
• Sem consumo através do conector
• Manutenção integrada (compactação, coleta de lixo, gerenciamento de instantâneos)
• Evolução automática de esquema
• Sincronização de serviço de catálogo externo
• Operações mais simples (em uma solução SaaS gerenciada integralmente, é serverless, sem necessidade de escalonamento ou operações pelo usuário final)

Vantagens semelhantes se aplicam a outras plataformas de dados e à integração potencial de primeira classe em comparação com a fornecimento de conectores simples.

Formato Aberto de Tabela para um Data Lake/Lakehouse usando Apache Iceberg, Apache Hudi e Delta Lake

O objetivo geral dos frameworks de formato de tabela, como Apache Iceberg, Apache Hudi e Delta Lake, é melhorar a funcionalidade e a confiabilidade dos data lakes abordando desafios comuns associados à gestão de dados em larga escala. Esses frameworks ajudam a:

1. Melhorar a gestão de dados
   • Facilitar o manuseio mais fácil de ingestão, armazenamento e recuperação de dados em data lakes.
   • Permitir a organização e armazenamento eficientes de dados, suportando melhor desempenho e escalabilidade.
2. Garantir a consistência dos dados
   • Fornecer mecanismos para transações ACID, garantindo que os dados permaneçam consistentes e confiáveis, mesmo durante operações de leitura e escrita concorrentes.
   • Suportar isolamento de snapshot, permitindo que os usuários visualizem um estado consistente dos dados a qualquer momento.
3. suporte à evolução do esquema
   • Permite mudanças no esquema de dados (como adicionar, renomear ou remover colunas) sem interromper dados existentes ou exigir migrações complexas.
4. otimizar o desempenho de consultas
   • Implementar estratégias avançadas de indexação e particionamento para melhorar a velocidade e eficiência das consultas de dados.
   • Habilitar gerenciamento eficiente de metadados para lidar com grandes conjuntos de dados e consultas complexas de forma eficaz.
5. melhorar a governança de dados
   • Fornecer ferramentas para melhor rastreamento e gerenciamento de linha de dados, versões e auditorias, que são cruciais para manter a qualidade e conformidade dos dados.

Ao abordar esses objetivos, frameworks de formato de tabela como Apache Iceberg, Apache Hudi e Delta Lake ajudam organizações a construir lagos de dados e lakehouses mais robustos, escaláveis e confiáveis. Engenheiros de dados, cientistas de dados e analistas de negócios utilizam ferramentas de análise, AI/ML ou relatórios/visualizações sobre o formato de tabela para gerenciar e analisar grandes volumes de dados.

Comparação de Apache Iceberg, Hudi, Paimon e Delta Lake

Não farei uma comparação dos frameworks de formato de tabela Apache Iceberg, Apache Hudi, Apache Paimon e Delta Lake aqui. Muitos experts já escreveram sobre isso. Cada framework de formato de tabela possui força e benefícios únicos. Mas atualizações são necessárias mensalmente devido à evolução rápida e inovação, adicionando novas melhorias e capacidades dentro desses frameworks.

Aqui está um resumo do que vejo em vários posts de blogs sobre as quatro opções:

• Apache Iceberg: Excelente em evolução de esquema e partição, gerenciamento eficiente de metadados e compatibilidade ampla com vários motores de processamento de dados.
• Apache Hudi: Mais adequado para ingestão de dados em tempo real e upserts, com fortes capacidades de captura de mudanças de dados e versionamento de dados.
• Apache Paimon: Um formato de lago que permite construir uma arquitetura de lakehouse em tempo real com Flink e Spark para operações de streaming e batch.
• Delta Lake: Fornece transações ACID robustas, imposição de esquema e recursos de viagem no tempo, tornando-se ideal para manter a qualidade e integridade dos dados.

Um ponto de decisão-chave pode ser que o Delta Lake não é impulsionado por uma ampla comunidade como o Iceberg e o Hudi, mas principalmente pela Databricks como um único fornecedor por trás disso.

Apache XTable como Framework de interoperabilidade entre tabelas suportando Iceberg, Hudi e Delta Lake

Os usuários têm muitas opções. XTable, anteriormente conhecido como OneTable, é mais uma framework de tabela incubando sob a licença open-source Apache para interoperar de forma transparente entre Apache Hudi, Delta Lake e Apache Iceberg.

Apache XTable:

• Fornece interoperabilidade omnidirecional entre tabelas de formatos de lakehouse.
• É não um novo ou formato separado. Apache XTable fornece abstrações e ferramentas para a tradução de metadados de formatos de tabela de lakehouse.

Talvez o Apache XTable seja a resposta para fornecer opções para plataformas de dados específicas e fornecedores de nuvem, enquanto ainda fornece integração e interoperabilidade simples.

Mas cuidado: Um wrapper sobre diferentes tecnologias não é uma bala de prata. Vimos isso há anos quando o Apache Beam emergiu. Apache Beam é um modelo unificado de código aberto e um conjunto de SDKs específicos de linguagem para definir e executar workflows de ingestão e processamento de dados. Ele suporta uma variedade de motores de processamento de stream, como Flink, Spark e Samza. O principal motor por trás do Apache Beam é o Google, que permite a migração de workflows no Google Cloud Dataflow. No entanto, as limitações são grandes, pois tal wrapper precisa encontrar o menor denominador comum de recursos suportados. E a principal vantagem da maioria dos frameworks é o 20% que não se encaixa em tal wrapper. Por esses motivos, por exemplo, Kafka Streams não suporta Apache Beam porque teria exigido muitas limitações de design.

Adoção de Mercado de Frameworks de Formato de Tabela

Primeiro de tudo, ainda estamos nas primeiras etapas. Ainda estamos no gatilho de inovação em termos do Ciclo de Hype do Gartner, approaching o pico das expectativas inflacionadas. A maioria das organizações está ainda avaliando, mas não adotando esses formatos de tabela em produção em toda a organização ainda.

Flashback: A Guerra dos Contêineres entre Kubernetes, Mesosphere e Cloud Foundry

O debate em torno do Apache Iceberg me lembra a guerra dos contêineres há alguns anos. O termo “Guerra dos Contêineres” se refere à competição e rivalidade entre diferentes tecnologias e plataformas de containerização no domínio do desenvolvimento de software e infraestrutura de TI.

As três tecnologias concorrentes eram Kubernetes, Mesosphere e Cloud Foundry. Aqui está para onde foi:

Cloud Foundry e Mesosphere foram pioneiros, mas o Kubernetes ainda venceu a batalha. Porquê? Nunca entendi todos os detalhes técnicos e diferenças. No final, se os três frameworks são bastante similares, tudo se resume a:

• Adoção pela comunidade
• Timing correto de lançamento de funcionalidades
• Bom marketing
• Sorte
• E alguns outros fatores

Mas é bom para a indústria de software ter um framework open-source líder para construir soluções e modelos de negócio em vez de três concorrentes.

Presente: A Guerra do Formato de Tabela entre Apache Iceberg vs. Hudi vs. Delta Lake

Obviamente, o Google Trends não é uma evidência estatística ou uma pesquisa sofisticada. Mas eu o usei muito no passado como uma ferramenta intuitiva, simples e gratuita para analisar tendências de mercado. Portanto, também usei essa ferramenta para ver se as pesquisas no Google se sobrepõem com minha experiência pessoal da adoção de mercado do Apache Iceberg, Hudi e Delta Lake (o Apache XTable ainda é muito pequeno para ser adicionado):

Obviamente, vemos um padrão semelhante ao que as guerras de contêineres mostraram há alguns anos. Não faço ideia de qual será o desfecho. E se uma tecnologia vencer, ou se os frameworks se diferenciarem o suficiente para provar que não há bala de prata, o futuro nos mostrará.

Minha opinião pessoal? Acho que o Apache Iceberg vencerá a corrida. Por quê? Eu não posso argumentar com nenhuma razão técnica. Eu apenas vejo muitos clientes em todos os setores falando sobre isso cada vez mais. E cada vez mais fornecedores começam a apoiá-lo. Mas veremos. Eu realmente não me importo quem vence. No entanto, semelhante às guerras de contêineres, acho que é bom ter um padrão único e fornecedores se diferenciando com recursos em torno dele, como é com o Kubernetes.

Mas com isso em mente, vamos explorar a estratégia atual das principais plataformas de dados e provedores de nuvem em relação ao suporte ao formato de tabela em suas plataformas e serviços de nuvem.

Estratégias de Plataforma de Dados e Fornecedores de Nuvem para Apache Iceberg

Não farei nenhuma especulação nesta seção. A evolução dos frameworks de formato de tabela avança rapidamente, e as estratégias dos fornecedores mudam rapidamente. Por favor, consulte os sites dos fornecedores para obter as informações mais recentes. Mas aqui está o status quo sobre as estratégias de plataforma de dados e fornecedores de nuvem em relação ao suporte e integração do Apache Iceberg.

• Snowflake:
  • Suporta Apache Iceberg há bastante tempo
  • Adicionando melhores integrações e novos recursos regularmente
  • Opções de armazenamento interno e externo (com compromissos) como o armazenamento do Snowflake ou Amazon S3
  • Anunciou o Polaris, uma implementação de catálogo de código aberto para Iceberg, com compromisso de apoiar a integração bidirecional, impulsionada pela comunidade e agnóstica ao fornecedor
• Databricks:
  • Foca no Delta Lake como formato de tabela e (agora com código aberto) Unity como catálogo
  • Adquiriu Tabular, a empresa líder por trás do Apache Iceberg
  • Futuro incerto da estratégia de apoiar a interface aberta do Iceberg (em ambas as direções) ou apenas para alimentar dados em sua plataforma de lakehouse e tecnologias como Delta Lake e Unity Catalog
• Confluent:
  • Incorpora Apache Iceberg como um cidadão de primeira classe em sua plataforma de streaming de dados (o produto é chamado Tableflow)
  • Converte um Kafka Topic e metadados de esquema relacionados (ou seja, contrato de dados) em uma tabela Iceberg
  • Integração bidirecional entre cargas de trabalho operacionais e analíticas
  • Análises com Flink serverless embutido e sua API unificada de lote e streaming ou compartilhamento de dados com motores de análise de terceiros como Snowflake, Databricks ou Amazon Athena
• Mais plataformas de dados e mecanismos de análise de código aberto:
  • A lista de tecnologias e serviços em nuvem que suportam Iceberg cresce a cada mês
  • Alguns exemplos: Apache Spark, Apache Flink, ClickHouse, Dremio, Starburst usando Trino (anteriormente PrestoSQL), Cloudera usando Impala, Imply usando Apache Druid, Fivetran
• Provedores de serviços em nuvem (AWS, Azure, Google Cloud, Alibaba):
  • Estratégias e integrações diferentes, mas todos os provedores de nuvem aumentam o suporte ao Iceberg em seus serviços atualmente, por exemplo:
    • Armazenamento de Objetos: Amazon S3, Azure Data Lake Storage (ALDS), Google Cloud Storage
    • Catálogos: Específicos da nuvem como AWS Glue Catalog ou agnósticos de fornecedor como Project Nessie ou Hive Catalog
    • Análises: Amazon Athena, Azure Synapse Analytics, Microsoft Fabric, Google BigQuery

Arquitetura Shift Left com Kafka, Flink e Iceberg para Unificar Cargas de Trabalho Operacionais e Analíticas

A arquitetura shift left movimenta o processamento de dados mais próximo à fonte de dados, aproveitando tecnologias de streaming de dados em tempo real como Apache Kafka e Flink para processar os dados em movimento logo após a ingestão. Esta abordagem reduz a latência e melhora a consistência e qualidade dos dados.

Ao contrário do ETL e ELT, que envolvem processamento em lote com os dados armazenados em repouso, a arquitetura shift left permite a captura e transformação de dados em tempo real. Ela se alinha ao conceito de zero-ETL tornando os dados imediatamente utilizáveis. Mas, ao contrário do zero-ETL, deslocar o processamento de dados para o lado esquerdo da arquitetura empresarial evita uma arquitetura complexa e difícil de manter emaranhada com muitas conexões ponto a ponto.

A arquitetura shift left também reduz a necessidade de ETL reverso, garantindo que os dados sejam acionáveis em tempo real tanto para sistemas operacionais quanto analíticos. No geral, essa arquitetura melhora a atualidade dos dados, reduz custos e acelera o tempo de lançamento no mercado para aplicações orientadas por dados. Saiba mais sobre este conceito em meu post no blog sobre “A Arquitetura Shift Left.”

Apache Iceberg como Formato de Tabela Aberta e Catálogo para Compartilhamento de Dados Sem Costura entre Motores Analíticos

Um formato de tabela aberta e catálogo introduz enormes benefícios na arquitetura empresarial:

• Interoperabilidade
• Liberdade de escolha dos motores analíticos
• Tempo de lançamento no mercado mais rápido
• Custo reduzido

O Apache Iceberg parece estar se tornando o padrão de fato entre fornecedores e provedores de nuvem. No entanto, ainda está em um estágio inicial e tecnologias concorrentes e envolventes como Apache Hudi, Apache Paimon, Delta Lake e Apache XTable também estão tentando ganhar força.

Iceberg e outros formatos de tabela abertos não são apenas uma grande vantagem para armazenamento único e integração com várias plataformas de análise/dados/IA/ML como Snowflake, Databricks, Google BigQuery, entre outros, mas também para a unificação de cargas de trabalho operacionais e analíticas utilizando streaming de dados com tecnologias como Apache Kafka e Flink. A arquitetura de shift left é um benefício significativo para reduzir esforços, melhorar a qualidade e consistência dos dados e permitir aplicativos e insights em tempo real em vez de em lote.

Por fim, se você ainda se pergunta quais são as diferenças entre streaming de dados e lakehouses (e como eles se complementam), assista a este vídeo de dez minutos:

 

Qual é a sua estratégia de formato de tabela? Quais tecnologias e serviços em nuvem você conecta? Vamos conversar no LinkedIn e discutir sobre isso!