Como migrar do BigQuery para um lakehouse aberto na AWS com Apache Iceberg

A AWS publicou uma arquitetura de referência para sair do data warehouse do Google e montar um lakehouse em S3 com Apache Iceberg, onde Athena, Redshift e EMR consultam a mesma cópia do dado.

A AWS publicou uma arquitetura de referência para sair do data warehouse do Google e montar um lakehouse em S3 com Apache Iceberg, onde Athena, Redshift e EMR consultam a mesma cópia do dado.

O problema

Quem roda um data warehouse fechado conhece o acordo implícito: em troca de conveniência, o armazenamento, o catálogo e o motor de consulta ficam fundidos no runtime de um único fornecedor. Funciona bem até o dia em que você precisa trocar de motor, compartilhar dado com outro time em outra nuvem, ou plugar um modelo de IA que não fala a língua proprietária daquele warehouse.

É o cenário que a AWS descreve no post Migrate Google BigQuery to an open lakehouse on AWS with Apache Iceberg, publicado no AWS Big Data Blog. O argumento não é "BigQuery é ruim": é que analytics multiengine, IA generativa e compartilhamento de dado entre equipes ficam mais caros quando o dado só existe dentro do formato de um vendor.

Interchangeability becomes a property of the architecture rather than something you engineer around.

Interchangeability becomes a property of the architecture rather than something you engineer around.AWS Big Data Blog

Traduzindo: a capacidade de trocar de motor de consulta deixa de ser algo que você constrói com pipelines de ETL para empurrar dado de um sistema a outro, e passa a ser uma propriedade da própria arquitetura. É essa promessa que sustenta o resto do post.

A arquitetura

A AWS recomenda uma arquitetura medallion (bronze, silver, gold) com Apache Iceberg como camada de armazenamento comum. O fluxo, da fonte ao consumidor final, segue este caminho:

1. Ingestão: dados chegam por caminhos diferentes conforme a origem. Migração em lote usa EXPORT DATA do BigQuery para exportar tabelas em Parquet para o Google Cloud Storage, seguido de AWS DataSync movendo esses arquivos para o Amazon S3. Fontes SaaS (Salesforce, SAP, ServiceNow, HubSpot, Google Analytics) entram via integrações Zero-ETL. Bancos operacionais usam CDC com conectores Debezium rodando em Amazon MSK Connect. Fontes de streaming usam Amazon Kinesis Data Streams ou Amazon MSK direto.
2. Camada bronze (raw): o dado pousa como está, já em formato Iceberg, em Amazon S3 Tables (gerenciado) ou em buckets S3 com Iceberg self-managed.
3. Camada silver (trusted): jobs do AWS Glue e do Amazon EMR com Spark limpam, conformam e transformam o dado em tabelas Iceberg confiáveis. O Amazon Athena consulta essa camada direto, sem cópia, para exploração interativa.
4. Camada gold (serving): o Amazon Redshift Serverless serve dado curado para BI e dashboard, podendo também materializar em Redshift Managed Storage quando o workload exige desempenho acima do que o Iceberg entrega sozinho.
5. Catálogo e governança: o AWS Glue Data Catalog expõe um endpoint REST Catalog compatível com a especificação aberta Apache Iceberg REST Catalog, e o AWS Lake Formation aplica permissões em nível de banco, tabela, coluna, linha e célula, válidas para qualquer engine que toque o dado.
6. Consumo: a mesma cópia de dado alimenta ferramentas de BI (Amazon Quick Suite, Looker, Power BI, Tableau), agentes de IA via Amazon Bedrock AgentCore, treino e inferência no Amazon SageMaker AI, e, pelo REST Catalog, engines de terceiros como Snowflake e Databricks.

Duas camadas cruzam o diagrama inteiro em vez de ocupar uma etapa: orquestração (Amazon MWAA, AWS Step Functions, Amazon EventBridge) coordena a sequência bronze → silver → gold, e segurança/observabilidade (IAM, AWS KMS, CloudWatch, CloudTrail, Cost Explorer) cobre autenticação, criptografia, auditoria e custo em todo o pipeline.

Os serviços envolvidos

Trade-offs

O ganho de portabilidade não é de graça, e vale nomear o preço em termos do Well-Architected Framework.

Excelência operacional: trocar um warehouse fechado por um lakehouse multiengine significa operar mais peças. Em vez de um único console BigQuery, o time passa a manter Glue Data Catalog, Lake Formation, Athena, Redshift e possivelmente EMR, cada um com seu próprio ciclo de patch, IAM role e monitoramento. O Amazon SageMaker Unified Studio existe justamente para mitigar essa fragmentação, oferecendo um ponto único de descoberta e desenvolvimento sobre as mesmas permissões do Lake Formation.

