top of page

Coffee and Tips Newsletter

Assine nossa newsletter para receber tutoriais Tech, reviews de dispositivos e notícias do mundo Tech no seu email

Nos vemos em breve!

Foto do escritorJP

Não quebre mais seus Dashboards: Entendendo DistKey e SortKey na prática

Entendendo DistKey e SortKey na prática

Primeiro, Sobre o AWS Redshift


O Redshift é um serviço de data warehouse em nuvem altamente escalável, oferecido pela AWS. Permite que as empresas analisem grandes volumes de dados rapidamente, utilizando SQL padrão e ferramentas de BI. A arquitetura do Redshift é otimizada para análise de dados em grande escala, aproveitando as vantagens da paralelização e armazenamento colunar. Recomendo a leitura onde falo dos detalhes da arquitetura e como funciona seus componentes, basta acessar o post Entendendo o AWS Redshift e seus componentes .


Porquê usar DistKey e SortKey?


Entendendo DistKey e SortKey na prática pode trazer diversos benefícios, como o principal deles, melhorar o desempenho das consultas. DistKey otimiza joins e agregações distribuindo dados de forma eficiente entre os nós, enquanto SortKey acelera consultas que filtram e ordenam dados, permitindo que o Redshift leia apenas os blocos de dados necessários. Ambos ajudam a tornar as consultas mais rápidas e o uso de recursos mais eficiente.


DistKey e seu funcionamento


DistKey (ou Distribution Key) é a estratégia de distribuição de dados entre os nós de um cluster Redshift. Quando você define uma coluna como DistKey, os registros que compartilham o mesmo valor nessa coluna são armazenados no mesmo nó, o que pode reduzir a movimentação de dados entre nós durante as consultas.


Overview do uso de DistKey
Overview do uso de DistKey

Uma das várias vantagens é a Redução da movimentação de dados entre nós, aumentando a performance das consultas e melhor utilização da capacidade de processamento distribuído do Redshift.


Atenção para a cardinalidade


Escolher uma coluna com baixa cardinalidade (poucos valores distintos) como DistKey pode resultar em uma distribuição desigual dos dados, criando "nós quentes" (nós com sobrecarga de dados) e degradando a performance.


O que é a tal cardinalidade?


A cardinalidade de uma coluna em uma tabela refere-se ao número de valores distintos que ela contém. Uma coluna com alta cardinalidade possui muitos valores distintos, o que geralmente a torna uma boa candidata para ser definida como DistKey no Amazon Redshift. Isso ocorre porque uma coluna com alta cardinalidade tende a distribuir os dados de forma mais equilibrada entre os nós do cluster, evitando o problema de nós com sobrecarga de dados.


Por mais que a ideia de DistKey é distribuir melhor os valores distintos entre os nós mantendo um balanço, devemos nos atentar que quanto mais estes dados movimentem entre os nós, menos desempenho teremos nas execuções de Queries complexas. Por isso é de grande importância definir uma boa estratégia na escolha da coluna para ser uma DistKey.


Benefícios de se usar DistKey


Para deixar mais claro, veja alguns dos benefícios na escolha de uma boa estratégia:


Redução da Movimentação de Dados Entre Nós


Quando os dados que compartilham a mesma DistKey estão no mesmo nó, as operações de join e agregações que utilizam essa chave podem ser realizadas localmente dentro de um único nó. Isso reduz significativamente a necessidade de movimentação de dados entre os nós, o que é um dos principais fatores que afetam a performance das consultas em sistemas distribuídos.


Melhor Performance em Joins e Consultas Filtradas


Se as consultas frequentemente realizam joins entre tabelas que compartilham a mesma DistKey, manter esses dados no mesmo nó pode melhorar drasticamente a performance. O tempo de resposta das consultas será mais rápido porque as operações não precisarão de redistribuição ou broadcast de dados entre os nós.


Suponha que você tenha duas tabelas grandes em seu cluster Redshift:


  • Tabela A (transações): Contém bilhões de registros de transações de clientes.


  • Tabela B (clientes): Armazena informações sobre os clientes.


Ambas as tabelas têm a coluna cliente_id. Se você frequentemente faz consultas que juntam essas duas tabelas para obter detalhes das transações por cliente, definir cliente_id como DistKey em ambas as tabelas garante que os registros relacionados ao mesmo cliente estejam armazenados no mesmo nó.


SELECT A.transacao_id, A.valor, B.nome_cliente
FROM transacoes A
JOIN clientes B
ON A.cliente_id = B.cliente_id
WHERE B.estado = 'CA';

