AWS Glue federa catálogo com Snowflake Horizon Catalog para tabelas Iceberg

O catálogo deixa de ser gargalo entre AWS e Snowflake

Um tutorial publicado na comunidade DEV, na trilha #aws, descreve como integrar Amazon S3, AWS Glue e Snowflake numa pipeline só, e chama atenção para um recurso que muda a arquitetura de referência de quem roda tabelas Iceberg nas duas plataformas: a federação de catálogo entre o Glue Data Catalog e o Snowflake Horizon Catalog.

Até pouco tempo, segundo o próprio tutorial, integrar catálogos de metadados separados podia exigir sincronização adicional de metadado e complexidade operacional extra. A federação inverte essa lógica: o Glue passa a enxergar os metadados do Horizon Catalog diretamente, sem copiar nada.

Segundo a descrição desse tutorial da comunidade DEV (não documentação oficial da AWS ou da Snowflake), o fluxo seria: o Snowflake mantém o catálogo de metadados via Horizon Catalog, o AWS Glue se conecta a esse catálogo federado, o AWS Lake Formation pode ajudar a gerenciar permissões, e o Amazon Athena consegue consultar tabelas Iceberg federadas suportadas, sem que ninguém precise exportar ou duplicar o dataset.

Por que isso pesa no desenho de arquitetura

Para arquiteto e SRE, o ganho não é "menos trabalho de ETL". É menos superfície de inconsistência. Cada cópia de metadado é mais um ponto de drift entre catálogos, de permissão divergente e de outra fonte de verdade para auditar num incidente. Reduzir isso de dois catálogos sincronizados para um catálogo federado tira um componente inteiro do raio de falha.

Mas federação de catálogo não elimina a pergunta de quem é dono do dado, só a desloca: de "onde está a cópia" para "quem administra o catálogo federado". Isso tem implicação direta em Organizations e ambiente multi-conta. Se o catálogo é administrado pelo Snowflake, o Lake Formation da conta AWS passa a depender de uma integração externa para aplicar política de acesso, não só de IAM.

A fonte recomenda, sem detalhar como, verificar sempre o método de autenticação suportado, a configuração do catálogo e a compatibilidade de tabela para o ambiente específico, antes de assumir que a federação funciona do mesmo jeito em qualquer setup. Lido por quem desenha produção, isso vira item de checklist: não existe configuração padrão documentada aqui, cada combinação de versão do Glue e do conector precisa ser validada antes de ir pra frente.

Iceberg é o que permite isso tudo

A federação só funciona porque as duas plataformas falam Iceberg. O formato de tabela aberto resolve o problema que motivou a arquitetura inteira: schema evolution, partition evolution, snapshot e time travel ficam no metadado da tabela, não presos ao motor que escreveu os dados.

Isso significa que o mesmo conjunto de arquivos Parquet em s3:// pode ser lido tanto pelo Glue e pelo Athena quanto pela Snowflake, cada um com seu próprio engine de consulta, sem um ETL de exportação no meio. Para quem desenha pipeline, Iceberg deixa de ser só mais um formato de arquivo e vira a interface de contrato entre plataformas, o papel que uma API bem versionada cumpre entre dois sistemas.

O trade-off é que nem toda feature do Iceberg é suportada igualmente nos dois lados. O material deixa claro que o padrão exato de integração depende de quem é dono do catálogo, das permissões concedidas, das features de tabela suportadas e do engine de consulta usado em cada ponta. Isso é arquitetura de referência sem SLA fechado: antes de comprometer um pipeline crítico a essa federação, vale rodar uma prova de conceito testando exatamente as operações (merge, time travel, alteração de schema) que o workload vai precisar.

Amazon Quick e Snowflake Cortex: IA sobre o mesmo dado, sem mover nada

O outro ponto do tutorial é a integração entre Amazon Quick e o Snowflake Cortex AI via Model Context Protocol (MCP). A ideia é dar uma interface de linguagem natural, do tipo "quais produtos geraram mais receita este trimestre?", sobre dados que continuam vivendo e sendo governados dentro do Snowflake.

Do ponto de vista de quem opera a infraestrutura, o ponto relevante não é a conversa em si: é o que ela evita. Sem essa integração, a alternativa comum seria replicar dado num data warehouse paralelo só para alimentar um chatbot de BI. Segundo a descrição do tutorial, que não é documentação oficial da AWS ou da Snowflake, o MCP funcionaria como protocolo de acesso aos recursos do Cortex (que, segundo a fonte, pode dar suporte a análise estruturada, busca em documento e interação com agente) sem que o Amazon Quick precise reimplementar lógica própria de acesso a dado.

Isso reforça o padrão que emerge do material inteiro: a tendência não é mais escolher entre AWS ou Snowflake, é desenhar o ambiente para que cada plataforma seja dona do que já faz bem, e federar acesso em vez de replicar dado.

O checklist de produção que a fonte lista (e o que fica de fora)

O tutorial organiza os cuidados de produção em quatro frentes. Resumindo o que interessa a quem vai operar isso num ambiente real:

• Segurança: papel IAM com privilégio mínimo, credencial fora do script em gerenciador de segredo, autenticação OAuth em vez de senha fixa, criptografia em trânsito e em repouso, RBAC do lado Snowflake e Lake Formation do lado AWS.
• Qualidade: validar schema na entrada, tratar nulo e duplicata, rastrear registro rejeitado, reconciliar contagem entre origem e destino.
• Performance: formato de arquivo e particionamento adequados, evitar shuffle desnecessário no Spark, dimensionar worker do Glue pelo volume real, dimensionar warehouse do Snowflake pela demanda de query.
• Custo: evitar job de Glue superdimensionado, configurar auto-suspend do warehouse Snowflake, monitorar custo de armazenamento e de request no S3, processar de forma incremental em vez de recarregar a base inteira.

O que o material não cobre, e que importa num ambiente de produção real na AWS: ele não fala em região (sa-east-1 não aparece em nenhum momento) nem em preço de nenhum dos serviços, nem no caminho de rede entre Glue e Snowflake. Se a conectividade passa por internet pública, VPC peering ou AWS PrivateLink muda completamente o desenho de segurança e o custo de transferência entre as duas plataformas. Isso precisa ser resolvido caso a caso, não há valor de referência no tutorial.

Quando federar catálogo compensa, e quando só complica

Catalog federation e Iceberg fazem sentido quando o dado já está espalhado entre S3 e Snowflake por motivo de negócio (times diferentes, contratos diferentes, histórico de migração) e a alternativa seria duplicar terabytes só para dar acesso cruzado. Nesse cenário, menos cópia de dado significa menos custo de armazenamento e menos risco de divergência entre ambientes.

Não compensa, pelo menos não ainda, para quem desenha um pipeline novo do zero com volume pequeno e um único time operando tudo. Nesse caso, a complexidade operacional extra (dois catálogos para entender, conector específico de versão, autenticação federada) supera o ganho. Um pipeline direto de Glue para Snowflake, sem federação, resolve com menos peça móvel.

O recado prático para quem está avaliando essa arquitetura: antes de desenhar em torno de federação de catálogo, vale medir o volume de dado que hoje é duplicado entre as duas plataformas. Se esse número for pequeno, a complexidade da federação não se paga.

Fonte

DEV Community, trilha #aws: "AWS + Snowflake: Building Modern Data and AI Workflows with Glue, S3, Iceberg, and Cortex" (https://dev.to/omayrashraf/aws-snowflake-building-modern-data-and-ai-workflows-with-glue-s3-iceberg-and-cortex-ffo)

Fonte: DEV Community — #aws