Do Disco ao Redshift: Arquitetura Colunar na Prática

Como reduzir a latência de uma API de 2.8 segundos para 8ms usando arquitetura colunar. A apresentação parte de um caso real — uma API de sugestão de comissão consultando 15
milhões de registros — para explicar as diferenças fundamentais entre armazenamento row-oriented (Postgres) e column-oriented (Redshift): I/O, trade-offs OLTP vs OLAP,
distribution keys, sort keys, zone maps e o papel do MPP. A solução combina ETL com PySpark, agregação no Redshift e uma serving layer em Postgres, alcançando uma melhoria
de 350x na latência. Inclui anti-patterns, checklist de quando usar banco colunar e práticas de manutenção com VACUUM e ANALYZE.

Transcript

1. Do Disco ao Redshift Arquitetura Colunar na Prática
2. Vagner Clementino | Staff Engineer Março 2026 15M records case study: 2.8s → 8ms 1
3. O Problema: A Realidade da API de Comissão API: POST /commission/suggest?category=1&niche=10&price=135 Resposta necessária: < 50ms Dados: 15M registros de vendas Query ingênua Postgres: 2.8s Solução: Colunar + Serving Layer 2
4. Row-Oriented: Como Postgres Armazena Bloco 64KB no HD/SSD: [ID=1, Nome=João, Email=joao@email, Saldo=100.50, Data=2026-01-01] [ID=2, Nome=Maria, Email=maria@email, Saldo=250.75, Data=2026-01-02] Para calcular AVG(saldo): Lê o bloco INTEIRO (5 colunas) Extrai só o saldo I/O desperdiçado: 80% dos dados 3
5. Column-Oriented: Como Redshift Armazena Mesmo espaço 64KB dividido por coluna: Bloco 1 (ID): [1, 2, 3, 4, 5...] Bloco 2 (Nome): [João, Maria, Pedro...] Bloco 3 (Email): [joao@email, maria@email...] Bloco 4 (Saldo): [100.50, 250.75, 75.30...] Para calcular AVG(saldo): Lê APENAS Bloco 4 I/O: 1/5 (20% do original) 4
6. Row vs Columnar: Matemática do I/O Tabela: 100 colunas, 10M linhas, 1TB total Query: AVG(3 colunas) WHERE 2 colunas Cenário I/O Row-store 100% = 1TB lido Column-store 5% = 50GB lido Ganho: 20x menos disco Queries: 10-100x mais rápidas 5
7. Row vs Columnar: Trade-offs Cenário Row Columnar INSERT/UPDATE Rápido Lento SELECT * OK Ruim AVG por categoria Lento Rápido JOINs analíticos Lento Rápido 100GB+ dados Ruim Ótimo Row = OLTP | Columnar = OLAP 6
8. Arquitetura Redshift: Leader + MPP Leader Node (Query Planner): Recebe SQL Gera plano distribuído Coordena execução Compute Nodes (Execução Paralela): 16+ CPUs por nó Slices processam dados em paralelo Resultado: 16x mais rápido com 16 nós 7
9. Distribution Key (DISTKEY): O Segredo dos Joins SEM DISTKEY: customer=123 → Nós 1,3,5,7 (randomizado) JOIN precisa redistribuir → 10x mais lento COM DISTKEY(customer_id): customer=123 → SEMPRE no Nó 3 JOIN é local, sem reshuffle 8
10. Distribution Styles: Qual Escolher? KEY: Ótimo para joins frequentes Evite meses, booleanos (baixa cardinalidade) EVEN: Load balancing | Joins custosos ALL: Joins locais (<2GB) | Disco duplicado AUTO: Redshift decide (comece com isso) 9
11. Sort Key + Zone Maps: Pular Blocos Inteiros SORTKEY(sale_date, customer_id): Bloco 1: 2026-01-01T00:00 [cust123, cust124...] Bloco 2: 2026-01-01T12:00 [cust125...] Bloco 3: 2026-01-02T00:00 [cust126...] Query: WHERE sale_date >= '2026-01-02' → Pula Bloco 1-2 (Zone Map) → Lê só Bloco 3 (70% menos I/O) 10
12. Compound vs Interleaved Sort Keys Compound Sort Key (PADRÃO): Ordem IMPORTA Exemplo: (sale_date, customer_id) Ideal para time-series (DATE primeiro) Menos overhead Interleaved Sort Key (Raro): Múltiplas ordens equitativas Mais overhead em VACUUM Use só se absolutamente necessário 11
13. Caso Real: Tabela de Comissões CREATE TABLE fact_sales ( customer_id BIGINT, product_id BIGINT, sale_date DATE, sale_price DECIMAL(10,2), commission_paid DECIMAL(10,2) ) DISTKEY(customer_id) SORTKEY(sale_date, customer_id); Justificativa: DISTKEY: JOINs com dim_customer frequentes SORTKEY: Filtros por data + análise por customer 12
14. Solução Completa: ETL + Serving Layer Postgres (OLTP) ← transações ↓ PySpark ETL (diário) Redshift (Analytics) ← 15M rows ↓ TRUNCATE + INSERT Postgres Serving ← 2.5K rows ↓ lookup 8ms Spring Boot API 13
15. ETL PySpark: De 15M para 2.5K Agregações SELECT category_id, niche_id, FLOOR(sale_price/50)*50 AS bucket_min, AVG(commission_paid/sale_price*100) AS pct, COUNT(*) AS support_count FROM fact_sales GROUP BY 1,2,3; Resultado: ~50 buckets × ~50 combos = 2.5K linhas Tempo Redshift: 18 segundos 14
16. API Serving Layer: Lookup em 8ms SELECT suggested_pct FROM commission_suggestion WHERE category_id = 1 AND niche_id = 10 AND 135 BETWEEN bucket_min AND bucket_max ORDER BY support_count DESC LIMIT 1; Index: (category_id, niche_id, bucket_min) Tempo: ~8ms Latência API p99: < 10ms 15
17. Performance: Números que Falam Stack ETL Time API Latency Só Postgres - 2.8s Redshift direto 18s 240ms Redshift+Serving 18s 8ms 350x mais rápido! 16
18. Manutenção Essencial: VACUUM e ANALYZE VACUUM: Reordena dados conforme SORTKEY Recupera espaço após DELETE Execute APÓS bulk COPY Schedule: off-peak (madrugada) ANALYZE: Atualiza table statistics Melhora query planner decisions Execute regularmente (semanal) 17
19. Anti-Patterns: O Que NÃO Fazer DISTKEY em coluna com baixa cardinalidade (meses, booleanos) SELECT * em tabelas com 100+ colunas Múltiplos JOINs sem DISTKEY alinhado Não fazer VACUUM após COPY Usar Interleaved Sort Key por padrão 18
20. Checklist: Quando Usar Redshift <10GB de dados? → Postgres (mais barato) 10GB - 1TB, queries analíticas frequentes? → Redshift + serving layer >1TB, team dedicado? → Snowflake/Redshift + materialised views Transações OLTP? → NUNCA use colunar direto 19
21. Melhores Práticas Consolidadas Design: DISTKEY = JOIN column (alta cardinalidade) Sort: SORTKEY primeira coluna = DATE Queries: SELECT colunas específicas (não SELECT *) Maintenance: VACUUM pós-COPY, ANALYZE semanal Monitoramento: Detectar skew, ver query plans Padrão: Staging → Core → Marts Híbrido: Row (OLTP) + Colunar (Analytics) 20
22. Perguntas? 21
23. Referências Principais AWS Docs - Columnar Storage https://docs.aws.amazon.com/redshift/latest/dg/c_columnar_storage_disk_mem_m gmnt.html Bix-Tech - Redshift Done Right (2025) https://bix-tech.com/amazon-redshift-done-right-a-practical-blueprint-for- designing-a-scalable-high-performance-data-warehouse/ OneUptime - DISTKEY/SORTKEY Optimization (2026) https://oneuptime.com/blog/post/2026-02-12-optimize-redshift-distribution- and-sort-keys/ Flexera - Query Optimization (2026) https://www.flexera.com/blog/finops/optimizing-redshift-performance/ 22
24. Código e Recursos GitHub: github.com/vagnerclementino/redshift-commission Blog: notes.clementin.me 23
25. Obrigado! Vagner Clementino | Staff Engineer Março 2026 Aproveita a apresentação e compartilha feedback! 24