Uma consulta que junta a tabela de fato de transações com a de clientes ficou lenta depois que o volume cresceu. Como você investiga e o que provavelmente encontra?

Eu começo olhando o plano de execução para ver se há redistribuição de dados entre os nós, porque em arquitetura massivamente paralela é isso que costuma dominar o tempo. Se as duas tabelas estão distribuídas por chaves diferentes, cada junção obriga o cluster a mandar linhas de um nó para outro pela rede, e o tempo cresce com o volume, exatamente como descrito. A correção é distribuir as duas pela coluna da junção, no caso o identificador do cliente, de forma que as linhas correspondentes já nasçam no mesmo nó. Se a tabela de clientes for pequena, uma alternativa melhor é distribuição ALL, replicando ela em todos os nós, o que elimina o tráfego sem custo relevante de espaço. Em paralelo eu olho a chave de ordenação da tabela de fato: se a consulta filtra por data e a tabela não está ordenada por data, estamos varrendo blocos que poderiam ser descartados. O que eu não faço de primeira é aumentar o cluster, porque isso mascara o problema e multiplica a conta todo mês.

O time quer manter cinco anos de histórico disponível para consulta, mas o custo do cluster está alto. Que arquitetura você propõe?

Eu separaria o dado quente do frio. Os últimos meses, que são consultados todo dia e sustentam os painéis, ficam em tabelas internas do cluster, modeladas com distribuição e ordenação pensadas para as consultas que existem. O histórico mais antigo vai para o S3 em Parquet, particionado por data, e continua consultável por Spectrum a partir do mesmo cluster, inclusive em junção com as tabelas internas. Assim eu paro de pagar armazenamento de warehouse por dado que quase ninguém lê, e o analista não perde o acesso: a consulta é a mesma, muda só onde o dado mora. O trade-off que eu declaro é desempenho: consulta em Spectrum é mais lenta e cobrada por dado lido, então particionamento e formato colunar deixam de ser detalhe e viram requisito. Também combinaria uma regra de ciclo de vida para o histórico bem antigo migrar para uma classe de armazenamento mais fria, já que a consulta dele é rara e tolera espera.

AWS · tema 19 de 40

Redshift e a camada de consumo analítico

35 min · 2 vídeos · 12 cards · 1 drill

Por que cai

Na sabatina de Analytics, a pergunta não é o que é Redshift: é por que a sua consulta demora e o que você faria. Chave de distribuição errada é a resposta certa na maioria das vezes, e quem não sabe explicar embaralhamento entre nós não consegue defender nenhuma escolha de modelagem.

Pré-teste · 1 de 2

responda antes de ver

Uma junção entre uma tabela de fato grande e outra tabela grande ficou muito lenta no Redshift. Qual é a primeira hipótese a investigar?

Quanta certeza você tem?

Vídeo · português · 5 min

Cinco minutos de panorama por quem trabalha com a ferramenta. Assista para fixar o vocabulário (nós, colunar, Spectrum) antes de entrar nas decisões de modelagem deste tema.

Em uma frase

O Redshift é colunar e paralelo: o que decide o desempenho não é índice, é onde cada linha mora (distribuição), em que ordem (ordenação) e quanto dado a consulta precisa ler.

Por que colunar muda a conversa

Num banco por linha, ler um registro é ler tudo dele junto — ótimo para cadastro. Num banco colunar, cada coluna é guardada separada: uma consulta que soma valor por mês lê duas colunas de milhões de linhas, e não as linhas inteiras. Some a isso que valores parecidos ficam vizinhos e comprimem muito melhor, e você tem a razão de relatórios voarem e cadastros sofrerem.

É por isso que a otimização muda de vocabulário: índice por linha perde sentido, e entram distribuição e ordenação.

As duas decisões que decidem o tempo

Estilo de distribuição	O que faz	Quando usar
KEY	Linhas com o mesmo valor da chave vão para o mesmo nó	Tabelas grandes que se juntam sempre pela mesma coluna
ALL	A tabela inteira é replicada em todos os nós	Dimensão pequena e estável que entra em quase toda consulta
EVEN	Espalha por rodízio, sem critério	Tabela que não participa de junção relevante
AUTO	O serviço escolhe e ajusta com o tempo	Padrão razoável quando o padrão de consulta ainda não é claro

chave de distribuição— Coluna que decide em qual nó cada linha fica. Quando duas tabelas grandes se juntam pela mesma coluna e estão distribuídas por ela, a junção acontece dentro de cada nó, sem tráfego de rede. chave de ordenação— Coluna pela qual os blocos ficam ordenados. O cluster guarda o mínimo e o máximo de cada bloco e descarta blocos inteiros que não atendem ao filtro.

