Otimizando Redshift na Prática: Um Estudo de Caso com DISTKEY e SORTKEY

Neste guia, vamos otimizar uma tabela no Amazon Redshift do zero. Analisaremos o padrão de consulta, usaremos a view svv_table_info para diagnosticar problemas e aplicaremos as DISTKEY e SORTKEY corretas para transformar a performance.

O Amazon Redshift é um data warehouse com arquitetura MPP (Massively Parallel Processing). Em resumo, dados e processamento são divididos entre múltiplos nós. Para extrair a performance máxima, precisamos instruir o Redshift sobre como distribuir (DISTKEY) e ordenar (SORTKEY) os dados de forma inteligente.

Embora o Redshift ofereça otimizações automáticas (AUTO), elas são um ponto de partida genérico. A otimização manual, baseada em padrões de consulta conhecidos, é o que realmente faz a diferença.

Parte 1: Conceitos Fundamentais

Antes de otimizar, precisamos dominar duas ferramentas.

A. Chaves de Distribuição (DISTKEY)

A DISTKEY define como as linhas de uma tabela são distribuídas entre os nós do cluster. O objetivo é minimizar a movimentação de dados pela rede (data shuffling) durante a execução de uma query.

• DISTSTYLE KEY(coluna): Linhas com o mesmo valor na coluna da DISTKEY são armazenadas no mesmo nó. Ideal para colunas com alta cardinalidade usadas em JOINs ou GROUP BY, pois a operação ocorre localmente em cada nó.
• DISTSTYLE ALL: Uma cópia completa da tabela é armazenada em cada nó. Use apenas para tabelas pequenas e de baixa frequência de atualização (ex: tabelas de dimensão < 3 milhões de linhas) que são frequentemente usadas em JOINs.
• DISTSTYLE EVEN: Os dados são distribuídos em round-robin. É o padrão, mas raramente a melhor escolha para tabelas grandes, pois não otimiza a co-localização de dados para JOINs.

B. Chaves de Ordenação (SORTKEY)

A SORTKEY define a ordem física em que as linhas são armazenadas nos blocos de 1MB em disco. O objetivo é minimizar a quantidade de dados lidos (I/O).

O Redshift mantém metadados (Zone Maps) que registram os valores mínimo e máximo de cada bloco. Se uma query filtra por uma coluna da SORTKEY (ex: WHERE data > '2025-10-01'), o Redshift usa os Zone Maps para ler apenas os blocos que podem conter esses dados, ignorando o resto.

• COMPOUND SORTKEY(col1, col2, ...): Ordena os dados estritamente na ordem das colunas listadas. É extremamente eficiente quando os filtros usam um prefixo da chave (principalmente a col1).
• INTERLEAVED SORTKEY(col1, col2, ...): Dá peso igual a todas as colunas na chave. É útil quando os filtros são imprevisíveis, mas tem um custo maior de VACUUM.

Parte 2: A Ferramenta de Diagnóstico: svv_table_info

Esta view do sistema é o painel de saúde de qualquer tabela. Para usá-la, rode:

SELECT "table", diststyle, skew_rows, sortkey1, unsorted, stats_off
FROM svv_table_info
WHERE "schema" = 'seu_schema' AND "table" = 'sua_tabela';

Abaixo, os campos essenciais e como interpretá-los:

Campo Relevante	O que é?	Como Interpretar e Agir?
diststyle	O estilo de distribuição atual.	Confirma se sua DISTKEY foi aplicada. Se for EVEN em uma tabela grande, é um forte candidato à otimização.
skew_rows	A distorção na distribuição. Razão entre o maior e o médio slice.	1.0 é perfeito. Valores altos (> 4.0) indicam "skew", onde um nó está sobrecarregado. A DISTKEY pode estar mal escolhida.
sortkey1	A primeira coluna da sua SORTKEY.	Essencial para garantir que a coluna mais filtrada em ranges (como datas) esteja aqui.
unsorted	O percentual de dados não ordenado.	O objetivo é 0.00. Um valor alto anula os benefícios da SORTKEY. Ação: VACUUM SORT sua_tabela;
stats_off	O percentual de "desatualização" das estatísticas.	O objetivo é 0.00. Um valor alto pode gerar planos de execução ineficientes. Ação: ANALYZE sua_tabela;

Parte 3: O Ciclo de Otimização - Estudo de Caso

Vamos aplicar os conceitos à tabela agg_cotacoes_produto_fornecedor_dia.

Etapa 1: Análise do Padrão de Consulta

• Problema: A tabela é a fonte de dashboards no Looker, e as consultas estão lentas.
• Padrão Identificado: Os filtros dos dashboards são quase sempre por id_fornecedor e por um range de data_cotacao.

Etapa 2: Diagnóstico da Tabela Original

Uma consulta na svv_table_info revelou:

• diststyle: AUTO(KEY(id_produto))
• sortkey1: AUTO(SORTKEY)

Conclusão do Diagnóstico: A otimização automática do Redshift escolheu id_produto, provavelmente para otimizar JOINs com uma tabela de produtos. No entanto, essa escolha não atende ao nosso padrão principal de filtro (id_fornecedor e data_cotacao).

Etapa 3: Definição da Estratégia de Otimização

Baseado no padrão de consulta, definimos a nova estratégia:

• DISTKEY(id_fornecedor): Como os filtros são por fornecedor, isso vai co-localizar os dados necessários em um mesmo nó, acelerando filtros e agregações.
• COMPOUND SORTKEY(data_cotacao, id_fornecedor): data_cotacao é a coluna mais filtrada em ranges, então deve vir primeiro na SORTKEY. Isso permitirá ao Redshift pular blocos de dados massivamente.

Etapa 4: Implementação (Processo "Deep Copy")

Para aplicar as mudanças em uma tabela populada, o processo mais seguro é criar uma nova tabela otimizada e depois trocá-las de lugar.

1. Criação (CTAS):

CREATE TABLE agg_cotacoes_produto_fornecedor_dia_novo 
DISTKEY(id_fornecedor) 
COMPOUND SORTKEY(data_cotacao, id_fornecedor) AS 
SELECT * FROM agg_cotacoes_produto_fornecedor_dia;

2. Manutenção Pós-Criação:
A svv_table_info da nova tabela mostrou unsorted e stats_off altos, o que é esperado após uma carga massiva.

VACUUM SORT ONLY agg_cotacoes_produto_fornecedor_dia_novo;
ANALYZE agg_cotacoes_produto_fornecedor_dia_novo;

3. Validação Final:
Verificamos a svv_table_info novamente. Agora, unsorted: 0.00 e stats_off: 0.00. A tabela está pronta.

4. A Troca Atômica:
Executamos a troca de nomes dentro de uma transação para garantir que a operação seja instantânea e segura, sem downtime para os usuários.

BEGIN;
ALTER TABLE agg_cotacoes_produto_fornecedor_dia RENAME TO agg_cotacoes_produto_fornecedor_dia_old;
ALTER TABLE agg_cotacoes_produto_fornecedor_dia_novo RENAME TO agg_cotacoes_produto_fornecedor_dia;
COMMIT;

Conclusão

O ciclo de otimização no Redshift é contínuo e baseado em dados:

1. Analisar Padrão de Query
2. Diagnosticar com svv_table_info
3. Definir Estratégia (DISTKEY, SORTKEY)
4. Implementar e Validar

Ao dominar esses conceitos, você sai do modo "automático" e passa a ter controle total sobre a performance do seu data warehouse, transformando tabelas lentas em fontes de dados eficientes para qualquer ferramenta de BI como o Looker.