Amazon Redshift: o Guia Avançado de Data Warehouse na Nuvem

Uma consulta que levaria minutos varrendo um banco transacional roda em segundos num data warehouse bem projetado — e é exatamente essa diferença de arquitetura, não de "banco mais rápido", que explica por que empresas com volume analítico crescente migram do PostgreSQL ou MySQL gerenciado para o Amazon Redshift. O Redshift não é um RDS mais robusto: é um motor de processamento massivamente paralelo (MPP), construído desde a base para varrer bilhões de linhas em consultas de BI, e isso muda decisões de modelagem, de custo e de quando ele é a ferramenta certa — ou um exagero. Este guia cobre a arquitetura MPP, a escolha entre nós RA3 e Redshift Serverless, o modelo de distribution e sort keys, quando o Redshift vence o Athena ou um data lake puro, e quanto custa de verdade rodar cada modelo.

O Que É o Amazon Redshift e Por Que Ele Não É "Só Outro Banco de Dados"

O Amazon Redshift é o serviço de data warehouse gerenciado da AWS, otimizado para consultas analíticas complexas sobre grandes volumes de dados — o padrão de uso de BI, relatórios executivos e análise histórica, não o de transações unitárias de um sistema operacional. A diferença técnica central está no motor: enquanto um banco transacional como o RDS PostgreSQL é orientado a linha (row-oriented) e otimizado para ler ou escrever um registro por vez, o Redshift é orientado a coluna (columnar) e distribui o processamento entre múltiplos nós que trabalham em paralelo sobre fatias do mesmo conjunto de dados.

Essa arquitetura columnar importa na prática porque uma consulta analítica típica ("some a receita por região no último trimestre") só precisa ler duas ou três colunas de uma tabela com quarenta. Num banco orientado a linha, o motor ainda varre o registro inteiro; num banco columnar, ele lê só as colunas relevantes, comprimidas de forma muito mais eficiente porque valores do mesmo tipo ficam fisicamente próximos no disco. É por isso que um Redshift bem modelado varre terabytes em segundos, algo impraticável na mesma escala com um motor transacional.

Vale a separação de propósito desde já: o Redshift é para dados estruturados e semiestruturados já modelados para consulta — schemas definidos, tabelas de fato e dimensão, granularidade pensada para BI. Um data lake, por outro lado, guarda dado bruto em qualquer formato, sem exigir modelagem prévia, e serve melhor a ciência de dados exploratória e machine learning. Os dois não competem — na prática, a arquitetura mais comum combina os dois, com o Redshift consultando o data lake via Spectrum quando precisa, como este guia detalha mais adiante. Para quem ainda está montando a stack de dados na AWS antes de chegar à camada de analytics, vale revisar primeiro o guia de serviços AWS mais usados por empresas, que mapeia onde o Redshift se encaixa ao lado de EC2, S3 e RDS.

A Arquitetura MPP: Como o Redshift Processa Consultas em Paralelo

Um cluster Redshift provisionado é formado por um nó líder e um ou mais nós de computação. O nó líder recebe a consulta SQL do cliente, faz o parsing, monta o plano de execução e distribui esse plano entre os nós de computação — que executam a parte pesada do trabalho e trocam dados intermediários entre si conforme necessário. O nó líder então agrega os resultados parciais e devolve a resposta final à aplicação. Cada nó de computação, por sua vez, é dividido internamente em slices — partições de CPU, memória e disco que processam sua fatia dos dados de forma independente e simultânea.

Essa é a essência do processamento massivamente paralelo (MPP): a mesma consulta é fatiada e executada ao mesmo tempo em dezenas ou centenas de slices, e o tempo de resposta cai proporcionalmente ao paralelismo disponível — até o ponto em que a rede entre os nós, não a CPU, vira o gargalo. É exatamente aí que entra a decisão mais importante de modelagem de dados no Redshift: como distribuir as linhas entre os nós para minimizar o tráfego de rede durante os joins, tema da próxima seção.

RA3, Redshift Serverless e o Modelo de Distribution/Sort Keys

Nós RA3: computação e armazenamento desacoplados

Nos clusters provisionados, a AWS recomenda os nós com armazenamento gerenciável (managed storage), hoje representados pela família RA3 — ra3.large, ra3.xlplus, ra3.4xlarge e ra3.16xlarge — e, mais recentemente, também pela família RG, baseada em processadores Graviton, que a AWS passou a recomendar lado a lado com o RA3 para cargas que se beneficiam de melhor custo-benefício de CPU e de um motor de consulta a data lake integrado ao próprio cluster. A característica que definiu o RA3 desde o lançamento continua sendo a mais relevante: computação e armazenamento são desacoplados. Cada nó usa SSDs locais de alta performance como cache e descarrega automaticamente para o Amazon S3 os dados que excedem esse cache — e você paga a mesma taxa de armazenamento gerenciado independentemente de o dado estar no SSD local ou no S3.

