Prometheus como backend de dados e Grafana como camada de visualização foram o ponto de partida natural. A combinação tornou dados operacionais visíveis rapidamente e funcionou enquanto o número de séries, dimensões e usuários permaneceu limitado. Então a análise de produto e sistema cresceu para usuários, links, páginas, indisponibilidade e outros sinais comportamentais e operacionais. Volume e cardinalidade ultrapassaram a faixa confortável do Prometheus.

Durante o horário de trabalho, consultas caras competiam com ingestão e retenção. Dashboards no Grafana ficavam lentos ou indisponíveis porque o backend Prometheus estava sob pressão. Escalar o mesmo modelo de storage significava pagar mais cloud por um sistema que continuava frágil no uso normal.

O problema era adequação ao workload, não ferramentas ruins

Prometheus é excelente para métricas recentes de infraestrutura e conjuntos limitados de labels. O problema surgiu quando pedimos a ele que se comportasse como uma grande plataforma analítica: retenção longa, dimensões de alta cardinalidade, consultas históricas amplas e muitas agregações exploratórias concorrentes. Grafana não era o gargalo, então não havia motivo para substituir a interface já conhecida pelos usuários.

Uma ferramenta pode ser excelente em seu trabalho original e ainda ser o modelo errado para um workload que mudou.

Os mesmos dados seguiam dois caminhos em paralelo

Dados de produto e sistema eram entregues em paralelo. Prometheus fornecia o caminho de baixa latência usado pelo Grafana, enquanto Snowplow coletava o stream de eventos e o carregava no Snowflake para histórico analítico. Ambos representavam usuários, atividade em páginas e links, disponibilidade, downtime e outras condições operacionais.

Antes: entrega duplicada
usuários + páginas + links + eventos do sistema
  ├─→ Prometheus ─────────────→ Grafana
  │       caminho em tempo real
  │
  └─→ Snowplow → Snowflake
          histórico analítico

Essa duplicação entregava atualização, mas também exigia operar um backend Prometheus cada vez mais caro para dados que já existiam no Snowflake. O objetivo passou a ser consolidar: manter Grafana, tornar Snowflake atualizado o suficiente para uso operacional e remover o caminho Prometheus.

Primeiro movimento: Snowflake Tasks agendadas

Como os dados do Snowplow já chegavam ao Snowflake, a primeira tentativa de consolidação usou Tasks agendadas para construir as visões de usuários, páginas, links, disponibilidade e sistema consumidas pelo Grafana. O compute podia escalar e suspender quando ocioso, evitando a pressão de recursos do Prometheus.

Mas Tasks agendadas não eram suficientemente próximas de tempo real. A atualização continuava presa à agenda. Intervalos menores aumentavam trabalho repetido e inicializações de warehouse; intervalos maiores deixavam Grafana atrás do estado atual. A arquitetura era estável, mas a experiência ainda não substituía o caminho paralelo do Prometheus.

Segundo movimento: mudanças incrementais com Snowflake Streams

Snowflake Streams mudou a unidade de processamento de “recalcular uma janela” para “consumir as linhas do Snowplow commitadas desde o último offset transacional”. Um consumidor orientado a mudanças atualizava apenas os agregados de usuários, páginas, links, downtime e sistema afetados pelos novos eventos.

Evolução do modelo de processamento
# Recálculo agendado
a_cada_intervalo:
    varrer_janela_recente
    reconstruir_agregados

# Processamento incremental
quando_stream_tem_mudancas:
    delta = consumir(stream)
    validar(delta)
    merge_agregados_afetados
    commit_atomico

Streams não executavam a transformação. Eles forneciam metadados transacionais de CDC e um offset. A camada de processamento consumia o stream com DML, avançava o offset no commit e podia executar apenas quando havia mudanças.

Depois: um único caminho analítico em tempo real
usuários + páginas + links + eventos do sistema
  → Snowplow
  → tabelas de eventos no Snowflake
  → Snowflake Streams
  → modelos operacionais incrementais
  → Grafana

caminho Prometheus: removido

Por que o design custava menos

Menos varreduras repetidas: o processamento tocava linhas alteradas em vez de reler grandes janelas recentes.
Compute elástico: analytics usava warehouses que podiam redimensionar e suspender automaticamente.
Storage adequado: histórico operacional volumoso passou para uma plataforma desenhada para retenção e leitura analítica.
Responsabilidades separadas: Grafana permaneceu como interface familiar; Snowflake assumiu storage, transformação e consultas analíticas em escala.

Por que ficou mais responsivo

Um agendamento fixo pergunta se o trabalho deve rodar porque o tempo passou. Um design orientado a Streams pergunta se dados commitados mudaram. Isso removeu execuções desnecessárias e permitiu processar deltas relevantes muito antes, aproximando analytics operacionais de tempo real sem manter o maior warehouse ligado continuamente.

Detalhes de confiabilidade que importam

Designs incrementais movem complexidade; não a eliminam. Cada consumidor independente precisa de seu próprio offset. Streams devem ser consumidos antes de ficarem stale. MERGE precisa ser idempotente, updates e deletes exigem tratamento correto, mudanças de schema pedem compatibilidade e o lag precisa ser observável.

Contrato operacional
monitorar:
  lag_do_stream
  stale_after
  linhas_consumidas
  duracao_do_merge
  creditos_do_warehouse
  atualizacao_dos_dados

alertar_quando:
  lag > slo_de_atualizacao
  ou stream_perto_de_stale
  ou merge_falhou

O resultado

Snowflake Streams tornou o caminho Snowplow–Snowflake suficientemente próximo de tempo real para substituir a entrega paralela ao Prometheus. Grafana permaneceu como superfície de visualização, mas Snowflake virou seu backend operacional e analítico. O custo de cloud caiu porque a plataforma deixou de operar um Prometheus cada vez mais superdimensionado e de recalcular dados que não mudaram.

A lição mais ampla é que visualização e infraestrutura de dados são decisões separáveis. Uma interface familiar pode permanecer enquanto seu modelo de storage e processamento evolui. Coloque histórico operacional de alta cardinalidade e análise exploratória em um sistema projetado para escala analítica, conectando a visualização com contratos explícitos de atualização e custo.

Este estudo de caso foi anonimizado e simplificado. Ele não identifica a empresa nem expõe dados internos, capacidade ou schemas.