Lakehouse em Apache Iceberg sem vendor lock-in

Um lakehouse em Apache Iceberg armazena os dados em arquivos abertos, no armazenamento de objetos da sua nuvem, e descreve cada tabela em um formato aberto que diversos motores de consulta conseguem ler e escrever. É isso que reduz o vendor lock-in: os dados deixam de depender do motor que os lê. Você pode consultar as mesmas tabelas com mais de um motor, trocar de motor sem migrar os dados e pagar armazenamento e processamento separadamente.

Este artigo explica como o Iceberg funciona, em que ponto ele resolve o lock-in, em que ponto ele não resolve e o que considerar antes de migrar.

O problema que o Iceberg resolve

Durante muito tempo, as empresas tinham duas opções para dados analíticos:

Data warehouse: tabelas confiáveis, transações e SQL rápido. Em contrapartida, os dados ficam em um formato e em um armazenamento controlados pelo fornecedor, e sair dele significa exportar tudo.
Data lake: arquivos de baixo custo em um armazenamento de objetos, em formatos abertos como o Parquet. Em contrapartida, não há transações: duas escritas simultâneas podem corromper uma tabela, e alterar uma coluna vira um projeto.

Um lakehouse reúne o melhor dos dois: tabelas com transações e evolução de esquema, sobre arquivos abertos em um armazenamento de baixo custo. Os formatos de tabela abertos — como Apache Iceberg, Delta Lake e Apache Hudi — são a peça que torna isso possível. Este artigo trata do Iceberg, um projeto da Apache Software Foundation.

Como uma tabela Iceberg funciona

Uma tabela Iceberg tem três camadas:

Arquivos de dados, normalmente em Parquet, no armazenamento de objetos (S3, GCS, Azure Blob).
Metadados: arquivos que listam quais arquivos de dados compõem cada versão da tabela, com estatísticas por coluna que permitem ignorar arquivos inteiros durante uma consulta.
Catálogo: guarda a referência para o arquivo de metadados atual de cada tabela.

Cada escrita gera uma nova versão (um snapshot) e atualiza essa referência no catálogo de forma atômica. Daí vêm as propriedades que importam no dia a dia:

Transações ACID. Ou a escrita aparece por inteiro, ou não aparece. Quem lê nunca vê uma tabela pela metade.
Evolução de esquema. As colunas são identificadas por um identificador, não pelo nome: renomear, reordenar ou acrescentar colunas não reescreve os dados.
Particionamento oculto. A tabela registra como foi particionada (por dia, por mês, por faixa), e quem consulta filtra pela coluna original, sem precisar conhecer a partição. O particionamento pode mudar ao longo do tempo sem reescrever o histórico.
Viagem no tempo. É possível consultar a tabela como ela estava em um snapshot anterior e reverter uma carga com erro.

Onde o Iceberg reduz o lock-in

Os dados ficam no seu armazenamento. Os arquivos estão no bucket da sua conta de nuvem, em Parquet. Trocar de motor não exige exportar nada.
Mais de um motor sobre as mesmas tabelas. Spark, Trino e Flink, além dos principais data warehouses em nuvem, oferecem suporte a tabelas Iceberg, com diferentes níveis de suporte à leitura e à escrita. Um time pode transformar os dados com um motor e atender às consultas com outro.
Troca de motor sem migração de dados. Se o custo ou o desempenho de um motor deixar de fazer sentido, a tabela continua onde está; muda apenas o motor que a lê.
Armazenamento e processamento separados. Você paga o armazenamento de objetos pelo volume armazenado e o processamento apenas enquanto ele está em execução.

Onde o Iceberg, sozinho, não resolve

Formato aberto não é sinônimo de ausência de lock-in. Três pontos merecem atenção:

O catálogo. É o catálogo que indica qual é a versão atual de cada tabela. Se ele for proprietário e não usar um protocolo aberto, você troca a dependência do formato pela dependência do catálogo. Prefira catálogos que implementem a especificação REST do Iceberg, já suportada por diversos motores e serviços.
Recursos exclusivos do motor. Visões materializadas, funções e otimizações específicas de um fornecedor continuam presas a ele. Mantenha a lógica de negócio em SQL portável e versionado, de preferência em uma camada de transformação como o dbt.
Suporte desigual. Nem todo motor implementa todos os recursos da especificação ao mesmo tempo. Antes de escolher, confira se os motores que você pretende usar suportam, na leitura e na escrita, os recursos de que você vai precisar, como exclusões em nível de linha.

Custo: o que muda na prática

O custo de um lakehouse se mantém previsível quando três hábitos fazem parte da rotina:

Particionar pelos campos mais usados nos filtros. Com estatísticas por arquivo e partições alinhadas aos filtros mais comuns, a consulta lê apenas uma fração da tabela.
Compactar arquivos pequenos. Cargas frequentes geram muitos arquivos pequenos, que tornam as consultas mais lentas e mais caras. A compactação periódica agrupa esses arquivos em arquivos maiores.
Expirar snapshots antigos. Cada versão mantém referências a arquivos antigos. Definir um prazo de retenção e remover arquivos órfãos evita pagar por dados que ninguém consulta mais.

Essas tarefas de manutenção precisam de um responsável e de uma rotina; sem elas, o lakehouse fica lento e caro com o tempo.

Como migrar sem parar a operação

A migração de um data warehouse, ou de um data lake sem transações, para o Iceberg não precisa ser um projeto de tudo ou nada:

Comece pelas tabelas que mais pesam no custo ou nas decisões. Elas mostram o ganho mais cedo.
Crie as tabelas Iceberg ao lado das atuais e carregue o histórico. Tabelas em Parquet em um data lake podem, em muitos casos, ser registradas como Iceberg sem reescrever os arquivos.
Mantenha as duas em paralelo por um período, comparando contagens e indicadores, até ganhar confiança nos resultados.
Migre os consumidores — painéis, modelos, aplicações — para a nova tabela, um de cada vez.
Desative a tabela antiga apenas depois que o último consumidor tiver migrado.

O sistema atual continua funcionando até a troca, e cada etapa pode ser revertida.

Checklist de decisão

Os dados ficarão em um bucket da sua conta de nuvem?
O catálogo usa um protocolo aberto, suportado por outros motores?
Os motores que você vai usar suportam os recursos de que você precisa?
A lógica de negócio está em SQL portável e versionado?
Há um responsável e uma rotina para compactação, expiração de snapshots e remoção de arquivos órfãos?
A migração começa pelas tabelas de maior ganho, com um período em paralelo?

Como a Coding4u trabalha isso

A Coding4u monta lakehouses em formatos de tabela abertos, como o Apache Iceberg, sobre o armazenamento de objetos da AWS, da GCP ou da Azure, consultados por Databricks, Snowflake ou outro motor compatível — para que os dados continuem sendo seus, mesmo que um dia você troque de nuvem. Os detalhes estão em Data lakehouse. A conversa de 30 minutos e o diagnóstico inicial não têm custo, e você sai deles com uma proposta.