Na prática, isso resolve o problema clássico dos nós antigos de armazenamento local (DC2): antes, para crescer o armazenamento você era obrigado a adicionar mais nós de computação, mesmo que não precisasse de mais CPU. Com RA3 ou RG, você dimensiona o número de nós pela necessidade de performance de consulta, e o armazenamento escala sozinho — a AWS ainda recomenda DC2 apenas para bancos comprimidos abaixo de 1 TB, onde o custo do armazenamento local embutido compensa.

Redshift Serverless: a unidade é o RPU

O Amazon Redshift Serverless elimina o gerenciamento de cluster: você não escolhe tipo nem número de nós, define uma capacidade base em RPUs (Redshift Processing Units) e o serviço escala automaticamente conforme a carga. Cada RPU equivale a 16 GB de memória disponível para processar consultas. A capacidade base pode ser configurada de 4 a 512 RPUs na maioria das regiões (até 1.024 RPUs em regiões selecionadas, como Norte da Virgínia e Ohio), com incrementos de 4 em 4 até 8 RPUs e de 8 em 8 a partir daí — o padrão da AWS ao criar um novo workgroup é 128 RPUs. A cobrança é por segundo, com mínimo de 60 segundos de uso a cada ativação, e o armazenamento é faturado separadamente, por GB/mês, do mesmo jeito que no modelo provisionado.

A configuração de 4 RPUs é a entrada mais barata, indicada para bases de até 32 TB de armazenamento gerenciado e tabelas com até 100 colunas — abaixo disso, o Redshift recomenda subir para 8 RPUs ou mais. É a opção certa para cargas intermitentes, ambientes de desenvolvimento/teste ou empresas que ainda não sabem seu padrão real de consumo; o modelo provisionado com reserva de capacidade compensa quando a carga é estável e previsível o ano inteiro.

Distribution keys e sort keys: a decisão que define a performance

A forma como as linhas de uma tabela são distribuídas entre os nós determina quanto dado precisa trafegar pela rede durante um join — e é aí que a maioria dos problemas de performance no Redshift realmente mora. A documentação da AWS descreve quatro estilos de distribuição:

• KEY — as linhas são distribuídas conforme os valores de uma coluna específica, geralmente a chave usada nos joins. Quando duas tabelas grandes são distribuídas pela mesma chave de junção, as linhas que precisam ser combinadas já estão fisicamente no mesmo nó, e o Redshift não precisa mover dado pela rede para fazer o join.
• ALL — uma cópia completa da tabela é replicada em todos os nós. Ideal para tabelas de dimensão pequenas e que mudam pouco (categorias de produto, por exemplo), porque elimina qualquer redistribuição durante o join — mas multiplica o custo de armazenamento pelo número de nós, e encarece cargas de escrita.
• EVEN — as linhas são distribuídas em round-robin, sem considerar valores de coluna. Serve para tabelas que não participam de joins relevantes, ou quando não há uma chave clara entre KEY e ALL.
• AUTO — o padrão quando nenhum estilo é definido explicitamente. O Redshift começa com ALL para tabelas pequenas e migra automaticamente para KEY ou EVEN conforme a tabela cresce, ajustando em segundo plano com impacto mínimo nas consultas em andamento.

Complementar à distribuição está a sort key, que define a ordem física de gravação dos dados no disco — permitindo que o otimizador pule blocos inteiros que não atendem ao filtro de uma consulta (block pruning), especialmente eficaz em colunas de data usadas em filtros de intervalo. Na dúvida, começar com AUTO em ambos os casos e revisar depois com base no padrão real de consultas costuma ser mais produtivo do que tentar acertar a modelagem ideal antes de ter dado de uso real.

Redshift Spectrum: Consultando o Data Lake sem Mover Dado

O Amazon Redshift Spectrum permite consultar dados estruturados e semiestruturados direto de arquivos no Amazon S3, usando SQL padrão do Redshift, sem carregar esse dado para dentro do cluster. A consulta é distribuída entre uma camada de processamento própria do Spectrum, separada da capacidade do cluster, o que permite que múltiplos clusters consultem o mesmo conjunto de dados no S3 simultaneamente sem duplicar nada.

