Descripción general

Introducción

La previsión y la detección de anomalías en miles de millones de series temporales son intensivos en términos de procesamiento. La mayoría de los sistemas existentes ejecutan la previsión y la detección de anomalías como trabajos por lotes (por ejemplo, canalizaciones de riesgo, previsión del tráfico, planificación de demanda, etcétera). Esto limita en gran medida el tipo de análisis que puedes realizar en línea, como decidir si activar una alerta en función de un aumento o una disminución repentinos en un conjunto de dimensiones de eventos.

Los objetivos principales de la API de Timeseries Insights son los siguientes:

  • Escala a miles de millones de series temporales que se crean de forma dinámica a partir de eventos sin procesar y sus propiedades, en función de los parámetros de consulta.
  • Proporciona resultados de previsión y detección de anomalías en tiempo real. Es decir, en pocos segundos, detecta las tendencias y la estacionalidad en todas las series temporales y decide si algunas porciones aumentan o disminuyen de forma inesperada.

Funcionalidad de la API

  • Administrar conjuntos de datos
    • Indexar y cargar un conjunto de datos que consta de varias fuentes de datos almacenadas en Cloud Storage. Permite agregar nuevos eventos de forma de transmisión.
    • Descarga un conjunto de datos que ya no necesites.
    • Solicitar el estado de procesamiento de un conjunto de datos
  • Consultar conjuntos de datos
    • Recupera las series temporales que coinciden con los valores de propiedad determinados. Las series temporales se prevén hasta un horizonte de tiempo específico. Las series temporales también se evalúan para detectar anomalías.
    • Detecta automáticamente combinaciones de valores de propiedades para anomalías.
  • Actualiza los conjuntos de datos.
    • La transferencia de eventos nuevos ocurrieron recientemente y, luego, los incorpora al índice casi en tiempo real (de segundos a minutos de retraso).

Recuperación ante desastres

La API de Timeseries Insights no sirve como copia de seguridad para Cloud Storage ni muestra actualizaciones de transmisión sin procesar. Los clientes son responsables de almacenar y crear una copia de seguridad de los datos por separado.

Después de una interrupción regional, el servicio realiza la mejor recuperación de esfuerzo. Es posible que los metadatos (información sobre el conjunto de datos y el estado operativo) y los datos del usuario transmitidos se actualicen dentro de las 24 horas del inicio de la interrupción.

Durante la recuperación, es posible que las consultas y las actualizaciones de transmisión a los conjuntos de datos no estén disponibles.

Datos de entrada

Es común que los datos numéricos y categóricos se recopilen con el tiempo. Por ejemplo, en la siguiente figura, se muestra el uso de CPU, el uso de memoria y el estado de un solo trabajo en ejecución en un centro de datos por cada minuto durante un período. El uso de CPU y el uso de memoria son valores numéricos, y el estado es un valor categórico.

Timeseries

Evento

La API de Timeseries Insights usa eventos como la entrada de datos básicos. 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 representación simple nos permite controlar los datos en una 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 por completo un solo evento. En la figura anterior, se muestra una serie de eventos registrados para un solo trabajo que ilustran 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 dentro del mismo conjunto de datos. Cada proyecto puede tener varios conjuntos de datos.

Un conjunto de datos se crea a partir de datos por lotes y de transmisión. La compilación de datos por lotes lee de 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. Con la compilación por lotes para datos históricos, el sistema puede evitar problemas de inicio en frío.

Un conjunto de datos se debe crear o indexar antes de que se lo pueda consultar o actualizar. La indexación comienza cuando se crea el conjunto de datos y, por lo general, tarda de minutos a horas en completarse, según la cantidad de datos. Más específicamente, las fuentes de datos se analizan una vez durante la indexación inicial. Si el contenido de los URI de Cloud Storage cambia después de que se completa la indexación inicial, no se vuelven a analizar. Usa actualizaciones de transmisión para datos adicionales. Las actualizaciones de transmisión se indexan de forma continua y casi en tiempo real.

Series temporales y detección de anomalías

Porciones

Para la API de Timeseries Insights, una porción es una colección de eventos con una combinación determinada de valores de dimensión. Nos interesa una medición de los eventos que corresponden a estas porciones a lo largo del tiempo.

Para 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 ilustran diferentes opciones de porciones como resultado de distintas combinaciones de las dimensiones “user”, “job” y “data_center”.

Series temporales y anomalías

Una anomalía ocurre para una porción determinada si el valor numérico del intervalo de tiempo de interés es significativamente diferente de los valores del pasado. En la figura anterior, se ilustra una serie temporal basada en temperaturas medidas en todo el mundo durante 10 años. Supongamos que queremos saber si el último mes de 2015 es una anomalía. Una consulta al sistema especifica que la hora de interés, detectionTime, será "2015/12/01" y la granularity, "1 mes". Las series temporales recuperadas antes de detectionTime se particionan en un período de entrenamiento anterior seguido de un período de exclusión. El sistema usa datos del período de entrenamiento para entrenar un modelo y usa el período de exclusión para verificar que el modelo pueda predecir de manera confiable los siguientes valores. Para este ejemplo, el período de retención es de 1 año. La imagen muestra los datos reales y los valores previstos del modelo con límites inferiores y superiores. La temperatura para 2015/2012 se marcó como una anomalía porque el valor real está fuera de los límites previstos.

¿Qué sigue?