Introducción
La previsión y la detección de anomalías en miles de millones de series temporales requieren muchos recursos computacionales. La mayoría de los sistemas actuales ejecutan la previsión y la detección de anomalías como tareas por lotes (por ejemplo, las canalizaciones de riesgo, la previsión del tráfico o la planificación de la demanda). Esto limita considerablemente el tipo de análisis que puede realizar online, como decidir si se debe enviar una alerta en función de un aumento o una disminución repentinos en un conjunto de dimensiones de evento.
Los objetivos principales de la API Timeseries Insights son los siguientes:
- Escala a miles de millones de series temporales que se construyen dinámicamente a partir de eventos sin procesar y sus propiedades, en función de los parámetros de consulta.
- Proporcionar resultados de previsiones y detección de anomalías en tiempo real. Es decir, en cuestión de segundos, detecta tendencias y estacionalidad en todas las series temporales y decide si alguna de las porciones está aumentando o disminuyendo de forma inesperada.
Funciones de la API
- Gestionar conjuntos de datos
- Indexa y carga conjuntos de datos formados por varias fuentes de datos almacenados en Cloud Storage. Permite añadir eventos nuevos de forma continua.
- Descarga un conjunto de datos que ya no necesites.
- Solicita el estado del proceso de un conjunto de datos.
- Consultar conjuntos de datos
- Obtiene la serie temporal que coincide con los valores de propiedad proporcionados. La serie temporal se pronostica hasta un horizonte temporal especificado. También se evalúan las series temporales para detectar anomalías.
- Detecta automáticamente combinaciones de valores de propiedades para detectar anomalías.
- Actualizar conjuntos de datos
- Ingiere los eventos nuevos que se han producido recientemente y los incorpora al índice casi en tiempo real (con un retraso de segundos o minutos).
Recuperación tras fallos
La API Timeseries Insights no sirve como copia de seguridad de Cloud Storage ni devuelve actualizaciones de streaming sin procesar. Los clientes son responsables de almacenar y crear copias de seguridad de los datos por separado.
Después de una interrupción regional, el servicio hace todo lo posible para recuperarse. Es posible que no se recuperen los metadatos (información sobre el conjunto de datos y el estado operativo) y los datos de usuario transmitidos que se hayan actualizado en las 24 horas posteriores al inicio de la interrupción.
Durante la recuperación, es posible que no estén disponibles las consultas ni las actualizaciones de streaming de los conjuntos de datos.
Datos de entrada
Es habitual que se recojan datos numéricos y categóricos a lo largo del tiempo. Por ejemplo, la siguiente figura muestra el uso de la CPU, el uso de la memoria y el estado de una sola tarea en ejecución en un centro de datos cada minuto durante un periodo determinado. El uso de CPU y el uso de memoria son valores numéricos, y el estado es un valor categórico.
Evento
La API Timeseries Insights usa eventos como entrada de datos básica. Cada evento tiene una marca de tiempo y una colección de dimensiones, es decir, pares clave-valor en los que la clave es el nombre de la dimensión. Esta sencilla representación nos permite gestionar datos a escala de billones. Por ejemplo, se incluyen el centro de datos, el usuario, los nombres de los trabajos y los números de las tareas para representar completamente un solo evento. En la figura anterior se muestra una serie de eventos registrados para un único trabajo que ilustra un subconjunto de dimensiones.
{"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"}
DataSet
Un DataSet es una colección de eventos. Las consultas se realizan en el mismo conjunto de datos. Cada proyecto puede tener varios conjuntos de datos.
Un conjunto de datos se crea a partir de datos de streaming y por lotes. La compilación de datos por lotes lee datos de varios URIs de Cloud Storage como fuentes de datos. Una vez que se haya completado la compilación por lotes, el conjunto de datos se puede actualizar con datos de streaming. Si se usa 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 para poder consultarlo o actualizarlo. La indexación empieza cuando se crea el conjunto de datos y suele tardar entre unos minutos y varias horas en completarse, en función de la cantidad de datos. En concreto, las fuentes de datos se analizan una vez durante la indexación inicial. Si el contenido de los URIs de Cloud Storage cambia una vez completada la indexación inicial, no se vuelve a analizar. Usa actualizaciones de streaming para obtener datos adicionales. Las actualizaciones de streaming se indexan continuamente y casi en tiempo real.
Series temporales y detección de anomalías
En la API Timeseries Insights, una sección es una colección de eventos con una combinación determinada de valores de dimensión. Nos interesa medir los eventos que se incluyen en estos segmentos a lo largo del tiempo.
En una porción determinada, los eventos se agregan en valores numéricos por resolución de intervalos de tiempo especificada por el usuario, que son las series temporales para detectar anomalías. En la figura anterior se muestran diferentes opciones de segmentación que se han obtenido a partir de distintas combinaciones de las dimensiones "user", "job" y "data_center".
Se produce una anomalía en un determinado segmento si el valor numérico del intervalo de tiempo de interés es significativamente diferente de los valores anteriores. La figura de arriba muestra una serie temporal basada en las temperaturas medidas en todo el mundo durante 10 años. Supongamos que queremos saber si el último mes del 2015 es una anomalía. Una consulta al sistema especifica el periodo de interés, detectionTime
, como "2015/12/01" y el granularity
como "1 month" (1 mes). La serie temporal obtenida antes del detectionTime
se divide en un periodo de entrenamiento anterior y un periodo de retención. El sistema usa los datos del periodo de entrenamiento para entrenar un modelo y el periodo de retención para verificar que el modelo puede predecir de forma fiable los valores siguientes. En este ejemplo, el periodo de retención es de 1 año. En la imagen se muestran los datos reales y los valores predichos del modelo, así como los límites superior e inferior. La temperatura de diciembre del 2015 se marca como anomalía porque el valor real está fuera de los límites previstos.
Siguientes pasos
- API Timeseries Insights Conceptos
- Un tutorial más detallado
- Más información sobre la API REST