Isso muda a arquitetura de decisão: em vez de escolher entre "tudo no Redshift" ou "tudo no data lake", a prática comum é manter no cluster apenas os dados mais consultados e recentes — o "quente" — e deixar o histórico mais antigo, consultado com menos frequência, apenas no S3, acessível via Spectrum quando alguém realmente precisar dele. A cobrança do Spectrum é por volume de dado escaneado (na região de referência da AWS, US East N. Virginia, US$ 5 por terabyte, com mínimo de 10 MB por consulta) — o que cria um incentivo direto para particionar e comprimir bem os arquivos no S3, já que uma consulta malparticionada pode escanear ordens de grandeza mais dado do que precisa.

Redshift vs. Athena, Data Lake Puro e Outros Data Warehouses

A pergunta que decide a arquitetura não é "qual ferramenta é melhor", é "qual o padrão de consulta". O Amazon Athena, por exemplo, também consulta dados no S3 com SQL, mas sem cluster nenhum por trás: é 100% serverless, cobrado só pelo volume escaneado, e ideal para consultas esporádicas ou exploratórias. O Redshift, com capacidade reservada (provisionada ou Serverless) sempre ativa, ganha nítida vantagem quando o volume de consultas concorrentes é alto e constante — dashboards de BI acessados o dia inteiro por dezenas de usuários, por exemplo — porque o custo por consulta cai à medida que a capacidade já paga é reutilizada, o que não acontece num modelo cobrado por escaneamento a cada execução.

Frente a outros data warehouses na nuvem, o diferencial do Redshift para quem já está na AWS é a integração nativa: IAM, VPC, CloudWatch, Lake Formation e o restante do ecossistema funcionam sem camada extra de configuração. Isso não torna o Redshift universalmente superior a alternativas como BigQuery ou Snowflake — mas para uma empresa que já opera a maior parte da infraestrutura na AWS, o custo de integração de um data warehouse fora do ecossistema raramente compensa o ganho técnico marginal.

Modelos de Implementação: Provisioned, Serverless e Híbrido

Não existe resposta única entre cluster provisionado e Serverless — depende do quanto a carga de trabalho é previsível. Três padrões cobrem a maioria dos casos:

Provisionado com nós reservados faz sentido para cargas de produção estáveis, com volume de consulta relativamente constante ao longo do dia e do mês — o desconto de nós reservados (comprados com um a três anos de compromisso) reduz significativamente o custo por hora frente ao modelo sob demanda, mas exige acertar o dimensionamento com antecedência.

Serverless puro é a escolha natural para cargas intermitentes, times pequenos sem capacidade de operar ajuste fino de cluster, ou qualquer cenário em que o padrão de uso ainda não é bem conhecido — o primeiro semestre de operação, tipicamente. A ausência de gestão de nó também reduz a carga operacional sobre o time de dados, que passa a lidar apenas com modelagem e SQL.

Híbrido com Spectrum — cluster (provisionado ou Serverless) para o dado quente e frequentemente consultado, Spectrum para consultar o histórico direto do S3 — é o padrão que mais aparece em empresas de porte médio para cima, porque equilibra custo de armazenamento (S3 é ordens de grandeza mais barato que managed storage do cluster para dado raramente acessado) com performance de consulta no que realmente importa no dia a dia.

Uma ferramenta que amplia qualquer um desses modelos sem custo adicional de escaneamento é o Concurrency Scaling, disponível para clusters provisionados em nós RA3, RG ou DC2 com quatro nós ou mais: quando o número de consultas concorrentes excede a capacidade da fila configurada, o Redshift acrescenta clusters temporários de forma transparente para a aplicação. Cada cluster acumula uma hora de crédito gratuito por dia — até um teto de 30 horas acumuladas — e, além disso, é cobrado por segundo, com mínimo de um minuto por ativação, sem custo pelo tempo de subida ou desligamento do cluster temporário.

Quanto Custa Rodar o Redshift na Prática

O erro mais comum ao estimar custo de Redshift é olhar só a tarifa de computação e esquecer o armazenamento gerenciado, que é cobrado separadamente e cresce com o volume de dado retido — inclusive dado "frio" que ninguém consulta há meses, mas que continua ocupando managed storage se não for movido para o S3 via Spectrum. A conta real soma pelo menos três componentes: computação (nó-hora reservado/sob demanda, ou RPU-hora no Serverless), armazenamento gerenciado (GB/mês) e, quando aplicável, Concurrency Scaling e Spectrum.

