Cómo calcular percentil en Real-Time Analytics: paso a paso

João Barros 21 de August de 2026 4 min de lectura

Aprende a calcular percentiles en Real-Time Analytics para monitorizar métricas de latencia y rendimiento en streaming. Saber calcular percentiles (p. ej. P50, P95, P99) en tiempo real ayuda a identificar degradaciones que la media no muestra: por ejemplo, una media de 120 ms puede ocultar que P95 = 450 ms, lo que significa que el 5% de las peticiones son muy lentas y afectan la experiencia del usuario.

Requisitos previos

Cuenta con acceso a un servicio que soporte consultas en streaming (p. ej.: Azure Data Explorer/ADX, también aplicable a otros motores que soporten KQL).
Datos de telemetría con timestamp y un campo numérico (p. ej. latency_ms). Idealmente los eventos tienen event time e ingestion time para gestionar latencia y reordenaciones.
Conocimientos básicos de KQL (filtros, extend, summarize).
Capacidad de ingestión adecuada — por ejemplo 1k–10k eventos/s para pequeños setups; para volúmenes mayores considera partición y compresión.
Política de retención y ventanas definidas (p. ej. 7 días de datos, agregaciones por minuto para paneles en tiempo real).

Paso 1: Estructurar el stream con timestamps y particiones

Es esencial garantizar que los eventos tienen timestamps correctos (event time) y, si es necesario, una clave de partición (p. ej. region o service). Eventos con timestamps erróneos crean ventanas con ceros o solapamientos. Para streaming en producción, aplica watermarking de 30s–2m según la confianza del reloj de los productores. Particiones como service o region permiten calcular percentiles por segmento sin mezclar tráfico heterogéneo.

// Exemplo: dados simulados para testar
let telemetry = datatable(Timestamp:datetime, service:string, latency_ms:double)
[
  datetime(2026-08-21 10:00:01), "api-a", 120.5,
  datetime(2026-08-21 10:00:02), "api-a", 95.0,
  datetime(2026-08-21 10:00:03), "api-b", 300.2,
  datetime(2026-08-21 10:00:04), "api-a", 110.1
];
telemetry

Paso 2: Elegir ventana temporal y estrategia (disjoint vs sliding)

Decide si quieres ventanas disjuntas (tumbling) o ventanas móviles (sliding). Ventanas tumbling (p. ej.: 1 minuto) dan agregados sencillos y son eficientes para informes periódicos. Ventanas sliding (p. ej.: ventana de 5 minutos con paso de 1 minuto) proporcionan percentiles más suaves y continuos, pero cuestan más porque solapan cálculos — típicamente ~N veces más trabajo donde N es el número de pasos por ventana. Por ejemplo, una ventana sliding de 5m con paso de 1m implica calcular 5 veces más agregaciones que tumbling 1m.

// Tumbling de 1 minuto
telemetry
| where Timestamp > ago(15m)
| summarize percentiles(latency_ms, 50, 95, 99) by bin(Timestamp, 1m), service

// Sliding de 5 minutos con paso de 1 minuto (usar range de bins recorrentes)
telemetry
| where Timestamp > ago(15m)
| serialize
| extend window_start = bin(Timestamp, 1m)
| summarize percentiles(latency_ms, 50, 95, 99) by window_start, service
| order by window_start asc

Paso 3: Usar la función percentiles correctamente

La función percentiles (o percentileif/percentile según el motor) calcula percentiles de forma eficiente. En ADX, percentiles acepta múltiples percentiles como argumentos. Para grandes volúmenes, considera algoritmos aproximados (TDigest, sketches) o reducir la precisión para disminuir coste y latencia. Ej.: usar aproximación que da error típico de ±1–2% en los cuantiles para grandes muestras.

// Percentis P50, P95, P99 por servicio por minuto
telemetry
| where Timestamp > ago(30m)
| summarize percentiles(latency_ms, 50, 95, 99) by bin(Timestamp, 1m), service
| project Timestamp, service, P50=latency_ms_50, P95=latency_ms_95, P99=latency_ms_99

Paso 4: Manejar la cardinalidad y los outliers

Los percentiles pueden ser poco fiables con pocas muestras. Define un umbral de confianza: por ejemplo, cnt >= 10 para visibilidad básica, cnt >= 30 para estadística razonable y cnt >= 100 para alta confianza. Filtra valores inválidos (negativos, ultra-altos por error) y marca ventanas con baja cuenta. Para outliers extremos, puedes truncar valores por encima de un SLA (p. ej.: latency_ms > 60s) o aplicar winsorizing.

// Filtrar valores negativos, calcular count y aplicar umbral mínimo de muestras
telemetry
| where Timestamp > ago(30m) and latency_ms >= 0 and latency_ms < 60000
| summarize cnt=count(), percentiles(latency_ms, 50, 95, 99) by bin(Timestamp, 1m), service
| where cnt >= 10
| project Timestamp, service, cnt, P50=latency_ms_50, P95=latency_ms_95, P99=latency_ms_99

Paso 5: Agregar y exportar para dashboards en tiempo real

Exporta los resultados a un panel (p. ej. Power BI, Grafana) o escribe en una tabla de agregados para históricos. En ADX puedes usar el connector Power BI para datos en near real-time o almacenar agregados con .set-or-append / update policy para evitar rehacer cálculos. Evalúa el coste: agregaciones por minuto para 100 servicios durante 24h resultan en ~144k ventanas/día; optimiza reduciendo resolución o usando sketches.

// Ejemplo simplificado: escribir en una tabla de agregados (pseudo-sintaxis)
let aggreg =
telemetry
| where Timestamp > ago(30m) and latency_ms >= 0
| summarize cnt=count(), percentiles(latency_ms, 50, 95, 99) by bin(Timestamp, 1m), service;

// En ADX, puedes usar .set-or-append para escribir en una tabla existente
// .set-or-append Aggregates <| aggreg

Verificar el resultado

Confirma que tienes filas por cada ventana y que cnt (conteo) tiene sentido. Compara percentiles con un histograma (bins de 10–50 ms) para validar la forma de la distribución. Errores comunes: eventos con timestamps en el futuro/antes causando ventanas vacías, cuentas bajas y percentiles NaN, y ventanas con valores anómalos por reenvíos. Si P95/P99 varían mucho en un corto espacio, investiga causas (deploy, GC, overload).

Conclusión

Calcular percentiles en Real-Time Analytics permite medir la experiencia real del usuario y detectar regresiones que la media no muestra. Próximos pasos: probar ventanas sliding para visibilidad continua, usar TDigest/sketches para reducir costes en grandes volúmenes, e integrar con alertas (p. ej.: alertar si P95 > 300 ms durante 3 ventanas consecutivas). Decide qué percentil usar según tu SLA — P95 es útil para latencias generales, P99 para picos raros.