Como calcular rolling average por utilizador em Real-Time Analytics

Este tutorial mostra como calcular uma rolling average (média móvel) por utilizador em Real-Time Analytics, útil para monitorizar comportamentos como tempo médio de resposta ou pontuação média de eventos sem perder a actualização em tempo real. Vamos explicar o porquê e como implementar uma janela deslizante eficiente.

Pré-requisitos

• Fonte de eventos com timestamp e user_id (por exemplo: telemetry, logs ou eventos de aplicação).
• Plataforma de Real-Time Analytics que suporte janelas deslizantes (por exemplo: Azure Stream Analytics, Kafka Streams, Flink ou Kusto/ADX com streaming ingestion).
• Ferramentas para testar eventos (curl, kafka-console-producer, ou script Python simples).
• Conhecimentos básicos de queries estilo SQL para streaming ou KQL.

Passo 1: Entender o problema e escolher a janela

Porquê: a média móvel suaviza variações e permite análise por utilizador com base em comportamento recente. A escolha da janela depende do caso: janelas curtas (p.ex. 1 minuto) para detectores rápidos; janelas longas (p.ex. 1 hora) para tendências.

Decida também se pretende janela tumbling (não sobreposta) ou sliding (deslizante). Para médias por utilizador em tempo real é comum usar sliding window com actualização contínua.

Passo 2: Estruturar o evento

Garanta que cada evento tem pelo menos: timestamp, user_id, value. Exemplo mínimo em JSON para ingestão:

{
  "timestamp":"2026-10-24T12:34:56Z",
  "user_id":"user-123",
  "value": 42.5
}

Passo 3: Implementar a query de streaming (exemplo conceptual SQL-like)

Este exemplo mostra a lógica genérica: agrupar por user_id e aplicar uma janela deslizante de 5 minutos com actualização a cada 30 segundos. Adapte à sintaxe da sua plataforma (Azure Stream Analytics, Flink SQL, Kafka Streams, etc.).

SELECT
  user_id,
  System.Timestamp() AS window_end,
  AVG(value) AS rolling_avg
FROM input_stream
GROUP BY
  user_id,
  HOPPINGWINDOW(second, 30, 300, timestamp)

Explicação: HOPPINGWINDOW(second, 30, 300, timestamp) cria uma janela deslizante de 300s que avança a cada 30s. System.Timestamp() indica o fim da janela; AVG calcula a média por user_id dentro de cada janela.

Passo 4: Optimizar e lidar com late events

Eventos tardios podem afectar a média. Use tolerância para late events (watermark) e actualizações incrementais. Exemplo de parâmetro conceptual:

-- Pseudocódigo para watermark (varia por plataforma)
WATERMARK ON timestamp DELAY 60s

Isto permite aceitar eventos até 60s depois do timestamp sem os rejeitar. Para plataformas com state store (Flink, Kafka Streams), defina limites de estado e compactação por user_id para evitar crescimento indefinido.

Passo 5: Emitir resultados e armazenar estado

Decida se emite cada actualização como uma nova linha (stream de métricas) ou escreve para uma base de dados/tabela de agregados. Exemplo conceptual para output para uma tabela de métricas:

OUTPUT TO metrics_table
FIELDS (user_id, window_end, rolling_avg)

Se usar uma store com upsert (p.ex. Azure SQL, Cosmos DB, ClickHouse), utilize a chave (user_id, window_end) para substituir a média mais recente por janela.

Passo 6: Testar com dados de exemplo

Gere eventos para um utilizador e verifique como a média evolui. Exemplo em Python para enviar três eventos separados por 20s (pseudo-envio):

import requests, json, time
url = 'https://your-ingest-endpoint'
user = 'user-123'
for v in [10, 20, 30]:
    evt = {"timestamp":time.strftime('%Y-%m-%dT%H:%M:%SZ', time.gmtime()),
           "user_id":user, "value":v}
    requests.post(url, json=evt)
    time.sleep(20)

Analise as médias emitidas: após três eventos a rolling average deve refletir a média dos valores dentro da janela activa.

Verificar o resultado

Confirme que para cada user_id o stream de métricas mostra rolling_avg actualizada com a cadência (p.ex. a cada 30s) e que os valores correspondem às médias dos eventos dentro dos últimos 5 minutos. Erros comuns: timestamps fora de ordem (ver timezone), watermark demasiado curto a rejeitar eventos, e estado por user_id a crescer sem limites.

Conclusão

Calculou uma rolling average por utilizador em Real-Time Analytics usando janelas deslizantes, lidando com late events e considerações de estado. Próximos passos: ajustar janela/delay para o seu caso e integrar alertas quando a rolling_avg ultrapassar thresholds. Dica: comece com janelas maiores para validar e depois reduza para maior sensibilidade — que janela considera ser adequada para o seu caso?