O AWS Glue 6.0 é uma atualização relevante para quem opera pipelines de dados em AWS e precisa reduzir custo sem abrir mão de compatibilidade moderna. A nova versão ficou 30% mais barata que as anteriores do Glue para Spark e passou a oferecer suporte completo ao Apache Iceberg v3, junto de upgrades de runtime que afetam performance, bibliotecas e integração com o restante do data lake. Para times de engenharia, a pergunta deixou de ser se a versão é interessante, e passou a ser quando migrar e com quais guardrails.
Principais destaques para decidir rápido
- Há economia direta: a AWS anunciou redução de 30% no preço do Glue 6.0 em relação às versões anteriores.
- O runtime mudou bastante: Spark 4.1.1, Python 3.13, Scala 2.13.17 e Java 17 passam a compor a base da versão.
- O Iceberg v3 chegou de forma ampla: VARIANT, deletion vectors, row lineage, timestamps em nanossegundos e tipos geo fazem parte do pacote.
- Nem toda a stack acompanha no mesmo ritmo: a documentação de migração alerta que tabelas Iceberg v3 criadas no Glue 6.0 ainda não são lidas pelo Athena SQL.
- A economia real pode ser maior: no Big Data Blog da AWS, benchmarks TPC-DS em 3 TB indicam até 36% de melhoria em price performance frente ao Glue 5.1.
O corte de preço é real, mas o impacto maior está no custo efetivo por workload
A redução de preço é concreta e já torna o Glue 6.0 atraente para workloads recorrentes. Só que o ganho mais importante para times maduros não está apenas na tabela de preço, e sim no custo efetivo por pipeline entregue, porque a nova base técnica pode reduzir tempo de execução, retrabalho e ajustes manuais.
Isso importa especialmente em ambientes com picos, reprocessamentos frequentes e janelas curtas de ETL. Se um job fica mais barato e ainda aproveita melhor o runtime, o efeito composto aparece no orçamento mensal, na previsibilidade de escala e até no dimensionamento de equipes. É por isso que o anúncio da AWS chama atenção, mas a decisão correta depende de medir custo por job, latência, dependências e compatibilidade do ecossistema.
O que muda na prática entre o Glue 5.1 e o Glue 6.0
A mudança não é cosmética. O Glue 6.0 avança o runtime para Spark 4.1.1, Python 3.13, Scala 2.13.17 e Java 17, além de atualizar os Open Table Formats para Hudi 1.1.1, Iceberg 1.11.0 e Delta Lake 4.2.0.
| Aspecto | Glue 5.1 | Glue 6.0 |
|---|---|---|
| Apache Spark | 3.5.6 | 4.1.1 |
| Python | 3.11 | 3.13 |
| Scala | 2.12.18 | 2.13.17 |
| Iceberg | sem suporte v3 completo | Iceberg 1.11.0 com formato v3 |
| Conector S3 | compatibilidade anterior | S3A como único conector S3 |
Além disso, entram recursos de produtividade que tendem a reduzir código operacional, como Spark Declarative Pipelines, Spark Connect para Interactive Sessions, Arrow-native Python UDFs, real-time mode para streaming stateless e virtual environments gerenciados pelo cliente para Python. Para equipes que mantêm muitos jobs, isso pode representar menos scripts auxiliares e menos ajustes fora do core do pipeline.
Por que o suporte completo ao Apache Iceberg v3 muda o desenho do data lake
O avanço mais estratégico do Glue 6.0 é o suporte completo ao Iceberg v3. Isso aproxima o serviço de uma arquitetura de data lake mais flexível para dados semiestruturados, atualizações em nível de linha e modelos analíticos que pedem governança sem sacrificar performance.
Na lista oficial da AWS, os recursos mais relevantes são o tipo VARIANT, que facilita o tratamento de dados semiestruturados com shredding automático para leituras mais rápidas, os deletion vectors para updates eficientes em nível de linha, o row lineage tracking, timestamps com precisão de nanossegundos e os tipos geometry e geography. Há ainda mecanismos de evolução de schema mais flexíveis, como UNKNOWN e valores DEFAULT em colunas.
Na prática, isso faz diferença quando o pipeline não lida só com tabelas estáveis e colunas previsíveis. Times que ingerem eventos, JSONs ricos, dados espaciais ou workloads com merge frequente tendem a sentir mais valor nessa versão do que times com ETLs simples e batch tradicional.
A pergunta mais importante é: seu ecossistema já acompanha o Iceberg v3?
Nem sempre vale ativar tudo no dia 1. A lacuna mais importante fora do material promocional está na compatibilidade entre engines, porque a própria documentação de migração da AWS informa que tabelas Iceberg v3 criadas no Glue 6.0 ainda não podem ser lidas pelo Athena SQL, que retorna erro de versão não suportada.
Esse ponto muda completamente a priorização do projeto. Se seu data lake depende de múltiplos consumidores, a migração do job ETL pode precisar ser separada da migração do formato de tabela. Em outras palavras, é possível adotar o Glue 6.0 primeiro pelos ganhos de runtime e custo, enquanto o uso pleno do Iceberg v3 entra depois, quando as engines consumidoras estiverem alinhadas.
Quais componentes merecem revisão antes da migração?
- JARs e conectores compilados para Spark antigo ou Scala 2.12.
- Dependências que ainda exigem AWS SDK for Java v1, removido no Glue 6.0.
- Integrações que dependiam de EMRFS, já que o S3A passou a ser o único conector S3.
- Bibliotecas Python sem suporte ou sem wheels adequados para Python 3.13.
- Ferramentas consumidoras que ainda não leem Iceberg table version 3.
Quando a migração faz sentido financeiro e operacional
O melhor cenário para migrar é aquele em que o ambiente já sofre com conta alta de ETL, backlog de evolução técnica ou necessidade de lidar melhor com dados semiestruturados. Nesses casos, Glue 6.0 tende a entregar valor em duas frentes: redução direta de preço e simplificação do desenho da plataforma.
Já em ambientes muito acoplados a bibliotecas antigas ou a consumers que não suportam Iceberg v3, a recomendação é migrar em ondas. Primeiro, validar compatibilidade e runtime. Depois, liberar recursos novos de formato de tabela. Esse caminho reduz risco de indisponibilidade analítica, algo crítico para operações que não podem parar.
Checklist objetivo para um piloto seguro
- Inventarie jobs por criticidade e dependências externas.
- Mapeie bibliotecas Python, JARs e conectores por versão.
- Valide consumers do data lake antes de criar tabelas v3.
- Compare tempo de execução, custo por job e taxa de falha entre 5.1 e 6.0.
- Teste rollback e reprocessamento antes de ampliar a adoção.
Onde a Interserv Cloud pode acelerar a adoção sem aumentar risco
Para empresas com operação crítica, a discussão sobre Glue 6.0 não deveria ficar restrita ao anúncio de produto. O ponto central é como transformar a atualização em ganho mensurável de custo, escala e resiliência, sem quebrar compatibilidade no data lake nem criar surpresas em auditoria ou observabilidade.
É exatamente nesse tipo de transição que a Interserv Cloud agrega valor: avaliação de arquitetura em AWS, revisão de dependências, endurecimento do ambiente, desenho de rollout por ondas e monitoramento contínuo da operação. Em vez de migrar apenas porque a versão é nova, a decisão passa a ser guiada por risco, impacto financeiro e continuidade do negócio.
Perguntas frequentes
O AWS Glue 6.0 já está disponível para uso geral?
Sim. O AWS Glue 6.0 já está em disponibilidade geral desde 21 de agosto de 2026. A versão chegou com redução de preço de 30% em relação às versões anteriores do Glue para Spark, além de atualizações importantes no runtime e no suporte a formatos abertos de tabela.
O que muda de verdade ao migrar do AWS Glue 5.1 para o 6.0?
O principal ganho é unir custo menor com um runtime mais moderno. O Glue 6.0 atualiza Spark para 4.1.1, Python para 3.13 e Scala para 2.13.17, além de trazer recursos que simplificam ETL, melhoram performance em PySpark e ampliam compatibilidade com data lakes baseados em Iceberg.
O suporte ao Apache Iceberg v3 no Glue 6.0 é realmente completo?
O suporte completo ao Apache Iceberg v3 inclui recursos como tipo VARIANT, deletion vectors, row lineage tracking, timestamps em nanossegundos e tipos geoespaciais. Na prática, isso melhora o tratamento de dados semiestruturados, atualizações em nível de linha e casos de uso analíticos mais complexos em data lakes.
Há algum risco de compatibilidade ao adotar Iceberg v3 agora?
Não imediatamente. A própria documentação de migração da AWS aponta que tabelas Iceberg v3 criadas no Glue 6.0 não podem ser lidas pelo Athena SQL no momento, que retorna erro por versão não suportada. Por isso, a migração deve considerar compatibilidade entre engines, não só o job ETL.
Quais cuidados de migração merecem mais atenção?
Os pontos mais críticos são dependências compiladas para versões antigas de Spark ou Scala, uso de AWS SDK for Java v1 e mudanças no conector de S3, já que o EMRFS foi removido e o S3A passou a ser o único conector S3 no Glue 6.0. Bibliotecas Python também devem ser revisadas para Python 3.13.