Otimização de custos: BigQuery on-demand cobra $6.25 por terabyte escaneado, segundo o próprio post da AWS. O Amazon Athena também cobra por dado escaneado, mas o Amazon Redshift é cobrado por capacidade de computação, não por consulta. Comparar os dois modelos lado a lado é enganoso: a AWS recomenda rodar três níveis de consulta (leve, média e pesada) contra o motor alvo, multiplicar pela frequência de execução de cada tipo, somar o custo de armazenamento e só então comparar com a fatura mensal atual do BigQuery.

Confiabilidade: o Apache Iceberg garante transações ACID e leitura/escrita concorrente em escala de petabytes entre engines diferentes, o que elimina uma classe inteira de inconsistência que apareceria se cada engine mantivesse sua própria cópia do dado.

Segurança: a troca de um único runtime de warehouse por múltiplos engines exige que a governança seja desenhada para ser transversal desde o início. É exatamente o papel do Lake Formation: a permissão é definida uma vez no catálogo e vale para o job Spark no EMR, a consulta no Athena e o treino no SageMaker AI, sem reimplementar a regra em cada serviço.

Custo estimado

O post não fornece uma calculadora pronta de BigQuery para AWS, porque os dois modelos de precificação não são diretamente comparáveis: BigQuery on-demand cobra por terabyte escaneado ($6.25/TB, segundo a fonte), enquanto Amazon Redshift é cobrado por capacidade de computação provisionada ou serverless. Para chegar a um número confiável, a recomendação da AWS é rodar um benchmark representativo em vez de comparar preço de lista.

O roteiro sugerido para montar o TCO:

• Separe as consultas em três faixas: leves (lookups e agregações simples), médias (joins e transformações moderadas) e pesadas (joins complexos, window functions, varreduras grandes).
• Multiplique o custo de cada faixa pela frequência real de execução.
• Some o custo de armazenamento mensal projetado para o S3.
• Compare o total mensal resultante com a fatura atual do BigQuery.

Um detalhe que a fonte destaca e que costuma passar batido: o BigQuery tem dois modelos de billing de armazenamento, lógico e físico, e o tamanho físico comprimido pode ser uma fração pequena do tamanho lógico. Antes de estimar quanto vai custar guardar o mesmo dado em S3, vale medir os bytes físicos reais de cada dataset, não o tamanho lógico que aparece por padrão no console do BigQuery, porque isso muda materialmente a escolha de storage class no S3.

Como adaptar

A AWS propõe quatro fases, e cada uma entrega algo que dá para validar antes de seguir para a próxima:

1. Avaliar e descobrir: inventariar datasets, views, stored procedures, scheduled queries e consumidores downstream (Looker Studio, Connected Sheets, aplicações que leem o BigQuery direto). Classificar SQL em ANSI padrão (migra direto) versus sintaxe específica do BigQuery (STRUCT, ARRAY, UNNEST, UDFs em JavaScript). Medir volume de dado em bytes físicos, não lógicos.
2. Desenhar a arquitetura alvo: definir layout de bucket S3 em camadas, escolher entre S3 Tables gerenciado ou Iceberg self-managed conforme a necessidade de controle fino sobre compactação, e decidir o motor por workload. A régua da fonte: Athena serve bem estimativas de volume moderado por dia com tolerância de alguns segundos de latência; Redshift fica melhor quando há concorrência sustentada, metas de dashboard abaixo de um segundo, ou volume escaneado diário alto o suficiente para que computação provisionada saia mais barata que pagar por terabyte.
3. Converter e validar em uma prova de conceito: pegar uma fatia representativa (algumas tabelas e os dashboards que as leem) e converter o SQL. STRUCT vira struct do Iceberg, ARRAY vira list, MERGE do BigQuery vira MERGE INTO no Athena ou Redshift (copy-on-write para tabelas atualizadas em lote, merge-on-read para as atualizadas com frequência), UDFs em JavaScript viram expressão SQL ou função Lambda via USING EXTERNAL FUNCTION. Validar comparando contagem de linhas, checksum por tabela e tempo de execução contra o BigQuery.
4. Migrar o dado: para a carga em lote, EXPORT DATA do BigQuery grava Parquet no Google Cloud Storage, e o AWS DataSync transporta esses arquivos para o S3, onde entram como tabela Iceberg na camada bronze.

Para quem cuida de bucket S3 no dia a dia, de job no Glue ou de consulta no Athena, o ponto prático é este: a decisão de engine por workload (passo 2) é reversível justamente porque o dado mora em Iceberg sobre S3, não dentro de um motor específico. Errar a escolha entre Athena e Redshift custa reconfigurar consumo, não reconstruir o dado do zero. É essa reversibilidade, mais do que qualquer feature isolada do Iceberg, que sustenta o argumento de portabilidade do post.

Fonte

1. AWS Big Data Blog: Migrate Google BigQuery to an open lakehouse on AWS with Apache Iceberg

Fonte: AWS Big Data Blog