Überblick

Einführung

Prognosen und Anomalieerkennung über Milliarden von Zeitachsen hinweg sind rechenintensiv. Die meisten vorhandenen Systeme führen Prognosen und Anomalieerkennung als Batchjobs aus (z. B. Risikopipelines, Traffic-Prognosen, Bedarfsplanung usw.). Dies schränkt die Art der Online-Analyse stark ein, z. B. ob bei einem plötzlichen Anstieg oder Abfall einer Reihe von Ereignisdimensionen eine Benachrichtigung erfolgen soll.

Die wichtigsten Ziele der Timeseries Insights API sind:

  • Skalieren Sie auf Milliarden von Zeitachsen, die dynamisch aus Rohereignissen und ihren Attributen basierend auf Abfrageparametern erstellt werden.
  • Erstellen Sie Prognosen in Echtzeit und Ergebnisse zur Anomalieerkennung. Das heißt, innerhalb weniger Sekunden Trends und Saisonabhängigkeiten über alle Zeitreihen hinweg erkennen und entscheiden, ob Segmente unerwartet ansteigen oder abnehmen.

API-Funktionen

  • Datasets verwalten
    • Indexieren und laden Sie ein Dataset, das aus mehreren in Cloud Storage gespeicherten Datenquellen besteht. Zulassen, dass neue Termine gestreamt werden
    • Nicht mehr benötigtes Dataset entladen
    • Nach dem Verarbeitungsstatus eines Datasets fragen.
  • Datasets abfragen
    • Ruft die Zeitreihe ab, die mit den angegebenen Attributwerten übereinstimmt. Die Zeitachse wird bis zu einem bestimmten Zeitraum prognostiziert. Die Zeitachse wird auch auf Anomalien bewertet.
    • Kombinationen von Property-Werten für Anomalien werden automatisch erkannt.
  • Datasets aktualisieren
    • Nehmen Sie kürzlich aufgetretene neue Ereignisse auf und nehmen Sie sie nahezu in Echtzeit in den Index auf (Verzögerung von Sekunden bis Minuten).

Notfallwiederherstellung

Die Timeseries Insights API dient nicht als Sicherung für Cloud Storage und gibt keine unbearbeiteten Streamingaktualisierungen zurück. Clients sind dafür verantwortlich, Daten getrennt zu speichern und zu sichern.

Nach einem regionalen Ausfall führt der Dienst eine Best-Effort-Wiederherstellung durch. Metadaten (Informationen über Dataset und Betriebsstatus) und gestreamte Nutzerdaten, die innerhalb von 24 Stunden nach Beginn des Ausfalls aktualisiert werden, können möglicherweise nicht wiederhergestellt werden.

Während der Wiederherstellung sind Abfragen und Streamingaktualisierungen für Datasets möglicherweise nicht verfügbar.

Eingabedaten

Häufig werden numerische und kategoriale Daten im Laufe der Zeit gesammelt. Die folgende Abbildung zeigt beispielsweise die CPU-Auslastung, die Arbeitsspeichernutzung und den Status eines einzelnen ausgeführten Jobs in einem Rechenzentrum für jede Minute über einen bestimmten Zeitraum. Die CPU- und Speichernutzung sind numerische Werte. Der Status ist ein kategorialer Wert.

Zeitachse

Ereignis

In der Timeseries Insights API werden Ereignisse als grundlegende Dateneingabe verwendet. Jedes Ereignis hat einen Zeitstempel und eine Sammlung von Dimensionen, d. h. Schlüssel/Wert-Paare, bei denen der Schlüssel der Dimensionsname ist. Mit dieser einfachen Darstellung können wir Daten im Billionenbereich verarbeiten. Zum Beispiel sind das Rechenzentrum, der Nutzer, die Jobnamen und die Aufgabennummern enthalten, um ein einzelnes Ereignis vollständig darzustellen. Die Abbildung oben zeigt eine Reihe von Ereignissen, die für einen einzelnen Auftrag erfasst wurden, und veranschaulicht einen Teil der Dimensionen.

{"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

Ein DataSet ist eine Sammlung von Ereignissen. Abfragen werden innerhalb desselben Datasets ausgeführt. Jedes Projekt kann mehrere Datasets enthalten.

Ein Dataset besteht aus Batch- und Streamingdaten. Batchdaten-Builds liest aus mehreren Cloud Storage-URIs als Datenquellen. Nach Abschluss des Batch-Builds kann das Dataset mit Streamingdaten aktualisiert werden. Durch die Verwendung von Batch-Builds für Verlaufsdaten kann das System Kaltstartprobleme vermeiden.

Ein Dataset muss erstellt oder indexiert werden, bevor es abgefragt oder aktualisiert werden kann. Die Indexierung beginnt mit der Erstellung des Datasets und dauert je nach Datenmenge in der Regel einige Minuten bis Stunden. Genauer gesagt werden die Datenquellen einmal während der ersten Indexierung gescannt. Wenn sich der Inhalt der Cloud Storage-URIs nach Abschluss der ersten Indexierung ändert, werden sie nicht noch einmal gescannt. Verwenden Sie Streaming-Updates für zusätzliche Daten. Streaming-Updates werden kontinuierlich und nahezu in Echtzeit indexiert.

Zeitreihen und Anomalieerkennung

Slices

Bei der Timeseries Insights API ist ein Slice eine Sammlung von Ereignissen mit einer bestimmten Kombination von Dimensionswerten. Wir interessieren uns für ein Maß der Ereignisse, die im Laufe der Zeit in diese Segmente fallen.

Für ein bestimmtes Slice werden die Ereignisse zu numerischen Werten pro benutzerspezifischer Auflösung von Zeitintervallen zusammengefasst. Dies sind die Zeitachsen zur Erkennung von Anomalien. Die obige Abbildung zeigt verschiedene Auswahlmöglichkeiten für Segmente, die sich aus verschiedenen Kombinationen von „user“-, „job“- und „data_center“-Dimensionen ergeben.

Zeitreihen und Anomalien

Eine Anomalie tritt für einen bestimmten Abschnitt auf, wenn der numerische Wert aus dem relevanten Zeitintervall deutlich von den Werten in der Vergangenheit abweicht. Die Abbildung oben zeigt eine Zeitachse, die auf Temperaturen basiert, die weltweit über 10 Jahre gemessen wurden. Angenommen, wir möchten herausfinden, ob der letzte Monat 2015 eine Anomalie ist. Durch eine Abfrage an das System wird der relevante Zeitpunkt (detectionTime) auf „01.12.2015“ und der Wert für granularity auf „1 Monat“ festgelegt. Die vor dem detectionTime abgerufene Zeitachse wird in einen früheren Trainingszeitraum partitioniert, gefolgt von einem Holdout-Zeitraum. Das System verwendet Daten aus der Trainingsphase, um ein Modell zu trainieren, und prüft anhand des Holdout-Zeitraums, ob das Modell die nächsten Werte zuverlässig vorhersagen kann. In diesem Beispiel beträgt der Holdout-Zeitraum 1 Jahr. Das Bild zeigt die tatsächlichen Daten und vorhergesagten Werte aus dem Modell mit Ober- und Untergrenzen. Die Temperatur für 2015/12 ist als Anomalie markiert, da der tatsächliche Wert außerhalb der vorhergesagten Grenzen liegt.

Nächste Schritte