Spectrum: o warehouse lendo o lake

Redshift Spectrum— Consulta arquivos no S3 direto do cluster, sem carregá-los, cobrando por dado lido. Permite juntar tabela interna com histórico externo na mesma consulta.

O desenho que a sabatina espera: quente dentro, frio fora. Meses recentes em tabelas internas, modeladas para as consultas que existem; histórico em Parquet particionado no S3, consultável por Spectrum. Você para de pagar armazenamento de warehouse por dado que ninguém lê, sem tirar o acesso de ninguém.

O trade-off precisa ser dito: consulta externa é mais lenta e cobra por dado lido, então formato colunar e particionamento deixam de ser detalhe e viram requisito.

A camada que o negócio vê

QuickSight— Ferramenta de BI da AWS. Conecta a Redshift, Athena, S3 e bancos, e tem o SPICE, um motor em memória que guarda uma cópia do conjunto para o painel responder sem consultar a origem a cada clique.

O SPICE resolve o painel lento e cria uma pergunta que o engenheiro de analytics precisa saber responder: de que momento é esse número? Ele é do último refresh, não de agora. É a mesma conversa de Source of Record e Source of Truth, aplicada à ferramenta.

Como responder isso em voz alta

Para qualquer pergunta de lentidão: plano de execução primeiro, para ver se há redistribuição; chaves de distribuição alinhadas com a junção; chave de ordenação cobrindo o filtro; e só então capacidade. Para custo: separar quente de frio, com Spectrum sobre Parquet particionado. Quem começa por "aumento o cluster" está oferecendo a solução mais cara antes de entender o problema.

Se quiser outro ângulo1 vídeo

Um minuto, direto nos estilos de distribuição, que é a decisão que mais afeta desempenho. Curto de propósito: é uma revisão, não uma aula.

Como cai na sabatina

“Uma consulta que junta fato e dimensão ficou lenta depois que a tabela cresceu. O que você investiga?”

Erros comuns

Tratar o Redshift como um banco relacional maior. Ele é colunar e massivamente paralelo: a otimização que importa é distribuição e ordenação entre nós, não índice por linha.
Deixar a distribuição no padrão para tabelas grandes que se juntam. Chaves mal escolhidas fazem o dado atravessar a rede entre nós a cada junção, e é isso que aparece como lentidão.
Usar distribuição ALL numa tabela grande. Replicar em todos os nós só compensa para dimensão pequena e estável; numa tabela grande, multiplica armazenamento e o custo de carga.
Achar que Spectrum substitui a carga. Ele lê direto do S3, o que é ótimo para dado frio ou eventual; consulta frequente e sensível a desempenho continua melhor dentro do cluster.
Esquecer a chave de ordenação. Sem ela, filtros por data varrem blocos que poderiam ser descartados; é o ganho mais barato numa tabela de fato.
Modelar no Redshift como se fosse OLTP, normalizando tudo. Junção demais em colunar custa caro; a modelagem dimensional existe por isso.

Flashcards

Card 1 de 12

0 certos · 0 a rever

Drill

Qual decisão resolve?

Para cada sintoma, diga a decisão de modelagem ou de arquitetura esperada.

1.Junção entre duas tabelas grandes redistribui dados entre nós toda vez.
2.Consulta filtra sempre pelos últimos 30 dias e ainda assim varre a tabela toda.
3.Uma tabela de 500 linhas de categorias entra em quase toda consulta.
4.Cinco anos de histórico em Parquet no S3, consultados uma vez por trimestre.
5.O painel da diretoria fica lento porque cada filtro dispara consulta no warehouse.

Quiz · 1 de 2

Qual afirmação sobre armazenamento colunar é mais defensável numa sabatina?

Explique para um gerente

Explique em um minuto por que guardar os dados por coluna, e não por linha, deixa um relatório mais rápido e um cadastro mais lento.

Se travar numa palavra técnica, é sinal de que ainda não entendeu essa parte.

Prefiro falar em voz alta

00:00

Toque para gravar, ou responda em voz alta sem gravar

Perguntas de sabatina deste tema2

· Uma consulta que junta a tabela de fato de transações com a de clientes ficou lenta depois que o volume cresceu. Como você investiga e o que provavelmente encontra?
· O time quer manter cinco anos de histórico disponível para consulta, mas o custo do cluster está alto. Que arquitetura você propõe?

Responder no simulado

Para ir além4 artigos