Estratégias de particionamento de dados para consultas analíticas rápidas

1. Fundamentos do Particionamento de Dados

Particionamento de dados é a técnica de dividir uma tabela lógica em segmentos físicos menores, chamados partições, com base em critérios específicos. Essa divisão permite que consultas analíticas processem apenas as partições relevantes, reduzindo drasticamente o volume de dados escaneados.

Particionamento horizontal divide linhas em diferentes partições (ex.: todos os dados de janeiro em uma partição, fevereiro em outra). Já o particionamento vertical divide colunas, sendo menos comum em bancos analíticos.

A diferença fundamental entre particionamento e indexação está no escopo: enquanto índices aceleram a localização de registros específicos dentro de uma tabela, partições eliminam completamente segmentos inteiros da varredura. Para consultas analíticas que agregam milhões de registros, o particionamento é geralmente mais eficiente que índices tradicionais.

-- Exemplo: tabela particionada por data no PostgreSQL
CREATE TABLE vendas (
    id SERIAL,
    data DATE,
    valor NUMERIC,
    regiao TEXT
) PARTITION BY RANGE (data);

CREATE TABLE vendas_2024_01 PARTITION OF vendas
    FOR VALUES FROM ('2024-01-01') TO ('2024-02-01');
CREATE TABLE vendas_2024_02 PARTITION OF vendas
    FOR VALUES FROM ('2024-02-01') TO ('2024-03-01');

2. Escolha da Chave de Particionamento

A seleção da chave de particionamento é a decisão mais crítica. Cardinalidade refere-se ao número de valores distintos em uma coluna. Colunas com alta cardinalidade (ex.: ID do cliente) criam muitas partições pequenas, enquanto colunas de baixa cardinalidade (ex.: status: ativo/inativo) geram partições grandes demais.

Critérios práticos para escolha:
- Data: ideal para séries temporais, com granularidade ajustável (ano, mês, dia)
- Região geográfica: útil quando consultas filtram por localização
- Categoria de produto: adequado para análises de catálogo

Armadilha comum — "small files problem": partições muito pequenas (ex.: por hora em sistemas de baixo volume) geram milhares de arquivos minúsculos, sobrecarregando o metadata e degradando performance. O oposto — partições enormes — elimina os benefícios do pruning.

-- Exemplo ruim: partição por hora em tabela com 100 registros/dia
-- Resultado: 2400 partições minúsculas por mês

-- Exemplo bom: partição por dia com compactação automática
CREATE TABLE eventos (
    ts TIMESTAMP,
    payload JSONB
) PARTITION BY RANGE (ts);

-- Rolling partitions: manter apenas 90 dias
CREATE TABLE eventos_2024_01_01 PARTITION OF eventos
    FOR VALUES FROM ('2024-01-01') TO ('2024-01-02');

3. Estratégias de Particionamento Temporal

O particionamento temporal é o mais comum em analytics. A granularidade depende da frequência de consultas e volume de dados:

  • Por ano: para dados históricos com consultas anuais
  • Por mês: balanço entre granularidade e número de partições
  • Por dia: ideal para sistemas com milhões de registros diários
  • Por hora: apenas para dados de altíssimo volume (IoT, logs)

Rolling partitions são essenciais para dados em streaming. Consistem em criar partições futuras automaticamente e descartar partições antigas além do período de retenção.

-- Script de rolling partitions (pseudo-código)
-- Criar partição para amanhã
CREATE TABLE logs_2024_03_16 PARTITION OF logs
    FOR VALUES FROM ('2024-03-16') TO ('2024-03-17');

-- Remover partição com mais de 30 dias
DROP TABLE IF EXISTS logs_2024_02_15;

Gerenciamento de retenção: partições temporais facilitam o arquivamento. Basta mover partições antigas para storage mais barato (S3 Glacier, Azure Archive) e removê-las da tabela ativa.

4. Particionamento Híbrido e Multidimensional

Combinar múltiplas chaves de particionamento pode otimizar consultas complexas. O padrão mais comum é data + outra dimensão (país, categoria).

Subpartições (partições compostas): criam uma hierarquia. Exemplo: partição principal por mês, subpartição por região.

