Panoramica

Introduzione

Le previsioni e il rilevamento di anomalie in miliardi di serie temporali sono ad alta intensità di calcolo. La maggior parte dei sistemi esistenti esegue previsioni e anomalie il rilevamento come job batch (ad esempio, pipeline di rischio, previsione del traffico, pianificazione della domanda e così via). Questo limita notevolmente il tipo di analisi che può funzionare online, ad esempio decidendo se inviare un avviso in base a un aumento improvviso o diminuisci in un insieme di dimensioni degli eventi.

Gli obiettivi principali dell'API Timeseries Insights sono:

• Scala fino a miliardi di serie temporali create dinamicamente da dati non elaborati e relative proprietà, in base ai parametri di ricerca.
• Fornisce risultati di previsioni e rilevamento di anomalie in tempo reale. Vale a dire che in pochi secondi, rilevare tendenze e stagionalità in tutte le serie temporali e decidi se le sezioni aumentano o diminuiscono inaspettatamente.

Funzionalità dell'API

• Gestisci i set di dati
  • Indicizzare e caricare un set di dati composto da più origini dati archiviate su Cloud Storage. Consenti l'aggiunta di nuovi eventi in modalità streaming.
  • Esegui l'unload di un set di dati non più necessario.
  • Chiedi lo stato di elaborazione di un set di dati.
• Esegui query su set di dati
  • Recupera le serie temporali corrispondenti ai valori specificati delle proprietà. La serie temporale viene prevista fino a un orizzonte temporale specificato. Anche la serie temporale viene valutata per rilevare eventuali anomalie.
  • Rileva automaticamente combinazioni di valori delle proprietà per rilevare 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 di ritardo).

Ripristino di emergenza

L'API Timeseries Insights non funge da backup per Cloud Storage o restituire aggiornamenti di flussi di dati non elaborati. I clienti sono responsabili dell'archiviazione e del backup dei dati separatamente.

Dopo un'interruzione a livello di regione, il servizio esegue il recupero ottimale. Metadati (informazioni su set di dati e stato operativo) e streaming dell'utente i dati aggiornati entro 24 ore dall'inizio dell'interruzione potrebbero non da recuperare.

Durante il ripristino, le query e gli aggiornamenti in streaming ai set di dati potrebbero non disponibili.

Dati di input

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

Evento

L'API Timeseries Insights utilizza gli eventi come immissione 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 i dati miliardi di dollari. Ad esempio data center, utente, nomi dei job e vengono inclusi i numeri che rappresentano interamente un singolo evento. La figura sopra mostra una serie di eventi registrati per un singolo job che illustra 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 in flussi. Letture di build dei dati in batch da più URI Cloud Storage come origini dati. Al termine della creazione batch, è possibile aggiornare il set di dati con flussi di dati. Utilizzando la compilazione batch per i dati storici, il sistema può evitare i problemi di avvio a freddo.

Un set di dati deve essere creato o indicizzato prima di poter eseguire query o aggiornarlo. L'indicizzazione inizia quando viene creato il set di dati e in genere richiede alcuni minuti ore da completare, a seconda della quantità di dati. In particolare, le origini dati vengono scansionate una volta durante l'indicizzazione iniziale. Se i contenuti gli URI Cloud Storage cambiano dopo il completamento dell'indicizzazione iniziale, non nuova scansione. Utilizza gli aggiornamenti in modalità flusso per dati aggiuntivi. Aggiornamenti in streaming vengono indicizzati in modo continuo quasi in tempo reale.

Nota: l'API Timeseries Insights non può restituire gli aggiornamenti in streaming non elaborati, pertanto i clienti devono archiviare questi dati separatamente se sono necessari.

Nota: i dati in streaming dovrebbero avere timestamp non troppo lontani dal tempo reale, pertanto gli aggiornamenti in streaming non possono essere utilizzati per aggiungere in modo incrementale i dati storici.

Rilevamento di serie temporali e anomalie

Per l'API Timeseries Insights, un sezionamento è una raccolta di eventi con una determinata combinazione di valori delle dimensioni. Siamo interessati a misurare gli eventi che rientrano in questi intervalli nel tempo.

Per un determinato intervallo, gli eventi vengono aggregati in valori numerici in base alla risoluzione specificata dall'utente degli intervalli di tempo, ovvero le serie temporali per rilevare le anomalie. La figura precedente mostra diverse scelte di slice risultanti da diverse combinazioni delle dimensioni "user", "job" e "data_center".

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 la figura sopra illustra una serie temporale basata sulle temperature misurate attraverso del mondo in 10 anni. Supponiamo di voler sapere se nell'ultimo mese Il 2015 è un'anomalia. Una query al sistema specifica l'ora di interesse, detectionTime, da essere "01/12/2015" e granularity in modo che sia "1 mese". La serie temporale recuperata prima che detectionTime sia partizionato in una precedente di addestramento seguito da un periodo di holdout. Il sistema utilizza i dati provenienti il periodo di addestramento per addestrare un modello e utilizza il periodo di holdout per verificare il modello può prevedere in modo affidabile i valori successivi. Per questo esempio, l'holdout è di 1 anno. L'immagine mostra i dati effettivi e i valori previsti da del modello con i limiti superiore e inferiore. La temperatura per il 2015/12 è contrassegnata un'anomalia perché il valore effettivo non rientra nei limiti previsti.

Passaggi successivi

• Concetti dell'API Timeseries Insights
• Un tutorial più dettagliato
• Scopri di più sull'API REST