Conceptos

En este artículo, revisaremos conceptos comunes con los que trabajamos en la API de Timeseries Insights y trataremos de proporcionar una explicación intuitiva sobre lo que representan.

Evento

Un evento es un dato y la entrada sin procesar con la que funciona la API de Timeseries Insights. Conceptualmente, representa una acción que realiza algún agente (p.ej., una transacción de un cliente o la publicación de un artículo de noticias) o una observación (p.ej., las lecturas de un sensor de temperatura o el uso de CPU en una máquina).

Un evento contiene lo siguiente:

  • Es un conjunto de valores en diferentes dimensiones, que representan propiedades que describen el evento, como etiquetas o mediciones numéricas.
  • Una marca de tiempo que representa la hora en que ocurrió el evento. Esta marca de tiempo se usará cuando agregues eventos para formar una serie temporal.
  • Un ID de grupo.

Dimensiones

Una dimensión representa un tipo de propiedad para los eventos de un conjunto de datos y el dominio de valores que puede tomar. Una dimensión puede ser de las siguientes maneras:

  • Categórica. Una propiedad de evento en esta dimensión puede contener uno de los valores limitados o finitos, generalmente strings. Algunos ejemplos son el nombre del país o del publicador en un conjunto de datos con artículos de noticias, el nombre de la máquina en un conjunto de datos con datos de supervisión de producción.
  • Numérico. Es una medición o una propiedad numérica general de un evento. Ejemplos: La cantidad de páginas vistas de artículos de noticias, el uso de CPU o la cantidad de errores relacionados con los datos de supervisión de producción.

Conjunto de datos

Un conjunto de datos es una colección de eventos con un nombre único dentro de un proyecto. Las consultas se realizan dentro del mismo conjunto de datos.

Grupo

Los eventos se pueden agrupar especificando el mismo ID de grupo (consulta Event.groupId). El grupo es similar a una "sesión" de actividades de Internet.

Por lo general, a cada registro Event se le asigna un ID de grupo único. Estos son algunos casos de uso del ID de grupo:

  • Un identificador de evento para el mismo evento (con las mismas marcas de tiempo o similares) de varios registros Event, especialmente cuando diferentes propiedades del mismo evento provienen de fuentes distintas y no se combinan antes de ingresar al sistema. Por ejemplo, varios sensores que supervisan el mismo dispositivo pueden producir un registro de evento independiente.
  • Un identificador de sesión para una colección de eventos relacionados (por lo general, con marcas de tiempo en un período corto). Un ejemplo son las actividades de una sesión de navegación web. Otro ejemplo son las entradas de registro de un viaje en taxi.
  • Un identificador de cuenta de usuario, por lo que todos los registros de Event con el mismo ID de grupo pertenecen al mismo usuario.

El propósito del grupo es calcular las correlaciones entre (dimensiones) de los eventos del mismo grupo. Por ejemplo, si tu conjunto de datos contiene datos de supervisión (como CPU, RAM, etc.), un grupo podría contener todos los datos de supervisión de un solo proceso. Con el tiempo, eso nos permitiría detectar que un aumento en la CPU está correlacionado con otro evento, como la actualización de una versión binaria en un momento anterior.

Si no tienes certeza o no te interesa calcular estos tipos de correlaciones, cada evento debe tener un ID de grupo único a nivel global. Omitir groupId tiene un efecto similar, y se genera un groupId interno basado en los contenidos y la marca de tiempo.

Porción

Una porción es el subconjunto de todos los eventos de un conjunto de datos que tienen algunos valores determinados en algunas dimensiones. Para una dimensión categórica, el valor dado es un único valor fijo; para una dimensión numérica, el valor dado es un rango.

Por ejemplo, supongamos que tenemos un conjunto de datos con las ventas de un minorista internacional y cada evento es una venta que tiene estas dimensiones categóricas: el país donde se realizó la venta, el nombre del producto, el nombre de la empresa que lo fabricó. Los ejemplos de porciones en este caso son: todas las ventas de un producto determinado, todas las ventas de un país determinado de todos los productos de una empresa determinada.

Series temporales