-- Particionamento composto: data + região
CREATE TABLE vendas_completo (
    data DATE,
    regiao TEXT,
    valor NUMERIC
) PARTITION BY RANGE (data);

CREATE TABLE vendas_2024_01 PARTITION OF vendas_completo
    FOR VALUES FROM ('2024-01-01') TO ('2024-02-01')
    PARTITION BY LIST (regiao);

CREATE TABLE vendas_2024_01_norte PARTITION OF vendas_2024_01
    FOR VALUES IN ('Norte');
CREATE TABLE vendas_2024_01_sul PARTITION OF vendas_2024_01
    FOR VALUES IN ('Sul');

Quando evitar: partições aninhadas em mais de 2 níveis geralmente degradam performance devido à complexidade do metadata. Além disso, se uma consulta não filtrar pela chave primária, todas as subpartições serão escaneadas.

5. Particionamento em Data Lakes Modernos (Delta Lake, Iceberg)

Data lakes modernos como Delta Lake e Apache Iceberg integram particionamento com recursos ACID e time travel. O layout de arquivos usa formatos colunares (Parquet, ORC) que maximizam o pruning de partições.

Boas práticas em Delta Lake:
- Usar ZORDER BY para otimizar consultas em colunas não particionadas
- Compactar arquivos pequenos com OPTIMIZE
- Aproveitar VACUUM para remover versões antigas

-- Delta Lake: criando tabela particionada
CREATE TABLE vendas_delta (
    data DATE,
    produto STRING,
    quantidade INT,
    valor DOUBLE
) USING DELTA
PARTITIONED BY (data, produto);

-- Otimização com ZORDER
OPTIMIZE vendas_delta
ZORDER BY (quantidade);

-- Time travel: consultar estado anterior
SELECT * FROM vendas_delta VERSION AS OF 12345;

Apache Iceberg oferece particionamento oculto (hidden partitioning), onde o engine gerencia automaticamente a evolução do esquema de partição sem reescrever dados.

6. Monitoramento e Manutenção de Partições

Ferramentas como SHOW PARTITIONS (Spark, Athena) e consultas ao information_schema ajudam a detectar problemas:

Problemas comuns:
- Partições desbalanceadas (algumas com 10GB, outras com 10MB)
- Fragmentação (muitos arquivos pequenos por partição)
- Partições órfãs (sem metadados correspondentes)

Estratégias de manutenção:

-- Detectar partições desbalanceadas no Spark
SHOW PARTITIONS vendas;

-- Reparticionamento (repartitioning) com coalesce
df.repartition(100)  -- aumenta partições
df.coalesce(10)      -- reduz partições

-- Compactação de arquivos pequenos
OPTIMIZE vendas_delta
WHERE data >= '2024-01-01';

Automação: pipelines em Airbyte ou GitHub Actions podem executar scripts de manutenção noturnos, verificando o número de arquivos por partição e compactando quando necessário.

7. Estudo de Caso e Comparação Prática

Cenário: tabela de eventos de e-commerce com 1 bilhão de registros (3 anos de dados), consultas analíticas filtrando por mês e categoria de produto.

Estratégias testadas:

Estratégia Tempo de consulta Armazenamento Complexidade
Sem partição 45 segundos 500 GB Baixa
Partição por mês 8 segundos 510 GB Média
Partição por mês + categoria 3 segundos 520 GB Alta
Partição por dia 12 segundos 550 GB Média

Resultados: a combinação mês + categoria foi 15x mais rápida que a tabela não particionada. A partição por dia foi pior que por mês devido ao excesso de partições.

Lições aprendidas:
1. Teste sempre granularidades diferentes — a teoria nem sempre reflete a prática
2. Monitore o tamanho das partições (ideal: 100MB-1GB por partição em data lakes)
3. Automatize a manutenção — partições não se gerenciam sozinhas
4. Considere o custo de metadata: muitas partições lentificam operações de catalog

Recomendação final: comece com particionamento temporal mensal, adicione uma segunda dimensão apenas se consultas frequentes filtrarem por ela, e implemente compactação automática desde o primeiro dia.

Referências