Um exercício prático de FinOps aplicado ao Redshift segue o mesmo raciocínio que já vale para qualquer serviço da AWS: revisar se o dimensionamento de nós ou a capacidade base em RPUs reflete o uso real, não o pico ocasional; mover dado raramente consultado para o S3 via Spectrum em vez de mantê-lo no cluster; e considerar nós reservados só depois de validar o padrão de uso com um cluster sob demanda por alguns meses. É exatamente o tipo de análise que a prática de FinOps na AWS foi desenhada para capturar — desperdício por inércia de dimensionamento custa tão caro num data warehouse quanto em qualquer outro serviço, só que a fatura de analytics costuma ser vista com menos frequência que a de computação.

Vale reforçar: os valores citados neste guia (como o preço de Spectrum por terabyte escaneado) são a referência publicada pela AWS para a região Norte da Virgínia — a região de São Paulo tem tabela própria, e o número correto para orçamento deve sempre vir da página oficial de preços do Redshift. Quando o objetivo é ir além do dimensionamento do próprio Redshift e revisar a fatura AWS como um todo, a análise de custos AWS da DOMINIT parte exatamente desse tipo de levantamento linha a linha.

Casos de Uso por Porte de Empresa

Para empresas na faixa de 30 a 100 funcionários com volume analítico ainda modesto, o caminho mais barato costuma ser Redshift Serverless com capacidade base mínima (4 ou 8 RPUs), alimentando dashboards de BI que hoje talvez ainda rodem sobre planilhas ou sobre o próprio banco transacional — uma prática que degrada a performance do sistema operacional à medida que o volume de dado cresce, tema já coberto no guia de EC2, S3 e RDS para PMEs.

Empresas de 100 a 300 funcionários com múltiplas fontes de dado (ERP, CRM, e-commerce, planilhas de área) tendem a se beneficiar do modelo híbrido: cluster para o dado consolidado e modelado, Spectrum para consultas ocasionais sobre histórico bruto no S3, e um processo de ETL/ELT recorrente alimentando o data warehouse — natural ponto de entrada para conversas sobre administração de banco de dados terceirizada, já que manter a modelagem e o desempenho de um data warehouse em dia exige disciplina contínua, não só a configuração inicial.

Empresas acima de 300 funcionários, com múltiplas equipes analíticas concorrendo pelo mesmo cluster, normalmente já justificam capacidade reservada ou base RPU maior, Concurrency Scaling ativo e uma governança clara de distribution/sort keys revisada periodicamente — o ponto em que erros de modelagem custam mais caro em performance e em fatura, e onde vale a pena estruturar o ambiente dentro de uma revisão de arquitetura mais ampla, como a proposta pelo AWS Well-Architected Framework.

Tendências: IA, Zero-ETL e Consulta Direta ao Data Lake

A linha entre data warehouse e data lake continua se apagando. O Redshift já suporta zero-ETL entre bases operacionais (como Aurora e RDS) e o próprio data warehouse, eliminando pipelines de extração manuais para cargas de replicação contínua, e os novos nós RG trazem um motor de consulta a data lake integrado ao próprio cluster, reduzindo a dependência do Spectrum como camada separada para certos padrões de consulta. Do lado de IA, a capacidade de rodar inferência de machine learning direto em SQL dentro do cluster (Redshift ML) e o AI-driven scaling do Serverless — que ajusta a capacidade automaticamente para equilibrar custo e performance conforme o histórico de uso — apontam para um modelo em que cada vez menos decisão de dimensionamento fica manual, e cada vez mais a conversa se desloca para modelagem de dado e governança de acesso.

Perguntas Frequentes sobre Amazon Redshift

Qual é a diferença entre Amazon Redshift e Amazon RDS?

O RDS é um banco de dados relacional transacional (row-oriented), otimizado para ler e escrever registros individuais rapidamente — o motor por trás de um sistema operacional, um ERP ou uma aplicação web. O Redshift é um data warehouse columnar e massivamente paralelo, otimizado para varrer grandes volumes de dado em consultas analíticas complexas. Não são substitutos um do outro: a arquitetura típica usa RDS para a operação do dia a dia e Redshift para consolidar e analisar esse dado depois.

Preciso de Redshift se já uso Athena para consultar meu data lake?