Las series temporales con las que trabajamos son de tiempo discreto, compuestas por puntos en intervalos de tiempo iguales. La duración de los intervalos temporales entre puntos consecutivos de la serie temporal se denomina nivel de detalle de las series temporales.

Una serie temporal se calcula de la siguiente manera:

  • Para una porción determinada, recopila todos los eventos en el intervalo de tiempo [detectionTime - TimeseriesParams.forecastHistory, detectionTime + granularity].
  • Agrupa estos eventos según su marca de tiempo y nivel de detalle. Se asigna un evento E a un punto que comienza en la hora T si E.eventTime está en el intervalo [T, T + granularity].
  • Agrega, para cada punto en la serie temporal, los eventos basados en la dimensión numérica especificada como métrica (TimeseriesParams.metric), que representa el valor de esos puntos. La agregación se puede hacer con un recuento (si no se especifica un metric, por lo general, si todas las dimensiones del evento son categóricas), mediante la suma o un promedio (si se especifica metric).

Punto de la serie temporal

Cada punto de una serie temporal tiene un tiempo y un valor asociados.

En realidad, time es un intervalo de granularity de duración con time como hora de inicio.

Si se especifica la métrica (TimeseriesParams.metric), debe ser una dimensión numérica. El value del punto se agrega a partir de los valores de dimensión en la dimensión metric de todos los eventos dentro del tiempo interno, mediante TimeseriesParams.metricAggregationMethod.

Si no se especifica ninguna métrica, el value del punto es la cantidad de eventos en el intervalo de tiempo.

Previsión

Es el proceso de predecir valores futuros para una serie temporal determinada. La previsión utiliza la parte inicial de la serie temporal como datos de entrenamiento para compilar un modelo.

Horizonte

Preveremos los valores de una serie temporal a partir del tiempo de detección hasta el horizonte temporal (proporcionado por el campo ForecastParams.horizonTime).

De manera intuitiva, este campo nos indica cuánto debemos hacer una previsión en el futuro. Si bien nos interesa principalmente el valor del punto de detección cuando clasificas una porción como una anomalía, permitimos que se prevean puntos adicionales, ya que pueden proporcionar información útil al usuario.

Hora y punto de detección

El tiempo de detección (especificado por QueryDataSetRequest.detectionTime) es el momento en el que se analizan posibles anomalías.

El punto de detección es el punto de la serie temporal en el momento de la detección.

Desviación esperada

Según la estabilidad y la previsibilidad de una serie temporal, podemos tener menos o más confianza en nuestra previsión. El nivel de confianza se refleja en el campo EvaluatedSlice.expectedDeviation, que especifica una desviación absoluta aceptable del valor que predijimos para el tiempo de detección.

Anomalía

Una porción se puede considerar una anomalía si la desviación entre los valores previstos y los reales durante el tiempo de detección es superior a lo que esperamos.

La puntuación de anomalía es la siguiente:

anomalyScore = (detectionPointActual - detectedPointForecast) / expectedDeviation

En general, las puntuaciones inferiores a 1.0 reflejan variaciones que son comunes en el historial de la porción, mientras que las puntuaciones superiores a 1.0 deben requerir atención, y las puntuaciones más altas representan anomalías más graves.

Umbral de ruido

La puntuación de anomalía, como se definió anteriormente, muestra qué tan estadísticamente significativa es una desviación con respecto a la normal. Sin embargo, en muchos casos, esta desviación podría no ser importante, ya que el cambio en el valor absoluto podría no ser de interés.

Por ejemplo, si una serie temporal tiene todos sus valores distribuidos de manera uniforme en el rango (9.9, 10.1), entonces expectedDeviation será ~0.1. Si la detectionPointForecast es 10.0 y la detectionPointActual es 10.3, anomalyScore será 3.0.

Si los cambios mayores en el valor absoluto te resultan más importantes, el umbral de ruido ofrece una manera de penalizar las porciones con cambios inferiores a ese umbral mediante una ponderación de la puntuación de anomalía:

anomalyScore = (detectionPointActual - DetectionPointForecast) / (expectedDeviation + noiseThreshold)

¿Qué sigue?