Introduction
La prévision et la détection d'anomalies sur des milliards de séries temporelles nécessitent beaucoup de ressources de calcul. La plupart des systèmes existants exécutent les prévisions et la détection d'anomalies en tant que tâches par lot (par exemple, pipelines de risque, prévision du trafic, planification de la demande, etc.). Cela limite fortement le type d'analyse que vous pouvez effectuer en ligne, comme décider d'envoyer une alerte en cas d'augmentation ou de diminution soudaines d'un ensemble de dimensions d'événement.
Les principaux objectifs de l'API Timeseries Insights sont les suivants:
- Répondez à des milliards de séries temporelles construites de manière dynamique à partir d'événements bruts et de leurs propriétés, en fonction des paramètres de requête.
- fournir des résultats de prévision et de détection d'anomalies en temps réel ; Autrement dit, en quelques secondes, détectez les tendances et la saisonnalité de toutes les séries temporelles, puis décidez si des tranches augmentent ou diminuent de manière inattendue.
Fonctionnement de l'API
- Gérer les ensembles de données
- d'indexer et de charger un ensemble de données constitué de plusieurs sources de données stockées dans Cloud Storage ; Autoriser l'ajout de nouveaux événements en streaming
- Déchargez un ensemble de données dont vous n'avez plus besoin.
- Demander l'état du traitement d'un ensemble de données
- Interrogez des ensembles de données.
- Récupérez la série temporelle correspondant aux valeurs de propriété données. La série temporelle est prévue jusqu'à un horizon temporel spécifié. La série temporelle est également évaluée à la recherche d'anomalies.
- Détectez automatiquement des combinaisons de valeurs de propriétés pour les anomalies.
- Mettre à jour des ensembles de données
- Ingérez les nouveaux événements récemment survenus et intégrez-les à l'index en temps quasi réel (délai de quelques secondes à quelques minutes).
Reprise après sinistre
L'API Timeseries Insights ne sert pas de sauvegarde pour Cloud Storage et ne renvoie pas de mises à jour brutes par flux. Les clients sont tenus de stocker et de sauvegarder les données séparément.
Après une panne régionale, le service effectue une récupération au mieux. Il est possible que les métadonnées (informations sur l'ensemble de données et l'état opérationnel) et les données utilisateur en flux continu mises à jour dans les 24 heures suivant le début de l'indisponibilité ne soient pas récupérées.
Pendant la récupération, les requêtes et les mises à jour en flux continu des ensembles de données peuvent ne pas être disponibles.
Données d'entrée
Il est courant que les données numériques et catégorielles soient collectées au fil du temps. Par exemple, la figure suivante montre l'utilisation du processeur, l'utilisation de la mémoire et l'état d'une tâche en cours d'exécution dans un centre de données pour chaque minute sur une période donnée. L'utilisation du processeur et de la mémoire sont des valeurs numériques, et l'état est une valeur catégorielle.
Événement
L'API Timeseries Insights utilise des événements comme entrée de données de base. Chaque événement est associé à un horodatage et à une collection de dimensions, c'est-à-dire des paires clé/valeur où la clé correspond au nom de la dimension. Cette représentation simple nous permet de traiter des données à l'échelle de milliers de milliards. Par exemple, le centre de données, l'utilisateur, les noms des tâches et les numéros de tâche sont inclus pour représenter entièrement un seul événement. La figure ci-dessus montre une série d'événements enregistrés pour une seule tâche et illustre un sous-ensemble de dimensions.
{"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 est une collection d'événements. Les requêtes sont effectuées dans le même ensemble de données. Chaque projet peut comporter plusieurs ensembles de données.
Un ensemble de données est créé à partir de données par lot et par flux. Les builds de données par lot se basent sur plusieurs URI Cloud Storage en tant que sources de données. Une fois la compilation par lot terminée, l'ensemble de données peut être mis à jour avec des données en flux continu. En utilisant la compilation par lot pour les données historiques, le système peut éviter les problèmes de démarrage à froid.
Un ensemble de données doit être créé ou indexé avant de pouvoir être interrogé ou mis à jour. L'indexation commence dès la création de l'ensemble de données et prend généralement quelques minutes, voire plusieurs heures, selon la quantité de données. Plus précisément, les sources de données sont analysées une seule fois lors de l'indexation initiale. Si le contenu des URI Cloud Storage change une fois l'indexation initiale terminée, ils ne sont pas analysés à nouveau. Utilisez les mises à jour en streaming pour obtenir des données supplémentaires. Les mises à jour en flux continu sont indexées en permanence, quasiment en temps réel.
Détection de séries temporelles et d'anomalies
Pour l'API Timeseries Insights, une tranche est une collection d'événements présentant une combinaison spécifique de valeurs de dimension. Nous souhaitons connaître la mesure des événements qui tombent dans ces segments au fil du temps.
Pour une tranche donnée, les événements sont agrégés en valeurs numériques par résolution d'intervalles de temps spécifiée par l'utilisateur. Il s'agit de séries temporelles permettant de détecter les anomalies. La figure précédente illustre différents choix de tranches résultant de différentes combinaisons de dimensions "utilisateur", "tâche" et "centre de données".
Une anomalie se produit pour une tranche donnée si la valeur numérique de l'intervalle de temps d'intérêt est très différente des valeurs du passé. La figure ci-dessus illustre une série temporelle basée sur des températures mesurées à travers le monde pendant 10 ans. Supposons que nous nous demandions
si le dernier mois de 2015 présente une anomalie. Une requête envoyée au système spécifie que la date et l'heure de l'intérêt sont "2015/12/01" (detectionTime) et "1 month" (1 mois) pour granularity. La série temporelle récupérée avant detectionTime est partitionnée dans une période d'entraînement antérieure suivie d'une période de holdout. Le système utilise les données de la période d'entraînement pour entraîner un modèle, puis utilise la période d'attente pour vérifier que le modèle peut prédire de manière fiable les valeurs suivantes. Dans cet exemple, la période d'attente est de 1 an. L'image montre les données réelles et les valeurs prédites du modèle avec les limites supérieure et inférieure. La température pour 2015/12 est marquée d'une anomalie, car la valeur réelle se situe en dehors des limites prévues.