AWS automatiza migração de tabelas Hive para Iceberg no S3 Tables

O que mudou

Em 4 de novembro de 2026, a AWS anunciou a migração gerenciada de tabelas Apache Hive para Apache Iceberg dentro do Amazon S3 Tables. O recurso assume as partes mais trabalhosas de uma migração de data lake: validação de compatibilidade, conversão de tipos de dado, recompressão e compactação de arquivos, geração de relatórios e sincronização repetida antes do corte final para produção.

O ponto central, descrito no AWS Builder Center por Pranav Gawai, é que a tabela Hive de origem continua recebendo gravações durante todo o processo. Em vez de congelar a plataforma de dados para rodar uma migração completa, o fluxo funciona em estágios: verificação de compatibilidade, validação de dados, cópia e conversão para uma tabela de destino somente leitura, sincronizações incrementais (só as mudanças desde a última sincronização) e, por fim, o cutover que transforma a tabela de destino em leitura e escrita.

Isso resolve um problema real de quem mantém data lake maduro: hoje, migrar de Hive para Iceberg não é trocar formato de arquivo, é lidar com metadado, catálogo, compatibilidade de engine e corte de produção sem quebrar quem já consulta aquela tabela todo dia.

Onde está disponível

A fonte cita explicitamente a disponibilidade em regiões selecionadas, dando Asia Pacific (Mumbai) como exemplo, e recomenda checar a documentação mais recente antes de planejar uma migração em produção. Ela não menciona a região América do Sul (São Paulo), sa-east-1: quem depende dessa região precisa validar diretamente no console ou na documentação da AWS se o recurso já chegou lá antes de desenhar qualquer plano de corte.

O escopo técnico também é limitado por desenho, não por bug:

Tabela em ORC, catálogo fora do Glue Data Catalog ou migração cross-account e cross-region ficam fora do escopo atual. Quem opera data lake com tabelas Hive catalogadas em um Hive Metastore externo, por exemplo, não consegue usar esse caminho gerenciado ainda.

Quanto custa

Segundo a AWS, a migração gerenciada em si não tem cobrança separada de conversão Hive para Iceberg: o que se paga é pelo volume de dados copiado pelo job de migração. Para quem usa S3 Intelligent-Tiering, os objetos de origem permanecem na camada de acesso atual durante o processo, o que evita uma recomputação de tier só por causa da migração.

Isso não zera a conta. Armazenamento, requisições, consultas no Athena e qualquer outro serviço envolvido continuam cobrando no modelo normal. Para quem cataloga tabelas no Glue e consulta via Athena, o custo adicional relevante tende a ser o de ter, por um período, dados duplicados em Hive e em Iceberg até o cutover ser concluído.

Como começar

O fluxo é operável por API, AWS CLI e SDK. A sequência básica é: iniciar a migração, revisar o relatório de compatibilidade, monitorar o progresso, sincronizar mudanças da origem, validar o destino e completar a migração.

Pelo CLI, o comando de início é:

aws s3tables start-table-migration \
 --cli-input-json file://migration-plan.json

O arquivo migration-plan.json descreve a tabela Glue de origem, o bucket de tabelas S3 de destino, o namespace e nome da tabela destino, a role do IAM usada na operação, a configuração de criptografia, as opções de conversão de dados e onde salvar o relatório de migração. A AWS não publica um schema fixo único para esse arquivo: o conteúdo exato depende da tabela de origem e do destino escolhido, então vale gerar o relatório de compatibilidade antes de fechar o plano.

Para quem trabalha com Athena e Glue no dia a dia, a AWS também disponibiliza uma skill de Agent Toolkit chamada migrating-hive-tables-to-s3-tables, pensada para um coding agent analisar políticas IAM, validar o plano de migração, executar os estágios e acompanhar o progresso. O texto da fonte é direto sobre o limite disso: o agente ajuda na orquestração, mas validação de migração e aprovação de produção continuam sendo responsabilidade do time de engenharia.

O que muda para quem já usa

No exemplo de e-commerce citado pela fonte, um data lake com cinco tabelas (orders, products, payments, customers, events), catalogadas no Glue e consultadas via Athena e Spark, deixaria de exigir uma pipeline de migração sob medida para cada tabela. Isso é a economia real para arquiteto, DevOps e SRE: menos infraestrutura de conversão para escrever, testar e manter.

O trade-off que não pode ser ignorado é o cutover. A AWS é explícita: a transição da tabela de destino de somente leitura para leitura e escrita tem uma janela de corte, e isso deve ser planejado, não tratado como operação zero-downtime. Isso muda o runbook de migração: em vez de só provisionar recursos, o time precisa agendar o cutover como evento de produção, com rollback definido caso a sincronização final falhe.

Para quem já tem Glue Data Catalog como fonte de verdade e Athena como engine principal de consulta, o ganho de Iceberg (transações ACID, evolução de schema, particionamento oculto, time travel) só se materializa depois do corte completo. Até lá, as duas tabelas (Hive e Iceberg) coexistem, e qualquer pipeline de ingestão ou dashboard precisa continuar apontando para a origem até a validação do destino estar fechada. O escopo restrito a mesma conta, mesma região e Parquet também significa que ambientes multi-conta via AWS Organizations, comuns em arquiteturas maduras, vão precisar de um passo extra de replicação antes de usar esse caminho gerenciado.

Fonte: AWS Builder Center