Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Concetti di interrogazione pian
Stringa di interrogazione: questa è la query di cui state precalcolando e memorizzando il risultato in un altro Timestream per tabella. LiveAnalytics È possibile definire un'interrogazione pianificata utilizzando l'intera SQL area di Timestream for LiveAnalytics, che offre la flessibilità di scrivere query con espressioni di tabella comuni, query annidate, funzioni di finestra o qualsiasi tipo di funzione aggregata e scalare supportata da Timestream per il linguaggio di query. LiveAnalytics
Espressione di pianificazione: consente di specificare quando vengono eseguite le istanze di query pianificate. È possibile specificare le espressioni utilizzando un'espressione cron (ad esempio, esegui alle 8:00 UTC ogni giorno) o un'espressione di frequenza (come esegui ogni 10 minuti).
Configurazione della destinazione: consente di specificare come mappare il risultato di una query pianificata nella tabella di destinazione in cui verranno archiviati i risultati di questa query pianificata.
Configurazione delle notifiche: Timestream for esegue LiveAnalytics automaticamente le istanze di una query pianificata in base all'espressione di pianificazione. Riceverai una notifica per ogni interrogazione di questo tipo eseguita su un SNS argomento che configuri quando crei un'interrogazione pianificata. Questa notifica specifica se l'istanza è stata eseguita correttamente o se si sono verificati errori. Inoltre, fornisce informazioni come i byte misurati, i dati scritti nella tabella di destinazione, l'ora di chiamata successiva e così via.
Di seguito è riportato un esempio di questo tipo di messaggio di notifica.
{ "type":"AUTO_TRIGGER_SUCCESS", "arn":"arn:aws:timestream:us-east-1:123456789012:scheduled-query/ PT1mPerMinutePerRegionMeasureCount-9376096f7309", "nextInvocationEpochSecond":1637302500, "scheduledQueryRunSummary": { "invocationEpochSecond":1637302440, "triggerTimeMillis":1637302445697, "runStatus":"AUTO_TRIGGER_SUCCESS", "executionStats": { "executionTimeInMillis":21669, "dataWrites":36864, "bytesMetered":13547036820, "recordsIngested":1200, "queryResultRows":1200 } } }
In questo messaggio di notifica, bytesMetered
sono i byte scansionati dalla query nella tabella di origine e dataWrites i byte scritti nella tabella di destinazione.
Nota
Se utilizzi queste notifiche a livello di codice, tieni presente che in futuro potrebbero essere aggiunti nuovi campi al messaggio di notifica.
Posizione del rapporto di errore: le query pianificate vengono eseguite in modo asincrono e memorizzano i dati nella tabella di destinazione. Se un'istanza rileva errori (ad esempio dati non validi che non è stato possibile archiviare), i record in cui si sono verificati errori vengono scritti in un report di errore nella posizione specificata al momento della creazione di una query pianificata. Devi specificare il bucket S3 e il prefisso per la posizione. Timestream for LiveAnalytics aggiunge il nome della query pianificata e l'ora di invocazione a questo prefisso per aiutarti a identificare gli errori associati a un'istanza specifica di una query pianificata.
Etichettatura: è possibile specificare facoltativamente tag da associare a una query pianificata. Per maggiori dettagli, consulta Tagging Timestream for Resources. LiveAnalytics
Esempio
Nell'esempio seguente, si calcola un aggregato semplice utilizzando una query pianificata:
SELECT region, bin(time, 1m) as minute, SUM(CASE WHEN measure_name = 'metrics' THEN 20 ELSE 5 END) as numDataPoints FROM raw_data.devops WHERE time BETWEEN @scheduled_runtime - 10m AND @scheduled_runtime + 1m GROUP BY bin(time, 1m), region
@scheduled_runtime parameter
- In questo esempio, noterai che la query accetta uno speciale parametro denominato. @scheduled_runtime
Si tratta di un parametro speciale (di tipo Timestamp) che il servizio imposta quando richiama un'istanza specifica di una query pianificata in modo da poter controllare in modo deterministico l'intervallo di tempo per il quale un'istanza specifica di una query pianificata analizza i dati nella tabella di origine. Puoi utilizzarlo @scheduled_runtime
nella tua query in qualsiasi posizione in cui è previsto un tipo di timestamp.
Consideriamo un esempio in cui si imposta un'espressione di pianificazione: cron (0/5 * * *? *) dove la query pianificata verrà eseguita al minuto 0, 5, 10, 15, 20, 25, 30, 35, 40, 45, 50, 55 di ogni ora. Per l'istanza attivata il 2021-12-01 00:05:00, il parametro @scheduled_runtime viene inizializzato su questo valore, in modo che l'istanza in questo momento operi su dati compresi tra 2021-11-30 23:55:00 e 2021-12-01 00:06:00.
Istanze con intervalli di tempo sovrapposti: come vedrai in questo esempio, due istanze successive di una query pianificata possono sovrapporsi nei rispettivi intervalli di tempo. Questo è qualcosa che puoi controllare in base ai tuoi requisiti, ai predicati temporali specificati e all'espressione di pianificazione. In questo caso, questa sovrapposizione consente a questi calcoli di aggiornare gli aggregati sulla base di tutti i dati il cui arrivo è stato leggermente ritardato, fino a 10 minuti in questo esempio. L'esecuzione della query attivata alle 00:00:00 del 2021-12-01 coprirà l'intervallo di tempo 2021-11-30 23:50:00 al 2021-12-30 00:01:00 e l'esecuzione della query attivata al 2021-12-01 00:05:00 coprirà l'intervallo dal 2021-11-30 23:55:00 al 01/12/2021 00:06:00.
Per garantire la correttezza e assicurarsi che gli aggregati archiviati nella tabella di destinazione corrispondano agli aggregati calcolati dalla tabella di origine, Timestream for LiveAnalytics assicura che il calcolo al 01/12/2021 00:05:00 verrà eseguito solo dopo il completamento del calcolo del 01/12/2021 00:00. I risultati di questi ultimi calcoli possono aggiornare qualsiasi aggregato precedentemente materializzato se viene generato un valore più recente. Internamente, Timestream for LiveAnalytics utilizza versioni record in cui ai record generati dalle ultime istanze di una query pianificata verrà assegnato un numero di versione più elevato. Pertanto, gli aggregati calcolati dalla chiamata alle 00:05:00 del 01/12/2021 possono aggiornare gli aggregati calcolati dalla chiamata alle 00:00:00del 01/12/2021, supponendo che i dati più recenti siano disponibili nella tabella di origine.
Trigger automatici e trigger manuali: dopo la creazione di una query pianificata, Timestream for eseguirà automaticamente le istanze in base alla pianificazione specificata. LiveAnalytics Tali trigger automatici sono gestiti interamente dal servizio.
Tuttavia, potrebbero esserci scenari in cui potresti voler avviare manualmente alcune istanze di una query pianificata. Ad esempio, se un'istanza specifica ha avuto esito negativo nell'esecuzione di una query, se sono arrivati dati o aggiornamenti in ritardo nella tabella di origine dopo l'esecuzione automatica della pianificazione o se si desidera aggiornare la tabella di destinazione per intervalli di tempo non coperti dalle esecuzioni automatiche di query (ad esempio, per gli intervalli di tempo prima della creazione di una query pianificata).
È possibile utilizzare il ExecuteScheduledQuery API per avviare manualmente un'istanza specifica di una query pianificata passando il InvocationTime parametro, che è un valore utilizzato per il parametro @scheduled_runtime. Di seguito sono riportate alcune considerazioni importanti relative all'utilizzo di: ExecuteScheduledQuery API
-
Se state attivando più di queste chiamate, dovete assicurarvi che queste invocazioni non generino risultati in intervalli di tempo sovrapposti. Se non riesci a garantire che gli intervalli di tempo non si sovrappongano, assicurati che queste esecuzioni di query vengano avviate in sequenza una dopo l'altra. Se avviate contemporaneamente più esecuzioni di query che si sovrappongono nei rispettivi intervalli di tempo, nei report sugli errori relativi a queste esecuzioni di query è possibile che si verifichino conflitti di versione.
-
È possibile avviare le chiamate con qualsiasi valore di timestamp per @scheduled_runtime. Quindi è tua responsabilità impostare i valori in modo appropriato in modo che gli intervalli di tempo appropriati vengano aggiornati nella tabella di destinazione corrispondente agli intervalli in cui i dati sono stati aggiornati nella tabella di origine.