Ao manter os dados de cliente_id no mesmo nó, os joins podem ser realizados localmente, sem necessidade de redistribuir dados entre diferentes nós do cluster. Isso reduz drasticamente o tempo de resposta da consulta.

Distkey and Nodes
Representação de transações onde os dados dos clientes e transações estão no mesmo nó

Sem DistKey, o Redshift precisaria redistribuir os dados de ambas as tabelas entre os nós para executar o join, aumentando o tempo de execução. Com DistKey em cliente_id, os dados já estão localizados no mesmo nó, permitindo uma execução muito mais rápida.



Eficiência de Armazenamento e Processamento


A execução local de operações em um único nó, sem a necessidade de redistribuição, permite uma utilização mais eficiente dos recursos de CPU e memória. Isso pode levar a uma melhor utilização do cluster como um todo, resultando em economia de custos e maior throughput das consultas.


Desvantagens em usar DistKey


Desequilíbrio de Dados (Data Skew)


Uma das maiores desvantagens é o risco de criar um desequilíbrio de dados entre os nós, conhecido como data skew. Se a coluna escolhida como DistKey tem baixa cardinalidade ou se os valores não estão distribuídos uniformemente, alguns nós podem acabar armazenando muito mais dados do que outros. Isso pode levar onde um nó está sobrecarregado, enquanto outros nós ficam subutilizados, resultando em performance degradada.


Flexibilidade Reduzida para Consultas Ad Hoc


Quando uma DistKey é definida, ela otimiza especificamente para os tipos de consultas que utilizam essa chave. No entanto, se as consultas ad hoc ou as necessidades analíticas mudarem, a DistKey pode não ser mais adequada. Alterar a DistKey requer um redesenho da tabela e possivelmente a redistribuição dos dados, o que pode ser um processo demorado e disruptivo.


Desempenho Pior em Consultas Não Otimizadas


Se consultas que não utilizam a DistKey de forma eficaz forem executadas, pode ocorrer uma performance ruim. Isso é particularmente relevante em cenários onde as consultas variam muito ou não seguem um padrão previsível. A ausência de movimentação de dados entre nós em consultas específicas pode ser um benefício em alguns casos, mas pode também limitar o desempenho em consultas que precisam acessar dados distribuídos em todos os nós.


Como criar uma DistKey na prática


Após a escolha da melhor estratégia baseando-se no que falamos acima, a criação é simples, basta adicionar a palavra chave DISTKEY na criação da tabela.


CREATE TABLE vendas (
    venda_id INT,
    cliente_id INT DISTKEY,
    data_venda DATE,
    valor DECIMAL(10, 2)
);

No exemplo acima, a coluna cliente_id foi definida como DistKey, otimizando as consultas que buscam dados de vendas por cliente.


SortKey e seu funcionamento


SortKey é a chave usada para determinar a ordem física em que os dados são armazenados nas tabelas do Redshift. A ordenação dos dados pode acelerar consideravelmente as consultas que utilizam filtros baseados nas colunas definidas como SortKey.


Sortkey e seus benefícios


Desempenho de Consultas com Filtros e Agrupamentos


Uma das principais vantagens de usar SortKey é a melhora do desempenho das consultas que aplicam filtros (WHERE), ordenações (ORDER BY), ou agrupamentos (GROUP BY) nas colunas definidas como SortKey. Como os dados são armazenados fisicamente no disco na ordem especificada pela SortKey, o Redshift pode ler apenas os blocos de dados necessários, em vez de realizar uma leitura completa da tabela.


Redução de I/O e Aumento da Eficiência


Com os dados ordenados por SortKey, o Redshift pode minimizar o I/O (input/output) ao acessar apenas os blocos de dados relevantes para a consulta. Isso é especialmente útil em tabelas grandes, onde a leitura completa de todas as linhas seria dispendiosa em termos de tempo e recursos. A redução do I/O resulta em um tempo de resposta mais rápido para as consultas.


Facilidade de Gerenciamento de Dados Temporais


SortKeys são particularmente úteis em colunas de data ou tempo. Quando você usa uma coluna de data como SortKey, consultas que filtram por intervalos de tempo, como "últimos 30 dias" ou "este ano", podem ser executadas muito mais rapidamente. Essa abordagem é muito comum em cenários onde os dados são consultados com base em datas, como logs de transações, acessos ou registros de eventos.


Apoio ao Comando VACUUM


