Introducción
Regístrate para obtener una vista previa.
Si no nos ponemos en contacto contigo en un plazo de 1 día laborable, prueba a registrarte de nuevo.
La detección de anomalías y la detección de anomalías en miles de millones de series temporales es sumamente compleja. La mayoría de los sistemas actuales ejecutan la previsión y la detección de anomalías como tareas por lotes (por ejemplo, flujos de procesamiento de riesgo, previsión de tráfico, planificación de la demanda, etc.). Esto limita en gran medida el tipo de análisis que se puede realizar online (por ejemplo, debemos alertar de un aumento o una disminución repentinos en un conjunto de dimensiones de evento).
Los objetivos principales de hacer previsiones de series temporales y utilizarlos para detectar anomalías a través de la API Insights de series temporales son los siguientes:
- Escalar a miles de millones de series temporales (cuando una serie temporal se define como una serie de recuentos a lo largo del tiempo para una propiedad de evento, como el número de transacciones realizadas en un operador).
- proporciona latencia en tiempo real para la previsión y la detección de anomalías (por ejemplo, al cabo de unos segundos, detectar tendencias y estacionalidad en todas las series temporales publicadas y decidir si una parte concreta está sonando o disminuye de manera inesperada).
Funciones de API
- Indexa y carga un conjunto de datos que consta de varias fuentes de datos almacenadas en Google Cloud Storage. Permitir añadir eventos adicionales a una moda de streaming.
- Ejecuta consultas de series temporales sobre un conjunto de datos cargado para prever la tendencia y detectar anomalías.
- Descarga un conjunto de datos que ya no necesites.
- Pedir el estado de procesamiento de un conjunto de datos.
Datos de entrada
Los datos de series temporales son conjuntos de observaciones que se miden repetidamente en el tiempo.
Por ejemplo, el uso medio de CPUs de la tarea específica por minuto son los datos de series temporales sencillas. La unidad más pequeña de los datos de entrada es un punto de datos como un par clave-valor en un momento concreto. En este caso, la clave es el nombre de la dimensión. Las dimensiones del ejemplo pueden ser cpu, ram, state, etc.
Evento
La API Timeseries Insights utiliza los eventos como entrada de datos básico. En el caso de la gestión de puntos de datos en la escala de billones, se pueden usar varias dimensiones para las distintas rutas. Por ejemplo, el centro de datos, el usuario, los nombres de las tareas y los números de tareas se añaden para representar un evento completo.
{"name":"user","stringVal":"user_64194"},
{"name":"job","stringVal":"job_45835"},
{"name":"data_center","stringVal":"data_center_30389"},
{"name":"task_num","longVal":19},
{"name":"cpu","doubleVal":3840787.5207877564},
{"name":"ram","doubleVal":1067.01},
{"name":"state","stringVal":"idle"}
Cada objeto Event tiene:
- una marca de tiempo
- uno o varios parámetros, cada uno de los siguientes:
- un nombre (único en todo el conjunto de datos)
- un valor (cadena, booleano, int/long o doble)
Las dimensiones de un evento son propiedades relacionadas con el evento. En términos generales, un conjunto de nombres de dimensiones corresponde a un tipo de eventos. Por ejemplo, se utilizan
["user", "job", "data_center", "task_num", "gcu"]para los eventos de consumo de recursos de trabajo, y["user", "gcu", "disk", "ram"]para los eventos de cuota de usuario.
- un ID de grupo de valor largo, establecido en el mismo valor para los registros de Event relacionados. Lo más habitual es que cada registro de Event tenga un ID único. Entre los casos de ID de grupo también se incluyen los siguientes:
- un identificador de evento del mismo evento (con la misma marca de tiempo) de varios registros de Event, especialmente cuando distintos aspectos del mismo evento proceden de diferentes fuentes y no se fusionan antes de acceder al sistema. Por ejemplo, varios sensores que supervisan el mismo dispositivo pueden producir un registro de eventos independiente.
- Identificador de sesión de una colección de eventos relacionados (normalmente, con marcas de tiempo en un breve periodo). Un ejemplo son las actividades de una sesión de navegación web. También las entradas de registro de un taxi en bicicleta
- un identificador de cuenta de usuario, de modo que todos los Events con el mismo ID de grupo pertenecen al mismo usuario.
Conjunto de datos
Un DataSet es una colección de eventos. Cada consulta se realiza en el mismo conjunto de datos. Cada proyecto puede tener varios conjuntos de datos.
Cada conjunto de datos se puede crear a partir de datos por lotes y en streaming. Permiso para crear lecturas por lotes desde varios URI de Cloud Storage como fuentes de datos. Una vez completada la compilación por lotes, el conjunto de datos se puede actualizar con datos de transmisión. Al usar la compilación por lotes para el historial de datos, el sistema puede evitar problemas de arranque en frío.
Es necesario crear o indexar un conjunto de datos antes de consultarlo o actualizarlo. La indexación comienza cuando se crea el conjunto de datos y suele tardar minutos, en función de la cantidad de datos. Más concretamente, las fuentes de datos se analizan una vez durante la indexación inicial. Si el contenido de los URI de Cloud Storage cambia una vez completada la indexación inicial, no se volverán a analizar. Utilizar las actualizaciones de streaming para obtener más datos. Las actualizaciones de streaming se indexan de forma continua casi en tiempo real.
Nota: La API Insights de Timeseries no puede devolver las actualizaciones de streaming sin procesar, por lo que los clientes deben tener su propio almacenamiento para almacenar estos datos.
Series temporales y detección de anomalías
En la API Insights de TimeSeries, una parte es una colección de eventos con una determinada combinación de valores de dimensión. Nos interesa que estos eventos se distribuyan a lo largo del tiempo. En una división concreta, los eventos se agregan a valores numéricos por resolución del intervalo de tiempo que haya especificado un usuario, que es la serie temporal que se detecta como anomalías.
La figura anterior ilustra diferentes opciones de un conjunto de datos con dimensiones "user", "job", "data_center".
Se produce una anomalía de una parte concreta si el valor numérico del intervalo de interés es significativamente distinto del de los valores anteriores. En la imagen se muestra una serie temporal basada en temperaturas globales a lo largo de 10 años.
Supongamos que nos interesa saber si el último mes de 2015 es una anomalía. Una consulta al sistema especifica el intervalo de tiempo del interés, testInterval,que equivale a "un mes termina el 2015/12/31". La serie temporal recuperada antes de testInterval se dividía en un periodo de preparación anterior seguido de un periodo de retención. El sistema usa datos del periodo de preparación para preparar un modelo. Además, utiliza el periodo de bloqueo para verificar que el modelo puede predecir con precisión los siguientes valores. En este ejemplo, el periodo de espera es de 1 año. El periodo de retención suele oscilar entre un 5 y un 10% del historial total. En la imagen se muestran los datos reales y los valores previstos del modelo con los límites superior e inferior. La temperatura de 2015/12 se marca como una anomalía, ya que el valor real es significativamente fuera de los límites de la predicción.