Cómo calcular rolling average por usuario en Real-Time Analytics

João Barros 24 de October de 2026 4 min de lectura

Este tutorial muestra cómo calcular una rolling average (media móvil) por usuario en Real-Time Analytics, útil para monitorizar comportamientos como tiempo medio de respuesta o puntuación media de eventos sin perder la actualización en tiempo real. Vamos a explicar por qué y cómo implementar una ventana deslizante eficiente.

Prerequisitos

Fuente de eventos con timestamp y user_id (por ejemplo: telemetry, logs o eventos de aplicación).
Plataforma de Real-Time Analytics que soporte ventanas deslizantes (por ejemplo: Azure Stream Analytics, Kafka Streams, Flink o Kusto/ADX con streaming ingestion).
Herramientas para probar eventos (curl, kafka-console-producer, o script Python simple).
Conocimientos básicos de queries estilo SQL para streaming o KQL.

Paso 1: Entender el problema y elegir la ventana

Por qué: la media móvil suaviza variaciones y permite análisis por usuario basado en comportamiento reciente. La elección de la ventana depende del caso: ventanas cortas (p. ej. 1 minuto) para detectores rápidos; ventanas largas (p. ej. 1 hora) para tendencias.

Decida también si desea ventana tumbling (no solapada) o sliding (deslizante). Para medias por usuario en tiempo real es común usar sliding window con actualización continua.

Paso 2: Estructurar el evento

Garantice que cada evento tiene al menos: timestamp, user_id, value. Ejemplo mínimo en JSON para ingestión:

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

Paso 3: Implementar la query de streaming (ejemplo conceptual SQL-like)

Este ejemplo muestra la lógica genérica: agrupar por user_id y aplicar una ventana deslizante de 5 minutos con actualización cada 30 segundos. Adapte a la sintaxis de su 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)

Explicación: HOPPINGWINDOW(second, 30, 300, timestamp) crea una ventana deslizante de 300s que avanza cada 30s. System.Timestamp() indica el fin de la ventana; AVG calcula la media por user_id dentro de cada ventana.

Paso 4: Optimizar y manejar late events

Los eventos tardíos pueden afectar la media. Use tolerancia para late events (watermark) y actualizaciones incrementales. Ejemplo de parámetro conceptual:

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

Esto permite aceptar eventos hasta 60s después del timestamp sin rechazarlos. Para plataformas con state store (Flink, Kafka Streams), defina límites de estado y compactación por user_id para evitar crecimiento indefinido.

Paso 5: Emitir resultados y almacenar estado

Decida si emite cada actualización como una nueva fila (stream de métricas) o escribe en una base de datos/tabla de agregados. Ejemplo conceptual para output a una tabla de métricas:

OUTPUT TO metrics_table
FIELDS (user_id, window_end, rolling_avg)

Si usa una store con upsert (p. ej. Azure SQL, Cosmos DB, ClickHouse), utilice la clave (user_id, window_end) para sustituir la media más reciente por ventana.

Paso 6: Probar con datos de ejemplo

Genere eventos para un usuario y verifique cómo evoluciona la media. Ejemplo en Python para enviar tres eventos separados por 20s (pseudo-envío):

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)

Analice las medias emitidas: tras tres eventos la rolling average debe reflejar la media de los valores dentro de la ventana activa.

Verificar el resultado

Confirme que para cada user_id el stream de métricas muestra rolling_avg actualizada con la cadencia (p. ej. cada 30s) y que los valores corresponden a las medias de los eventos dentro de los últimos 5 minutos. Errores comunes: timestamps fuera de orden (ver timezone), watermark demasiado corto que rechace eventos, y estado por user_id que crece sin límites.

Conclusión

Ha calculado una rolling average por usuario en Real-Time Analytics usando ventanas deslizantes, gestionando late events y consideraciones de estado. Próximos pasos: ajustar ventana/delay para su caso e integrar alertas cuando la rolling_avg supere thresholds. Consejo: empiece con ventanas más grandes para validar y luego reduzca para mayor sensibilidad — ¿qué ventana considera adecuada para su caso?