O comando VACUUM é usado para reorganizar os dados no Redshift, removendo espaços livres e aplicando o ordenamento definido pela SortKey. Tabelas com uma SortKey bem definida se beneficiam mais desse processo, pois o VACUUM pode reorganizar os dados de maneira mais eficiente, resultando em uma tabela mais compacta e consultas ainda mais rápidas.


Desvantagens no uso da SortKey


Escolha Incorreta da Coluna de SortKey


Se uma coluna inadequada for escolhida como SortKey, pode não haver melhora significativa na performance das consultas, ou pior, a performance pode até piorar. Por exemplo, se a coluna escolhida não é frequentemente utilizada em filtros ou ordenações, a vantagem de acessar blocos de dados de maneira eficiente é perdida, ou seja, o Redshift irá varrer mais blocos, resultando em maior latência nas consultas.


Um exemplo seria definir uma coluna status (com poucos valores distintos) como SortKey em uma tabela onde as consultas geralmente filtram por transaction_date resultará em pouca ou nenhuma melhoria no tempo de execução.


Tamanho de tabela e reorganização


Em tabelas muito grandes, a reorganização dos dados para manter a eficiência da SortKey pode ser lenta e consumir muitos recursos. Isso pode afetar a disponibilidade e a performance geral do sistema.


Um exemplo seria quando uma tabela com bilhões de registros precisa ser reorganizada devido a inserções ou alterações que desordenam a SortKey, a operação de VACUUM pode demorar horas ou até dias, dependendo do tamanho da tabela e da carga de trabalho do cluster.


Difícil alteração da SortKey


Alterar a SortKey de uma tabela existente pode ser complicado e demorado, especialmente em tabelas grandes. Isso envolve a criação de uma nova tabela, a cópia dos dados para a nova tabela com a nova SortKey, e a remoção da tabela antiga.


Ou seja, se ê perceber que a coluna original escolhida como SortKey não está mais otimizando as consultas conforme esperado, a alteração da SortKey pode exigir uma migração completa dos dados, o que pode ser disruptivo.


Como criar uma SortKey na prática


Aqui, data_venda foi definida como SortKey, ideal para consultas que filtram registros com base em datas específicas ou intervalos de datas.


CREATE TABLE vendas (
    venda_id INT,
    cliente_id INT,
    data_venda DATE SORTKEY,
    valor DECIMAL(10, 2)
);

Concluindo tudo que falamos


SortKey é particularmente eficaz para acelerar consultas que filtram, ordenam ou agrupam dados. Ao ordenar fisicamente os dados no disco, SortKeys permitem que o Redshift leia apenas os blocos de dados relevantes, resultando em tempos de resposta mais rápidos e menor utilização de recursos. No entanto, a escolha errada de uma SortKey ou a falta de planejamento para gerenciar a reorganização dos dados pode levar a uma performance inferior e aumentar a complexidade do gerenciamento do banco de dados.

Por outro lado, DistKey é essencial para otimizar joins e agregações entre grandes tabelas. Ao distribuir os dados de maneira eficiente entre os nós do cluster, uma DistKey bem escolhida pode minimizar a movimentação de dados entre os nós, melhorando significativamente o desempenho das consultas. A escolha da coluna de DistKey deve ser baseada em sua cardinalidade e no padrão de consultas, para evitar problemas como desequilíbrio de dados e "nós quentes."

No entanto, tanto SortKey quanto DistKey requerem uma análise cuidadosa e planejamento. Usá-las de forma inadequada pode resultar em pouca ou nenhuma melhoria de performance, ou até mesmo piorá-la. Alterações nas SortKeys ou DistKeys também podem ser complexas e disruptivas em tabelas grandes.

Portanto, a chave para o uso eficaz de SortKey e DistKey no Redshift é um entendimento claro dos padrões de acesso aos dados e das necessidades de performance. Com o planejamento e monitoramento adequados, essas ferramentas podem transformar a maneira como você gerencia e consulta seus dados no Redshift, garantindo que seus dashboards e relatórios sejam rápidos e eficientes, mesmo à medida que o volume de dados cresce. Espero que tenha gostado da leitura sobre o uso deste recursos poderosos do Redshift, todos os pontos levantadas aqui foram baseados no dia a dia do meu time acompanhando ás áreas que utilizam dos dados na entrega de valor. Busquei a simplicidade para explicar de forma clara sobre a importância de pensar nas estratégias antes de definir as DistKeys e SortKeys, e também trouxe exemplos claros do mundo real facilitando o entendimento, Até a próxima!

Posts recentes

Ver tudo

Comments


bottom of page