Panoramica

Introduzione

Le previsioni e il rilevamento di anomalie in miliardi di serie temporali richiedono un uso intensivo del calcolo. La maggior parte dei sistemi esistenti esegue previsioni e rilevamento di anomalie come job batch (ad esempio pipeline di rischio, previsione del traffico, pianificazione della domanda e così via). Ciò limita drasticamente il tipo di analisi che puoi eseguire online, ad esempio decidere se avvisare in base a un aumento improvviso o a una diminuzione in un insieme di dimensioni evento.

Gli obiettivi principali dell'API Timeseries Insights sono:

  • Scala fino a miliardi di serie temporali create dinamicamente a partire da eventi non elaborati e dalle relative proprietà in base ai parametri di ricerca.
  • Fornisce previsioni in tempo reale e risultati del rilevamento di anomalie. In altre parole, in pochi secondi, rileva tendenze e stagionalità in tutte le serie temporali e decidi se le sezioni sono in aumento o in calo inaspettatamente.

Funzionalità dell'API

  • Gestisci i set di dati
    • Indicizzare e caricare un set di dati composto da più origini dati archiviate in Cloud Storage. Consenti l'aggiunta di nuovi eventi in modalità streaming.
    • Annulla il caricamento di un set di dati non più necessario.
    • Chiedi lo stato di elaborazione di un set di dati.
  • Query sui set di dati
    • Recupera la serie temporale che corrisponde ai valori della proprietà specificati. La serie temporale viene prevista fino a un determinato orizzonte temporale. Le serie temporali vengono valutate anche per individuare eventuali anomalie.
    • Rileva automaticamente le combinazioni di valori delle proprietà per le anomalie.
  • Aggiorna i set di dati
    • Importa i nuovi eventi che si sono verificati di recente e incorporali nell'indice quasi in tempo reale (da secondi a minuti).

Ripristino di emergenza

L'API Timeseries Insights non funge da backup per Cloud Storage e non restituisce aggiornamenti dei flussi di dati non elaborati. I client sono responsabili di archiviare e fare il backup dei dati separatamente.

Dopo un'interruzione regionale, il servizio esegue un ripristino del tipo "best effort". I metadati (informazioni sul set di dati e sullo stato operativo) e i flussi di dati utente aggiornati entro 24 ore dall'inizio dell'interruzione potrebbero non essere recuperati.

Durante il ripristino, le query e gli aggiornamenti dei flussi di dati potrebbero non essere disponibili.

Dati di input

È normale che nel tempo vengano raccolti dati numerici e categorici. Ad esempio, la figura seguente mostra l'utilizzo della CPU, l'utilizzo della memoria e lo stato di un singolo job in esecuzione in un data center per ogni minuto in un periodo di tempo. L'utilizzo della CPU e l'utilizzo della memoria sono valori numerici, mentre lo stato è un valore categorico.

Timeseries

Evento

L'API Timeseries Insights utilizza gli eventi come voce di dati di base. Ogni evento ha un timestamp e una raccolta di dimensioni, ovvero coppie chiave-valore in cui la chiave è il nome della dimensione. Questa semplice rappresentazione ci consente di gestire dati su una scala di miliardi. Ad esempio, il data center, gli utenti, i nomi dei job e i numeri delle attività sono inclusi per rappresentare in modo completo un singolo evento. La figura sopra mostra una serie di eventi registrati per un singolo job che illustrano un sottoinsieme di dimensioni.

{"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 è una raccolta di eventi. Le query vengono eseguite all'interno dello stesso set di dati. Ogni progetto può avere più set di dati.

Un set di dati viene creato a partire da dati in batch e flussi. La creazione di dati in batch legge più URI Cloud Storage come origini dati. Una volta completata la build batch, il set di dati può essere aggiornato con i flussi di dati. Usando la build batch per i dati storici, il sistema può evitare problemi di avvio a freddo.

Un set di dati deve essere creato o indicizzato prima di poter essere sottoposto a query o aggiornato. L'indicizzazione inizia quando viene creato il set di dati e in genere richiede da pochi minuti a diverse ore, a seconda della quantità di dati. In particolare, le origini dati vengono analizzate una volta durante l'indicizzazione iniziale. Se i contenuti degli URI di Cloud Storage cambiano dopo il completamento dell'indicizzazione iniziale, non verranno scansionati di nuovo. Utilizza gli aggiornamenti dei flussi di dati per dati aggiuntivi. Gli aggiornamenti dei flussi di dati vengono indicizzati continuamente, quasi in tempo reale.

Rilevamento di serie temporali e anomalie

Sezioni

Per l'API Timeseries Insights, una sezione è una raccolta di eventi con una determinata combinazione di valori di dimensione. Vogliamo misurare gli eventi che rientrano in questi gruppi nel tempo.

Per una determinata sezione, gli eventi vengono aggregati in valori numerici per la risoluzione degli intervalli di tempo specificata dall'utente, che rappresentano le serie temporali per rilevare le anomalie. La figura precedente illustra le diverse scelte delle sezioni derivanti da diverse combinazioni di dimensioni "user", "job" e "data_center".

Serie temporali e anomalie

Un'anomalia si verifica per una determinata sezione se il valore numerico dell'intervallo di tempo di interesse è nettamente diverso dai valori del passato. La figura sopra mostra una serie temporale basata sulle temperature misurate nel mondo nell'arco di 10 anni. Supponiamo che ci interessi sapere se l'ultimo mese del 2015 è un'anomalia. Una query al sistema specifica che il tempo di interesse, detectionTime, è "01/12/2015" e il granularity deve essere "1 mese". La serie temporale recuperata prima di detectionTime viene partizionata in un periodo di addestramento precedente seguito da un periodo di holdout. Il sistema utilizza i dati del periodo di addestramento per addestrare un modello e il periodo di holdout per verificare che il modello possa prevedere in modo affidabile i valori successivi. Per questo esempio, il periodo di attesa è di 1 anno. L'immagine mostra i dati effettivi e i valori previsti dal modello, con i limiti superiore e inferiore. La temperatura per il periodo 2015/12 è contrassegnata da un'anomalia perché il valore effettivo non rientra nei limiti previsti.

Passaggi successivi