Estratégias de cold path e warm path em arquiteturas de processamento analítico

1. Fundamentos das Arquiteturas de Processamento Analítico

1.1. Definição de cold path, warm path e hot path

Em arquiteturas modernas de processamento analítico, os dados fluem por diferentes caminhos definidos por três parâmetros críticos: latência, volume e granularidade.

  • Hot path: dados em tempo real, com latência de milissegundos a segundos. Processa eventos individuais com baixo volume por transação. Exemplo: detecção de fraudes em pagamentos.
  • Warm path: dados semi-real-time, com latência de segundos a minutos. Processa agregados ou janelas curtas. Exemplo: dashboards operacionais.
  • Cold path: dados históricos, com latência de horas a dias. Processa volumes massivos em lote. Exemplo: relatórios financeiros anuais.

1.2. Trade-offs entre throughput, custo e tempo de resposta

A escolha entre os caminhos envolve um balanço delicado:

Característica Hot Path Warm Path Cold Path
Throughput Baixo Médio Alto
Custo por GB Alto Médio Baixo
Tempo de resposta ms s-min h-dias
Granularidade Evento Agregado Completo

1.3. Contexto de aplicação

Sistemas analíticos modernos combinam esses caminhos. Por exemplo, uma plataforma de e-commerce usa hot path para recomendações em tempo real, warm path para métricas de vendas do dia e cold path para análise de tendências sazonais.

2. Warm Path: Processamento de Dados Semi-Real-Time

2.1. Características do warm path

O warm path opera com janelas de tempo curtas (5 a 60 minutos) e dados pré-agregados. A latência alvo fica entre 1 e 60 segundos. Exemplo de agregação em janela:

Janela: 5 minutos
Agregação: soma de vendas por categoria
Latência: 10 segundos
Armazenamento: 7 dias de dados agregados

2.2. Tecnologias típicas

Bancos OLAP em memória como Druid e ClickHouse são escolhas comuns. Frameworks de streaming como Kafka Streams e Apache Flink realizam o processamento. Exemplo de pipeline com Kafka Streams:

Topologia:
1. Consumir tópico "vendas" do Kafka
2. Agrupar por categoria (janela de 5 min)
3. Calcular soma do valor
4. Produzir para tópico "vendas_agregadas"
5. Druid ingere e serve consultas subsegundo

2.3. Casos de uso

Dashboards operacionais que exigem atualização a cada poucos segundos: métricas de conversão, taxa de erros em APIs, monitoramento de infraestrutura.

3. Cold Path: Processamento Batch de Longa Duração

3.1. Características do cold path

Processa datasets completos sem restrições de tempo real. Volume típico: terabytes a petabytes. Latência aceitável: 1 a 24 horas. Exemplo de job batch:

Job: relatório diário de vendas
Entrada: 500 GB de logs brutos em S3
Processamento: Apache Spark (20 workers)
Duração: 45 minutos
Saída: tabela particionada por data em Parquet

3.2. Tecnologias típicas

Data lakes em S3 ou HDFS armazenam os dados brutos. Apache Spark realiza transformações complexas. Presto/Trino e Hive permitem consultas SQL sobre os dados processados.

3.3. Casos de uso

Relatórios financeiros auditáveis, treinamento de modelos de machine learning, análises de tendências de longo prazo.

4. Estratégias de Separação e Integração entre os Caminhos

4.1. Modelo Lambda

Combina camadas batch (cold) e streaming (warm) unificadas por uma camada de serving:

Camada Batch: Spark processa dados históricos -> Tabela "vendas_completas"
Camada Streaming: Flink processa dados recentes -> Tabela "vendas_recentes"
Camada Serving: View unificada que combina ambas as fontes
Consulta: SELECT * FROM vendas_unificado WHERE data >= '2024-01-01'

4.2. Modelo Kappa

Processamento único baseado em streaming, com cold path como replay de eventos:

Pipeline único:
1. Kafka retém todos os eventos (7 dias)
2. Flink processa streaming contínuo
3. Para dados históricos: Kafka replay de partições antigas
4. Dados são armazenados em formato imutável (Avro)

4.3. Critérios de escolha

Lambda oferece consistência e é mais fácil de depurar, mas requer manutenção de duas pipelines. Kappa simplifica a arquitetura, mas exige que todo processamento seja expressável como streaming.

5. Gerenciamento de Dados e Otimização de Armazenamento

5.1. Estratégias de particionamento e retenção

Tiers de armazenamento em data lakes:

Hot Tier (7 dias): SSD, dados não particionados
Warm Tier (30 dias): HDD, particionado por dia
Cold Tier (365 dias): S3 Glacier, particionado por mês

5.2. Compactação e compressão

No cold path, arquivos pequenos são combinados em arquivos maiores (256 MB a 1 GB) e comprimidos com Snappy ou Zstandard:

Antes: 10.000 arquivos JSON de 1 MB cada (10 GB)
Após compactação: 40 arquivos Parquet de 256 MB (2 GB)
Redução: 80% de espaço, 95% menos arquivos

5.3. Sincronização entre warm e cold

Jobs de reconciliação diária detectam e corrigem inconsistências:

Job de reconciliação (execução diária às 02:00):
1. Ler agregados do warm path (últimas 24h)
2. Reprocessar logs brutos no cold path
3. Comparar métricas chave (soma, contagem)
4. Se diferença > 0.1%, disparar alerta
5. Atualizar tabela de correção

6. Métricas de Performance e Monitoramento

6.1. Principais KPIs

  • Latência p50/p99: tempo entre ingestão e disponibilidade para consulta
  • Taxa de ingestão: eventos por segundo no warm path, GB/hora no cold path
  • Volume processado: dados totais transformados por janela

6.2. Monitoramento de gargalos

Métricas de warm path:
- CPU dos workers de streaming (>80% = alerta)
- Lag do consumidor Kafka (>1000 mensagens = alerta)

Métricas de cold path:
- I/O do Spark shuffle (>1 GB/s por worker = contenção)
- Tempo de leitura do S3 (>500ms por request = degradação)

6.3. Estratégias de alerta

Alertas configurados para degradação de SLA (>10% acima do esperado), inconsistências entre caminhos (diferença >0.5% em métricas chave) e custos acumulados (>20% acima do orçamento mensal).

7. Casos Práticos e Considerações de Implementação

7.1. Exemplo de arquitetura híbrida

Warm Path:
- Apache Kafka (tópico "eventos_web")
- Apache Flink (agregação em janelas de 5 min)
- Apache Druid (armazenamento e consulta)
- Latência: 10 segundos

Cold Path:
- Apache Kafka (tópico "eventos_web" completo)
- Apache Spark (processamento batch diário)
- Amazon S3 (armazenamento em Parquet)
- Presto (consultas ad-hoc)
- Latência: 1 hora

Camada de Serving:
- API unificada que roteia consultas:
  * Últimos 7 dias -> Druid
  * Histórico completo -> Presto + S3

7.2. Desafios comuns

  • Data skew: partições desbalanceadas no Kafka causam backpressure
  • Backpressure: quando warm path não consegue processar na velocidade de ingestão
  • Reprocessamento: reprocessar 30 dias de dados pode levar horas e consumir recursos significativos

7.3. Tendências

Uso de object storage como camada unificada com Delta Lake, Apache Hudi ou Iceberg permite que warm e cold path compartilhem o mesmo storage, simplificando a arquitetura. Serverless analytics (Athena, BigQuery) reduz custos operacionais ao eliminar gerenciamento de clusters.

Referências