Depende do padrão de consulta. Athena é serverless e cobra por dado escaneado, o que é econômico para consultas esporádicas ou exploratórias. Se o volume de consultas concorrentes crescer — muitos usuários batendo no mesmo dashboard o dia inteiro, por exemplo — a capacidade reservada do Redshift (provisionada ou Serverless) tende a sair mais barata e mais rápida, porque o custo já foi pago uma vez e é reutilizado em cada consulta, em vez de recalculado a cada execução.

O que são distribution key e sort key, em termos simples?

A distribution key decide em qual nó cada linha de uma tabela fica armazenada — o objetivo é colocar linhas que serão combinadas em joins no mesmo nó, evitando tráfego de rede durante a consulta. A sort key decide a ordem física dos dados dentro de cada nó, permitindo que o Redshift pule blocos inteiros que não atendem a um filtro. As duas juntas são o principal alavancador de performance numa tabela grande.

Vale a pena migrar do RA3 provisionado para o Redshift Serverless?

Vale considerar quando a carga é intermitente ou imprevisível, ou quando o time não quer dedicar esforço a dimensionar e ajustar cluster. Para cargas estáveis e constantes ao longo do mês, um cluster provisionado com nós reservados costuma custar menos por unidade de capacidade do que RPUs sob demanda equivalentes — a decisão correta exige medir o padrão real de uso antes de escolher, não assumir por padrão.

O Redshift Spectrum substitui um data lake completo?

Não. O Spectrum é a camada de consulta que permite ao Redshift ler dados direto do S3, mas ele não organiza, cataloga ou governa esse dado — isso continua sendo função de um data lake bem estruturado (S3 particionado, Glue Data Catalog, políticas de acesso via Lake Formation). O Spectrum funciona melhor como extensão de um data lake já existente, não como substituto dele.

Quanto custa, na prática, começar com Redshift?

O ponto de entrada mais barato é Redshift Serverless com capacidade base de 4 RPUs, cobrado por segundo com mínimo de 60 segundos de uso — ideal para validar o caso de uso antes de comprometer capacidade reservada. A partir daí, o custo real depende do volume de dado armazenado (managed storage, cobrado por GB/mês) e do padrão de consulta, e os valores exatos para orçamento devem sempre vir da página oficial de preços da AWS para a região de destino, já que São Paulo tem tabela própria.

O Redshift funciona bem para uma empresa pequena, ou é ferramenta só para grande corporação?

Funciona, principalmente na configuração Serverless de entrada, mas a pergunta certa não é o tamanho da empresa e sim o volume e a complexidade das consultas analíticas. Uma empresa de 30 funcionários com volume de dado relativamente baixo pode não precisar de Redshift — um banco relacional bem indexado ou uma ferramenta de BI direto sobre o data lake pode bastar. O Redshift compensa quando o padrão de consulta analítica já é grande, concorrente ou complexo o suficiente para justificar capacidade dedicada.

O Amazon Redshift Compensa Quando o Padrão de Consulta, Não o Volume de Dado, Exige um Motor Paralelo

A decisão de adotar Redshift não deveria ser guiada por quantos terabytes uma empresa acumulou, e sim por como esse dado é consultado: com que frequência, por quantos usuários simultâneos, e com que complexidade de agregação. É essa combinação — não o tamanho do banco — que separa um caso onde um data lake com Athena resolve bem de um caso onde a capacidade dedicada e paralela do Redshift paga o próprio custo em tempo de resposta e produtividade analítica.

Empresas que tratam a escolha entre RA3, Serverless, Spectrum e alternativas como decisão de arquitetura — revisitada conforme o padrão de uso muda, não fixada para sempre na configuração inicial — extraem o máximo de cada real investido em data warehouse. As que decidem uma vez e nunca revisam tendem a pagar por capacidade que não usam, ou a sofrer performance que não têm mais razão para aceitar.

Artigos Relacionados

• FinOps AWS: o Guia Completo para Reduzir Custos na Nuvem — o mesmo raciocínio de dimensionamento por uso real, aplicado à computação e ao armazenamento do Redshift, é um dos alvos clássicos de revisão de FinOps.
• AWS Well-Architected Framework: o Guia Avançado — o pilar de otimização de custos e o de excelência operacional são onde a governança de distribution keys e dimensionamento de cluster deveria aparecer na revisão de arquitetura.
• Administração de Banco de Dados Terceirizada: o Guia Definitivo — manter um data warehouse performático exige a mesma disciplina contínua de tuning e monitoramento que qualquer banco de produção.
• Serviços AWS Mais Usados por Empresas: Guia Completo — para quem ainda está decidindo por onde começar a stack de dados na AWS, este guia mapeia os serviços mais adotados antes de chegar à camada de analytics.