Durante muitos anos, falar de analytics em escala significava falar de arquiteturas caras, complexas e difíceis de expandir. Data warehouses tradicionais dependiam de appliances on-premises, alto investimento inicial e longos ciclos de planejamento de capacidade. Quando o volume de dados crescia, a infraestrutura precisava crescer junto. Quando a performance se tornava um gargalo, muitas vezes a resposta era comprar mais hardware.
O Amazon Redshift mudou essa conversa ao trazer para a AWS um data warehouse distribuído, gerenciado e elástico, capaz de processar grandes volumes analíticos sem exigir que as empresas sustentassem toda a complexidade física das plataformas tradicionais.
Desde seu lançamento, em 2013, o Redshift passou por várias gerações arquiteturais. Evoluiu de modelos mais acoplados de computação e armazenamento para o RA3 com managed storage, avançou para o Redshift Serverless, fortaleceu recursos como data sharing, integração com formatos abertos e aproximação com arquiteturas lakehouse.
Agora, com a chegada do Amazon Redshift RG baseado em AWS Graviton, estamos diante de uma mudança que vai além de uma nova família de instâncias.
O Redshift RG representa uma alteração importante na forma como o Redshift processa dados entre o data warehouse e o data lake.
Redshift em poucas palavras
O Amazon Redshift é o serviço de data warehouse analítico da AWS. Ele foi criado para armazenar, organizar e consultar grandes volumes de dados com foco em análise.
Diferente de bancos transacionais, como PostgreSQL, MySQL ou SQL Server em workloads OLTP, o Redshift não foi desenhado para registrar uma venda individual ou atualizar o saldo de uma conta em milissegundos. Ele foi desenhado para responder perguntas analíticas sobre grandes massas de dados.
Uma pergunta transacional seria: “qual é o status do pedido 123?”. Uma pergunta analítica seria: “qual foi o faturamento por região, categoria de produto e canal de aquisição nos últimos doze meses?”.
Para responder esse segundo tipo de pergunta, o Redshift usa uma arquitetura MPP, ou Massively Parallel Processing. Em vez de uma única máquina tentar processar tudo sozinha, o trabalho é distribuído entre múltiplos nós. Além disso, o Redshift usa armazenamento colunar, muito eficiente para analytics porque permite ler apenas as colunas necessárias em uma consulta.
Na prática, o Redshift costuma ser usado como uma camada central de decisão para dashboards de BI, relatórios financeiros, análises de risco, marketing, produto, operações, ciência de dados, pipelines ETL/ELT e, cada vez mais, workloads orientados por IA.
Onde entram S3, Glue e Spectrum
Analytics moderno não acontece apenas dentro do data warehouse. Muitas organizações armazenam volumes massivos de dados no Amazon S3, o serviço de object storage da AWS. O S3 se tornou a base natural dos data lakes porque permite armazenar dados em grande escala, com flexibilidade e custo relativamente baixo.
Um data lake pode conter arquivos CSV, eventos em JSON, datasets em Parquet, logs históricos, exports de aplicações e tabelas Apache Iceberg. O S3 guarda os arquivos, mas armazenar não basta. O grande desafio é consultar esses dados de forma eficiente.
Foi nesse ponto que o Redshift Spectrum se tornou tão importante.
O Spectrum permitiu que o Redshift consultasse dados diretamente no S3 sem precisar carregá-los para dentro do cluster. Isso viabilizou arquiteturas híbridas em que dados mais quentes, estruturados e frequentemente acessados ficavam dentro do Redshift, enquanto dados históricos, massivos ou menos acessados permaneciam no data lake.
Para o usuário, a experiência parecia simples: era SQL. Uma consulta podia fazer join entre uma tabela interna do Redshift e uma tabela externa armazenada no S3. Mas, por trás dessa simplicidade, existia uma separação arquitetural importante. O Redshift coordenava a query, enquanto o scan dos arquivos externos era executado por uma infraestrutura separada do Spectrum.
O AWS Glue entra nesse desenho como o catálogo de metadados. Ele descreve os dados armazenados no S3: tabelas, colunas, tipos, partições, formatos e localizações. Quando criamos um external schema no Redshift apontando para um database do Glue, estamos dizendo ao Redshift como interpretar aquelas tabelas externas.
Esse modelo era poderoso, mas também trazia complexidade. Tabelas externas não se comportavam exatamente como tabelas internas. Performance, permissões, formatos de arquivo, particionamento, IAM Roles, acesso ao S3, Glue Catalog e cobrança por terabyte escaneado faziam parte do modelo operacional.
O papel do RA3
Antes do RG, uma das maiores evoluções do Redshift foi o RA3.
O RA3 trouxe managed storage e uma separação mais clara entre computação e armazenamento. Em gerações anteriores, escalar um cluster muitas vezes significava aumentar compute e storage juntos. Isso podia gerar desperdício, porque uma empresa podia precisar de mais armazenamento, mas não necessariamente de mais CPU.
Com RA3, os nós passaram a usar SSD local como cache de alta performance e Redshift Managed Storage, baseado em S3, como camada durável. Isso permitiu dimensionar clusters mais pelo perfil do workload do que apenas pelo volume total armazenado.
O RA3 foi uma grande evolução em flexibilidade, custo e performance. Mas, para consultas em data lake, ele ainda dependia do Spectrum, e é exatamente aqui que o RG muda a arquitetura.
O que muda com o Amazon Redshift RG
O Amazon Redshift RG é a nova família de instâncias provisionadas do Redshift baseada em AWS Graviton. O Graviton é a família de processadores Arm desenvolvida pela própria AWS para entregar melhor custo-performance em workloads de nuvem.
Mas, no caso do Redshift RG, a mudança mais importante não é apenas o processador. A principal mudança é arquitetural.
Com RG, o Redshift passa a processar consultas em data lake diretamente nos nós do cluster. Em outras palavras, o mesmo compute que processa workloads de data warehouse também passa a processar queries sobre dados no S3. Isso remove a dependência da fleet separada do Spectrum nos clusters RG.
No RA3, o modelo mental era: Redshift para warehouse, Spectrum para data lake.No RG, o modelo passa a ser: Redshift como engine único para warehouse e data lake.
Essa é a grande virada.
Engine integrado de data lake
Quando falamos em engine integrado de data lake, estamos dizendo que o Redshift deixa de delegar o processamento externo para uma camada separada. Scans em formatos como Apache Iceberg e Parquet passam a acontecer dentro do compute do próprio cluster RG.
Essa arquitetura se conecta diretamente a conceitos importantes do analytics moderno, como execução vetorizada e data pruning.
Execução vetorizada significa processar dados em blocos, e não linha por linha, aproveitando melhor a CPU em workloads analíticos. Data pruning significa evitar leitura desnecessária. Se uma query precisa apenas de dados de um determinado mês, não faz sentido ler arquivos de anos anteriores.
Em formatos como Apache Iceberg, os metadados ajudam o engine a identificar quais arquivos realmente precisam ser lidos. Quanto menos dado irrelevante é processado, menor tende a ser a latência e menor o consumo de recurso.
Parquet e Iceberg são peças importantes nessa discussão. Parquet é um formato colunar muito usado em analytics porque permite compressão eficiente e leitura seletiva de colunas. Apache Iceberg vai além do formato de arquivo: ele cria uma camada de tabela sobre arquivos no S3, com metadados, snapshots, evolução de schema, particionamento e suporte a múltiplos engines.
É por isso que o Redshift RG se aproxima tanto da visão lakehouse: uma arquitetura que tenta combinar a flexibilidade e o baixo custo do data lake com a governança, estrutura e performance do data warehouse.
O que melhora
O primeiro ganho é performance, especialmente em workloads que combinam dados internos e externos ou usam formatos como Iceberg e Parquet.
O segundo é custo. Como o RG remove a fleet separada do Spectrum para queries em data lake, também remove a cobrança por terabyte escaneado do Spectrum nos clusters RG.
O terceiro é simplicidade arquitetural. Em vez de pensar em Redshift mais uma camada externa, os times passam a raciocinar em torno de um engine mais integrado para analytics.
Essa mudança também conversa com workloads modernos. BI, ETL, analytics near real-time e agentes de IA têm padrões de consumo diferentes. Agentes de IA, especialmente, podem executar muito mais queries que usuários humanos, buscando contexto, validando hipóteses e cruzando informações.
Nesse cenário, um engine analítico mais integrado e eficiente se torna cada vez mais relevante.
Informações práticas: custo, performance e tipos de nós
Na prática, o Redshift RG chega com três mensagens bem objetivas: mais performance, menor custo por vCPU e uma nova forma de processar consultas em data lake. Segundo a AWS, as instâncias Amazon Redshift RG, baseadas em AWS Graviton, conseguem executar workloads de data warehouse até 2,2 vezes mais rápido do que as instâncias RA3 da geração anterior, com preço por vCPU 30% menor.
Para workloads de data lake, o RG permite executar analytics SQL entre o data warehouse e o data lake a partir de um único engine, com performance até 2,4 vezes superior ao RA3 para Apache Iceberg e até 1,5 vez superior ao RA3 para Apache Parquet.
A AWS posiciona essa combinação de velocidade, eficiência de custo e engine integrado de data lake como especialmente relevante para os workloads atuais de analytics e de agentic AI, em que o volume de queries e os requisitos de baixa latência são cada vez maiores.
No lançamento, os tipos suportados são rg.xlarge e rg.4xlarge, ambos disponíveis para clusters multi-node. O rg.xlarge possui 4 vCPUs, 32 GiB de memória, 2 slices por nó e limite de 32 TB de Redshift Managed Storage por nó. Já o rg.4xlarge possui 16 vCPUs, 128 GiB de memória, 8 slices por nó e limite de 128 TB de Redshift Managed Storage por nó. A documentação também indica que clusters rg.xlarge podem ser criados com até 16 nós e redimensionados elasticamente até 32 nós, enquanto clusters rg.4xlarge podem ser criados com até 32 nós e redimensionados elasticamente até 64 nós.
Em termos de equivalência, a AWS recomenda olhar para o rg.xlarge como o caminho natural para ambientes que hoje usam ra3.xlplus, especialmente clusters menores ou workloads departamentais. Já o rg.4xlarge aparece como a alternativa ao ra3.4xlarge, mas com uma diferença importante: enquanto o ra3.4xlarge possui 12 vCPUs e 96 GB de memória, o rg.4xlarge entrega 16 vCPUs e 128 GB de memória. Ou seja, há um aumento de aproximadamente 33% em CPU e memória por nó nessa comparação.
| Atual RA3 | Caminho RG recomendado | vCPU | Memória | Uso típico |
|---|---|---|---|---|
ra3.xlplus | rg.xlarge | 4 | 32 GiB | analytics departamental, clusters menores |
ra3.4xlarge | rg.4xlarge | 12 → 16 | 96 → 128 GiB | produção, workloads médios |
Do ponto de vista de performance, a AWS posiciona o RG como mais eficiente tanto para workloads tradicionais de data warehouse quanto para workloads de data lake. O ponto mais relevante é que, no RG, o engine integrado de data lake roda diretamente nos recursos computacionais do cluster, enquanto no RA3 as consultas em data lake usam Redshift Spectrum.
Na prática, isso muda a leitura de performance. Em RA3, parte relevante do processamento externo acontecia fora do cluster, na camada do Spectrum. Em RG, a performance das consultas sobre S3 passa a depender diretamente do tamanho e da capacidade do cluster. Isso significa que adicionar nós ou escolher um tipo de nó maior não impacta apenas queries internas do warehouse, mas também consultas em data lake.
O custo também muda bastante. Na página de preços, a AWS mostra um exemplo comparando quatro nós rg.4xlarge com quatro nós ra3.4xlarge em US East (N. Virginia), usando 40 TB de Redshift Managed Storage e 20 TB de dados escaneados no data lake durante o mês. No exemplo, o RG tem custo mensal de US$ 9.867,64, enquanto o RA3 fica em US$ 10.602,24. A diferença vem de dois pontos: o custo do compute RG no exemplo é menor e o custo de Spectrum no RG é US$ 0,00, enquanto no RA3 os 20 TB escaneados via Spectrum geram US$ 100,00 adicionais.
Essa comparação é importante porque mostra que a economia não vem apenas do preço do nó. Ela também vem da remoção da cobrança separada por TB escaneado no Spectrum para clusters RG. Em ambientes que consultam pouco o data lake, essa diferença pode ser pequena. Em ambientes que fazem muitos scans externos, especialmente sobre Iceberg ou Parquet no S3, o impacto pode ser bem mais relevante.
Mas isso não significa que o RG sempre será automaticamente mais barato. O custo passa a depender ainda mais do dimensionamento correto do cluster. Se antes uma parte do workload externo era absorvida pela infraestrutura do Spectrum, agora esse processamento entra na conta do próprio cluster. Se o ambiente tiver muitas queries pesadas no data lake, pode ser necessário aumentar o número de nós ou escolher uma configuração maior para manter a mesma experiência de performance.
Também existe um detalhe importante sobre migração e compatibilidade. A documentação de versões do Redshift indica suporte aos tipos rg.xlarge e rg.4xlarge em clusters multi-node e aponta uma versão mínima necessária para migrar para esses tipos, disponível na maintenance track CURRENT.
Na prática, antes de migrar, é necessário pelo menos cinco pontos: versão do cluster, região disponível, tipo de nó atual, volume de dados no Redshift Managed Storage e perfil real das queries externas. Se o cluster atual usa muito Spectrum, essa análise precisa ser ainda mais cuidadosa, porque o RG muda onde esse processamento acontece.
O principal trade-off
Aqui está o ponto operacional mais importante. Com RA3 e Spectrum, uma query ruim no S3 podia ser lenta, cara e ineficiente, mas boa parte do processamento externo era absorvida por uma camada separada. Com RG, queries em data lake rodam no compute do próprio cluster.
Isso significa que workloads externos passam a competir diretamente com workloads internos por CPU, memória, rede, cache, filas e concorrência.
Isso não é necessariamente ruim. É justamente o que permite maior integração, arquitetura mais simples e remoção da cobrança separada de scan. Mas muda o modelo operacional.
Antes, era comum pensar: “essa query é externa, então o Spectrum absorve parte da pancada”. Com RG, a pergunta passa a ser: “meu cluster está dimensionado para suportar queries internas, scans no lake, dashboards, ETLs e análises ad hoc ao mesmo tempo?”.
Esse ponto torna sizing, WLM, governança de queries e observabilidade ainda mais importantes. WLM, ou Workload Management, controla concorrência, filas, prioridades e comportamento dos workloads dentro do Redshift.
Em resumo: uma query ruim no data lake não é mais apenas um problema do Spectrum. É um problema do cluster. E, se é um problema do cluster, é um problema de confiabilidade, performance e custo.
O que não muda
External schemas continuam existindo. O Glue continua importante como catálogo. IAM Roles continuam necessárias para controle de acesso. O S3 continua sendo a camada de armazenamento do data lake. Conceitos de external tables continuam relevantes.
O RG muda a arquitetura de execução, mas não elimina a necessidade de boas práticas de engenharia de dados. Arquivos bem organizados, formatos adequados, bom particionamento, metadados consistentes e governança continuam sendo essenciais.
RA3 também não desaparece. Ele continua sendo uma geração madura e relevante, e o Spectrum continua existindo para clusters RA3.
Minha leitura como DBRE
Eu não olharia para o Redshift RG apenas como “RA3 mais barato e mais rápido”.
O ganho de performance e a redução de custo são importantes, mas a mudança arquitetural é o ponto principal. O Redshift está deixando de ser um data warehouse que acessa o data lake por uma camada externa e se aproximando de um engine unificado de analytics entre warehouse e lake.
Isso é uma grande evolução para ambientes bem modelados, com dados organizados, bons formatos, boas estratégias de particionamento, observabilidade e governança de queries.
Mas em ambientes desorganizados, com data lakes sem curadoria, muitos small files, ausência de filtros e análises exploratórias sem controle, essa mudança pode expor problemas que antes ficavam parcialmente diluídos na camada do Spectrum.
A pergunta não é apenas: “quanto posso economizar migrando?”, mas “meu ambiente está preparado para operar warehouse e lake no mesmo compute com previsibilidade, segurança e governança?”.
Conclusão
O Amazon Redshift RG representa uma das mudanças mais relevantes da história recente do Redshift.
Ele combina AWS Graviton, melhor custo-performance, ganhos de performance e um engine integrado de data lake que remove a dependência da fleet separada do Spectrum em clusters RG.
Para quem está começando, a mensagem é simples: Redshift é o data warehouse analítico da AWS; S3 é a base do data lake; Glue descreve os dados; Spectrum permitia ao RA3 consultar dados externos; e RG muda esse modelo ao trazer o processamento do data lake para dentro do próprio cluster.
Para quem já opera ambientes analíticos, a mensagem é mais profunda: troubleshooting, sizing, governança e WLM mudam. O data lake deixa de ser um workload parcialmente isolado e passa a compartilhar diretamente os recursos do cluster. Isso pode reduzir custo, simplificar arquitetura e melhorar performance. Mas também exige maturidade operacional.
O Redshift RG não é apenas uma nova família de instâncias. É um sinal claro de que o Redshift está entrando em uma nova fase: mais integrada, mais lakehouse, mais preparada para workloads orientados por IA e mais exigente para quem opera dados em escala.
Referências:
https://aws.amazon.com/pt/redshift/features/rg/?trk=d8ec3b19-0f37-4f8c-8c12-189f913e205c&sc_channel=el
Deixe um comentário