```
Una risposta può indicare un successo o contenere informazioni sull'errore.
## Crea un esempio di attività di caricamento in batch
**Example**
1. Crea un flusso temporale per il LiveAnalytics database denominato `BatchLoad` e una tabella denominata. `BatchLoadTest` Verificate e, se necessario, regolate i valori di `MemoryStoreRetentionPeriodInHours` e. `MagneticStoreRetentionPeriodInDays`
```
aws timestream-write create-database --database-name BatchLoad \
aws timestream-write create-table --database-name BatchLoad \
--table-name BatchLoadTest \
--retention-properties "{\"MemoryStoreRetentionPeriodInHours\": 12, \"MagneticStoreRetentionPeriodInDays\": 100}"
```
1. Utilizzando la console, crea un bucket S3 e copia il `sample.csv` file in quella posizione. [Puoi scaricare un file CSV di esempio dalla pagina Sample CSV.](samples/batch-load-sample-file.csv.zip)
1. Utilizzando la console, crea un bucket S3 per Timestream per scrivere un rapporto se l' LiveAnalytics attività di caricamento in batch viene completata con errori.
1. Crea un'attività di caricamento in batch. Assicurati di sostituire *\$1INPUT\$1BUCKET* e *\$1REPORT\$1BUCKET* con i bucket che hai creato nei passaggi precedenti.
```
aws timestream-write create-batch-load-task \
--data-model-configuration "{\
\"DataModel\": {\
\"TimeColumn\": \"timestamp\",\
\"TimeUnit\": \"SECONDS\",\
\"DimensionMappings\": [\
{\
\"SourceColumn\": \"vehicle\"\
},\
{\
\"SourceColumn\": \"registration\",\
\"DestinationColumn\": \"license\"\
}\
],
\"MultiMeasureMappings\": {\
\"TargetMultiMeasureName\": \"mva_measure_name\",\
\"MultiMeasureAttributeMappings\": [\
{\
\"SourceColumn\": \"wgt\",\
\"TargetMultiMeasureAttributeName\": \"weight\",\
\"MeasureValueType\": \"DOUBLE\"\
},\
{\
\"SourceColumn\": \"spd\",\
\"TargetMultiMeasureAttributeName\": \"speed\",\
\"MeasureValueType\": \"DOUBLE\"\
},\
{\
\"SourceColumn\": \"fuel_consumption\",\
\"TargetMultiMeasureAttributeName\": \"fuel\",\
\"MeasureValueType\": \"DOUBLE\"\
},\
{\
\"SourceColumn\": \"miles\",\
\"MeasureValueType\": \"BIGINT\"\
}\
]\
}\
}\
}" \
--data-source-configuration "{
\"DataSourceS3Configuration\": {\
\"BucketName\": \"$INPUT_BUCKET\",\
\"ObjectKeyPrefix\": \"$INPUT_OBJECT_KEY_PREFIX\"
},\
\"DataFormat\": \"CSV\"\
}" \
--report-configuration "{\
\"ReportS3Configuration\": {\
\"BucketName\": \"$REPORT_BUCKET\",\
\"EncryptionOption\": \"SSE_S3\"\
}\
}" \
--target-database-name BatchLoad \
--target-table-name BatchLoadTest
```
Il comando precedente restituisce l'output seguente.
```
{
"TaskId": "TaskId "
}
```
1. Controlla lo stato di avanzamento dell'operazione. Assicurati di sostituirlo *\$1TASK\$1ID* con l'ID dell'attività restituito nel passaggio precedente.
```
aws timestream-write describe-batch-load-task --task-id $TASK_ID
```
**Output di esempio**
```
{
"BatchLoadTaskDescription": {
"ProgressReport": {
"BytesIngested": 1024,
"RecordsIngested": 2,
"FileFailures": 0,
"RecordIngestionFailures": 0,
"RecordsProcessed": 2,
"FileParseFailures": 0
},
"DataModelConfiguration": {
"DataModel": {
"DimensionMappings": [
{
"SourceColumn": "vehicle",
"DestinationColumn": "vehicle"
},
{
"SourceColumn": "registration",
"DestinationColumn": "license"
}
],
"TimeUnit": "SECONDS",
"TimeColumn": "timestamp",
"MultiMeasureMappings": {
"MultiMeasureAttributeMappings": [
{
"TargetMultiMeasureAttributeName": "weight",
"SourceColumn": "wgt",
"MeasureValueType": "DOUBLE"
},
{
"TargetMultiMeasureAttributeName": "speed",
"SourceColumn": "spd",
"MeasureValueType": "DOUBLE"
},
{
"TargetMultiMeasureAttributeName": "fuel",
"SourceColumn": "fuel_consumption",
"MeasureValueType": "DOUBLE"
},
{
"TargetMultiMeasureAttributeName": "miles",
"SourceColumn": "miles",
"MeasureValueType": "DOUBLE"
}
],
"TargetMultiMeasureName": "mva_measure_name"
}
}
},
"TargetDatabaseName": "BatchLoad",
"CreationTime": 1672960381.735,
"TaskStatus": "SUCCEEDED",
"RecordVersion": 1,
"TaskId": "TaskId ",
"TargetTableName": "BatchLoadTest",
"ReportConfiguration": {
"ReportS3Configuration": {
"EncryptionOption": "SSE_S3",
"ObjectKeyPrefix": "ObjectKeyPrefix ",
"BucketName": "amzn-s3-demo-bucket"
}
},
"DataSourceConfiguration": {
"DataSourceS3Configuration": {
"ObjectKeyPrefix": "sample.csv",
"BucketName": "amzn-s3-demo-source-bucket"
},
"DataFormat": "CSV",
"CsvConfiguration": {}
},
"LastUpdatedTime": 1672960387.334
}
}
```
# Utilizzo del caricamento in batch con AWS SDKs
Per esempi su come creare, descrivere ed elencare le attività di caricamento in batch con AWS SDKs[Crea attività di caricamento in batch](code-samples.create-batch-load.md), vedere[Descrizione dell'attività di caricamento in batch](code-samples.describe-batch-load.md),[Elenca le attività di caricamento in batch](code-samples.list-batch-load-tasks.md), e[Riprendi l'operazione di caricamento in batch](code-samples.resume-batch-load-task.md).
# Utilizzo dei report sugli errori di caricamento in batch
Le attività di caricamento in batch hanno uno dei seguenti valori di stato:
+ `CREATED`(**Creato**): l'attività viene creata.
+ `IN_PROGRESS`(**In corso**): l'attività è in corso.
+ `FAILED`(**Non riuscito**): l'attività è stata completata. Ma sono stati rilevati uno o più errori.
+ `SUCCEEDED`(**Completata**): l'attività è stata completata senza errori.
+ `PROGRESS_STOPPED`(**Progresso interrotto**): l'attività è stata interrotta ma non completata. È possibile tentare di riprendere l'attività.
+ `PENDING_RESUME`(**Curriculum in sospeso**): l'attività è in attesa di ripresa.
In caso di errori, viene creato un report di registro degli errori nel bucket S3 definito a tale scopo. Gli errori sono classificati come TaskErrors o FileErrors in matrici separate. Di seguito è riportato un esempio di segnalazione di errori.
```
{
"taskId": "9367BE28418C5EF902676482220B631C",
"taskErrors": [],
"fileErrors": [
{
"fileName": "example.csv",
"errors": [
{
"reason": "The record timestamp is outside the time range of the data ingestion window.",
"lineRanges": [
[
2,
3
]
]
}
]
}
]
}
```
# Utilizzo delle interrogazioni pianificate in Timestream per LiveAnalytics
La funzionalità di interrogazione pianificata di Amazon Timestream LiveAnalytics for è una soluzione completamente gestita, serverless e scalabile per il calcolo e l'archiviazione di aggregati, rollup e altre forme di dati preelaborati tipicamente utilizzati per dashboard operativi, report aziendali, analisi ad hoc e altre applicazioni. Le interrogazioni pianificate rendono l'analisi in tempo reale più performante ed economica, in modo da poter ricavare ulteriori informazioni dai dati e continuare a prendere decisioni aziendali migliori.
Con le query pianificate, definisci le query di analisi in tempo reale che calcolano aggregati, rollup e altre operazioni sui dati, mentre Amazon Timestream esegue LiveAnalytics periodicamente e automaticamente queste query e scrive in modo affidabile i risultati delle query in una tabella separata. I dati vengono generalmente calcolati e aggiornati in queste tabelle entro pochi minuti.
È quindi possibile indirizzare i dashboard e i report in modo da interrogare le tabelle che contengono dati aggregati anziché interrogare le tabelle di origine, notevolmente più grandi. Ciò porta a miglioramenti in termini di prestazioni e costi che possono superare ordini di grandezza. Questo perché le tabelle con dati aggregati contengono molti meno dati rispetto alle tabelle di origine, quindi offrono query più veloci e un'archiviazione dei dati più economica.
Inoltre, le tabelle con interrogazioni pianificate offrono tutte le funzionalità esistenti di un Timestream for table. LiveAnalytics Ad esempio, è possibile interrogare le tabelle utilizzando SQL. È possibile visualizzare i dati memorizzati nelle tabelle utilizzando Grafana. Puoi anche inserire dati nella tabella utilizzando Amazon Kinesis, Amazon MSK AWS , IoT Core e Telegraf. Puoi configurare le politiche di conservazione dei dati su queste tabelle per la gestione automatica del ciclo di vita dei dati.
Poiché la conservazione dei dati delle tabelle che contengono dati aggregati è completamente disaccoppiata da quella delle tabelle di origine, puoi anche scegliere di ridurre la conservazione dei dati delle tabelle di origine e conservare i dati aggregati per una durata molto più lunga, a una frazione del costo di archiviazione dei dati. Le query pianificate rendono l'analisi in tempo reale più veloce, economica e quindi più accessibile a molti più clienti, in modo che possano monitorare le loro applicazioni e prendere decisioni aziendali migliori basate sui dati.
**Topics**
+ [Vantaggi](#scheduledqueries-benifits)
+ [Casi d’uso](#scheduledqueries-usescases)
+ [Esempio](#scheduledqueries-example)
+ [Concetti](scheduledqueries-concepts.md)
+ [Espressioni di pianificazione](scheduledqueries-schedule.md)
+ [Mappature dei modelli di dati](scheduledqueries-mappings.md)
+ [Messaggi di notifica](scheduledqueries-notification.md)
+ [Rapporti di errore](scheduledqueries-errorreport.md)
+ [Schemi ed esempi](scheduledqueries-examplesandpatterns.md)
## Vantaggi delle interrogazioni pianificate
Di seguito sono riportati i vantaggi delle interrogazioni pianificate:
+ **Facilità operativa**: le query pianificate sono senza server e completamente gestite.
+ **Prestazioni e costi**: poiché le query pianificate precalcolano gli aggregati, i rollup o altre operazioni di analisi in tempo reale dei dati e archiviano i risultati in una tabella, le query che accedono alle tabelle popolate da query pianificate contengono meno dati rispetto alle tabelle di origine. Pertanto, le query eseguite su queste tabelle sono più veloci ed economiche. Le tabelle popolate da calcoli pianificati contengono meno dati rispetto alle tabelle di origine e quindi aiutano a ridurre i costi di archiviazione. È inoltre possibile conservare questi dati per un periodo più lungo nell'archivio di memoria a una frazione del costo di conservazione dei dati di origine nell'archivio di memoria.
+ **Interoperabilità**: le tabelle popolate da query pianificate offrono tutte le funzionalità esistenti di Timestream per le LiveAnalytics tabelle e possono essere utilizzate con tutti i servizi e gli strumenti compatibili con Timestream for. LiveAnalytics [Vedi Lavorare con altri servizi per i dettagli.](https://docs.aws.amazon.com/timestream/latest/developerguide/OtherServices.html)
## Casi d'uso delle interrogazioni pianificate
È possibile utilizzare le query pianificate per i report aziendali che riepilogano l'attività dell'utente finale delle applicazioni, in modo da poter addestrare modelli di machine learning per la personalizzazione. Puoi anche utilizzare le query pianificate per gli allarmi che rilevano anomalie, intrusioni di rete o attività fraudolente, in modo da poter intraprendere azioni correttive immediate.
Inoltre, puoi utilizzare le query pianificate per una governance dei dati più efficace. Puoi farlo concedendo l'accesso alla tabella di origine esclusivamente alle query pianificate e fornendo agli sviluppatori l'accesso solo alle tabelle popolate dalle query pianificate. Ciò riduce al minimo l'impatto delle query involontarie e di lunga durata.
## Esempio: utilizzo di analisi in tempo reale per rilevare pagamenti fraudolenti e prendere decisioni aziendali migliori
Prendi in considerazione un sistema di pagamento che elabora le transazioni inviate da più point-of-sale terminali distribuiti nelle principali città metropolitane degli Stati Uniti d'America. Vuoi utilizzare Amazon Timestream LiveAnalytics per archiviare e analizzare i dati delle transazioni, in modo da poter rilevare transazioni fraudolente ed eseguire query di analisi in tempo reale. Queste domande possono aiutarti a rispondere a domande aziendali come identificare i point-of-sale terminali più trafficati e meno utilizzati all'ora, l'ora più trafficata del giorno per ogni città e la città con il maggior numero di transazioni all'ora.
Il sistema elabora circa 100.000 transazioni al minuto. Ogni transazione memorizzata in Amazon Timestream è di 100 LiveAnalytics byte. Hai configurato 10 query che vengono eseguite ogni minuto per rilevare vari tipi di pagamenti fraudolenti. Hai anche creato 25 query che aggregano e suddividono i dati in varie dimensioni per aiutarti a rispondere alle tue domande aziendali. Ognuna di queste query elabora i dati dell'ultima ora.
Hai creato una dashboard per visualizzare i dati generati da queste query. La dashboard contiene 25 widget, viene aggiornata ogni ora e in genere è accessibile da 10 utenti in un dato momento. Infine, l'archivio di memoria è configurato con un periodo di conservazione dei dati di 2 ore e l'archivio magnetico è configurato per avere un periodo di conservazione dei dati di 6 mesi.
In questo caso, puoi utilizzare query di analisi in tempo reale che ricalcolano i dati ogni volta che si accede e si aggiorna la dashboard, oppure utilizzare tabelle derivate per la dashboard. Il costo delle query per i dashboard basati su query di analisi in tempo reale sarà di 120,70 dollari al mese. [Al contrario, il costo delle query di dashboard basate su tabelle derivate sarà di 12,27 dollari al mese (consulta Amazon Timestream per i prezzi). LiveAnalytics](https://aws.amazon.com/timestream/pricing/) In questo caso, l'utilizzo di tabelle derivate riduce il costo delle query di circa 10 volte.
# Concetti di interrogazione pian
**Stringa di interrogazione**: questa è l'interrogazione il cui risultato viene precalcolato e memorizzato in un altro Timestream per tabella. LiveAnalytics [È possibile definire una query pianificata utilizzando l'intera area di superficie SQL 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 ](https://docs.aws.amazon.com/timestream/latest/developerguide/reference.html)
**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 ogni giorno alle 8:00 UTC) o un'espressione di frequenza (ad esempio 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 query di questo tipo eseguita su un argomento SNS configurato quando crei una query 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 sono 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](https://docs.aws.amazon.com/timestream/latest/developerguide/tagging-keyspaces.html) 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 \$1 \$1 \$1? \$1) 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\$1runtime 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 l' ExecuteScheduledQuery API per avviare manualmente un'istanza specifica di una query pianificata passando il InvocationTime parametro, che è un valore utilizzato per il parametro @scheduled\$1runtime. Di seguito sono riportate alcune considerazioni importanti relative all'utilizzo dell' ExecuteScheduledQuery API:
+ Se state attivando più di queste chiamate, dovete assicurarvi che queste chiamate 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\$1runtime. 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.
+ L' ExecuteScheduledQuery API funziona in modo asincrono. Dopo una chiamata riuscita, il servizio invia una risposta di 200 e procede all'esecuzione della query. Tuttavia, se sono in esecuzione contemporaneamente più esecuzioni di query pianificate, è possibile prevedere potenziali ritardi nell'esecuzione delle esecuzioni pianificate attivate manualmente.
# Espressioni di pianificazione per le interrogazioni pianificate
Puoi creare query pianificate in base a una pianificazione automatica utilizzando Amazon LiveAnalytics Timestream per query pianificate che utilizzano espressioni cron o rate. Tutte le query pianificate utilizzano il fuso orario UTC e la precisione minima possibile per le pianificazioni è di 1 minuto.
*Due modi per specificare le espressioni di pianificazione sono *cron* e rate.* Le espressioni cron offrono un controllo più preciso della pianificazione, mentre le espressioni rate sono più semplici da esprimere ma non dispongono di un controllo granulare.
Ad esempio, con un'espressione cron, puoi definire una query pianificata che viene attivata a un'ora specifica in un determinato giorno di ogni settimana o mese, o un minuto specifico ogni ora solo dal lunedì al venerdì e così via. Al contrario, le espressioni rate avviano una query pianificata a una frequenza regolare, ad esempio una volta ogni minuto, ora o giorno, a partire dall'ora esatta in cui viene creata la query pianificata.
**Espressione cron**
+ *Sintassi*
```
cron(fields)
```
Le espressioni Cron hanno sei campi obbligatori separati da uno spazio vuoto.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/timestream/latest/developerguide/scheduledqueries-schedule.html)
**Caratteri jolly**
+ Il carattere jolly \$1, \$1 (virgola) include valori aggiuntivi. Nel campo Month (Mese), JAN,FEB,MAR (GEN,FEB,MAR) include gennaio, febbraio e marzo.
+ Il carattere jolly \$1-\$1 (trattino) specifica gli intervalli. Nel campo Day (Giorno), 1-15 include i giorni dall'1 al 15 del mese specificato.
+ Il carattere jolly \$1\$1\$1 (asterisco) include tutti i valori del campo. Nel campo Ore, \$1\$1\$1 includerebbe ogni ora. Non è possibile utilizzare \$1\$1\$1 in entrambi i Day-of-week campi Day-of-month e. Se lo usi in uno, devi usare\$1? \$1 nell'altra.
+ Il carattere jolly \$1/\$1 (barra in avanti) specifica gli incrementi. Nel campo Minuti, è possibile inserire 1/10 per specificare ogni decimo minuto, a partire dal primo minuto dell'ora (ad esempio, l'undicesimo, il ventunesimo e il 31° minuto e così via).
+ Il\$1? \$1 (punto interrogativo) il carattere jolly specifica l'uno o l'altro. Nel Day-of-month campo puoi inserire \$17\$1 e se non ti interessa in che giorno della settimana è il 7, puoi inserire\$1? \$1 nel campo. Day-of-week
+ Il carattere jolly \$1L\$1 nei Day-of-week campi Day-of-month or specifica l'ultimo giorno del mese o della settimana.
+ Il carattere jolly W nel campo specifica un giorno della settimana Day-of-month. Nel Day-of-month campo, 3W specifica il giorno della settimana più vicino al terzo giorno del mese.
+ Il carattere jolly \$1\$1\$1 nel Day-of-week campo specifica una determinata istanza del giorno della settimana specificato all'interno di un mese. Ad esempio, 3\$12 sarebbe il secondo martedì del mese: il 3 fa riferimento a martedì perché è il terzo giorno di ogni settimana e il 2 fa riferimento al secondo giorno di questo tipo in un mese.
**Nota**
Se si utilizza un carattere '\$1', è possibile definire solo un'espressione nel campo. day-of-week Ad esempio, "3\$11,6\$13" non è valido perché viene interpretato come due espressioni.
**Limitazioni**
+ Non puoi specificare i campi Day-of-month e Day-of-week nella stessa espressione cron. Se si specifica un valore (o un \$1) in uno dei campi, è necessario utilizzare un \$1? \$1 (punto interrogativo) nell'altro.
+ Le espressioni Cron che indicano frequenze più rapide di 1 minuto non sono supportate.
**Esempi**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/timestream/latest/developerguide/scheduledqueries-schedule.html)
**Espressioni della frequenza**
+ Un espressione rate inizia quando crei la regola di evento pianificato e successivamente la esegui nella relativa pianificazione definita. Le espressioni rate hanno due campi obbligatori. I campi sono separati da uno spazio vuoto.
*Sintassi*
```
rate(value unit)
```
+ `value`: Un numero positivo.
+ `unit`: L'unità di tempo. Sono necessarie unità diverse per i valori di 1 (ad esempio, minuto) e i valori superiori a 1 (ad esempio, minuti). Valori validi: minuto \$1 minuti \$1 ora \$1 ore \$1 giorno \$1 giorni
# Mappature dei modelli di dati per le interrogazioni pianificate
Timestream for LiveAnalytics supporta la modellazione flessibile dei dati nelle sue tabelle e questa stessa flessibilità si applica ai risultati delle query pianificate che vengono materializzate in un altro Timestream per tabella. LiveAnalytics Con le interrogazioni pianificate, è possibile eseguire query su qualsiasi tabella, indipendentemente dal fatto che contenga dati in record a più misure o record di singola misura, e scrivere i risultati della query utilizzando record a più o a misura singola.
È possibile utilizzare il TargetConfiguration nella specifica di un'interrogazione pianificata per mappare i risultati della query alle colonne appropriate nella tabella derivata di destinazione. Le sezioni seguenti descrivono i diversi modi di TargetConfiguration specificarlo per ottenere modelli di dati diversi nella tabella derivata. In particolare, vedrai:
+ Come scrivere su record multimisura quando il risultato della query non ha un nome di misura e si specifica il nome della TargetConfiguration misura di destinazione in.
+ Come si utilizza il nome della misura nei risultati della query per scrivere record con più misure.
+ Come definire un modello per scrivere più record con diversi attributi multimisura.
+ Come definire un modello per scrivere su record di singola misura nella tabella derivata.
+ In che modo è possibile interrogare record di singola misura, record di and/or più misure in un'interrogazione pianificata e far sì che i risultati vengano materializzati in un record a misura singola o in un record a più misure, il che consente di scegliere la flessibilità dei modelli di dati.
## Esempio: nome della misura di destinazione per i record multimisura
In questo esempio, si vedrà che la query sta leggendo i dati da una tabella con dati a più misure e sta scrivendo i risultati in un'altra tabella utilizzando record multimisura. Il risultato della query pianificata non ha una colonna con il nome della misura naturale. Qui, si specifica il nome della misura nella tabella derivata utilizzando la TargetMultiMeasureName proprietà in TargetConfiguration. TimestreamConfiguration.
```
{
"Name" : "CustomMultiMeasureName",
"QueryString" : "SELECT region, bin(time, 1h) as hour, AVG(memory_cached) as avg_mem_cached_1h, MIN(memory_free) as min_mem_free_1h, MAX(memory_used) as max_mem_used_1h, SUM(disk_io_writes) as sum_1h, AVG(disk_used) as avg_disk_used_1h, AVG(disk_free) as avg_disk_free_1h, MAX(cpu_user) as max_cpu_user_1h, MIN(cpu_idle) as min_cpu_idle_1h, MAX(cpu_system) as max_cpu_system_1h FROM raw_data.devops_multi WHERE time BETWEEN bin(@scheduled_runtime, 1h) - 14h AND bin(@scheduled_runtime, 1h) - 2h AND measure_name = 'metrics' GROUP BY region, bin(time, 1h)",
"ScheduleConfiguration" : {
"ScheduleExpression" : "cron(0 0/1 * * ? *)"
},
"NotificationConfiguration" : {
"SnsConfiguration" : {
"TopicArn" : "******"
}
},
"ScheduledQueryExecutionRoleArn": "******",
"TargetConfiguration": {
"TimestreamConfiguration": {
"DatabaseName" : "derived",
"TableName" : "dashboard_metrics_1h_agg_1",
"TimeColumn" : "hour",
"DimensionMappings" : [
{
"Name": "region",
"DimensionValueType" : "VARCHAR"
}
],
"MultiMeasureMappings" : {
"TargetMultiMeasureName": "dashboard-metrics",
"MultiMeasureAttributeMappings" : [
{
"SourceColumn" : "avg_mem_cached_1h",
"MeasureValueType" : "DOUBLE",
"TargetMultiMeasureAttributeName" : "avgMemCached"
},
{
"SourceColumn" : "min_mem_free_1h",
"MeasureValueType" : "DOUBLE"
},
{
"SourceColumn" : "max_mem_used_1h",
"MeasureValueType" : "DOUBLE"
},
{
"SourceColumn" : "sum_1h",
"MeasureValueType" : "DOUBLE",
"TargetMultiMeasureAttributeName" : "totalDiskWrites"
},
{
"SourceColumn" : "avg_disk_used_1h",
"MeasureValueType" : "DOUBLE"
},
{
"SourceColumn" : "avg_disk_free_1h",
"MeasureValueType" : "DOUBLE"
},
{
"SourceColumn" : "max_cpu_user_1h",
"MeasureValueType" : "DOUBLE",
"TargetMultiMeasureAttributeName" : "CpuUserP100"
},
{
"SourceColumn" : "min_cpu_idle_1h",
"MeasureValueType" : "DOUBLE"
},
{
"SourceColumn" : "max_cpu_system_1h",
"MeasureValueType" : "DOUBLE",
"TargetMultiMeasureAttributeName" : "CpuSystemP100"
}
]
}
}
},
"ErrorReportConfiguration": {
"S3Configuration" : {
"BucketName" : "******",
"ObjectKeyPrefix": "errors",
"EncryptionOption": "SSE_S3"
}
}
}
```
La mappatura in questo esempio crea un record multimisura con il nome della misura dashboard-metrics e i nomi degli attributi, min\$1mem\$1free\$11h, max\$1mem\$1used\$11h, avg\$1disk\$1used\$11h avgMemCached, avg\$1disk\$1free\$11h, P100, min\$1cpu\$1idle\$11h, P100. totalDiskWrites CpuUser CpuSystem Si noti l'uso opzionale di TargetMultiMeasureAttributeName per rinominare le colonne di output della query con un nome di attributo diverso utilizzato per la materializzazione dei risultati.
Di seguito è riportato lo schema per la tabella di destinazione una volta materializzata questa query pianificata. Come si può vedere dal Timestream per il tipo di LiveAnalytics attributo nel risultato seguente, i risultati vengono materializzati in un record multimisura con un nome a misura singola`dashboard-metrics`, come mostrato nello schema di misura.
| Colonna | Tipo | Timestream per il tipo di attributo LiveAnalytics |
| --- | --- | --- |
| region | varchar | DIMENSIONE |
| measure\$1name | varchar | MEASURE\$1NAME |
| time | timestamp | TIMESTAMP |
| CpuSystemP100 | virgola mobile a doppia precisione | MULTIPLO |
| avgMemCached | virgola mobile a doppia precisione | MULTI |
| min\$1cpu\$1idle\$11h | virgola mobile a doppia precisione | MULTIPLO |
| avg\$1disk\$1free\$11h | virgola mobile a doppia precisione | MULTIPLO |
| avg\$1disk\$1used\$11h | virgola mobile a doppia precisione | MULTI |
| totalDiskWrites | virgola mobile a doppia precisione | MULTI |
| max\$1mem\$1used\$11 h | virgola mobile a doppia precisione | MULTIPLO |
| min\$1mem\$1free\$11 h | virgola mobile a doppia precisione | MULTIPLO |
| CpuUserP100 | virgola mobile a doppia precisione | MULTIPLO |
Di seguito sono riportate le misure corrispondenti ottenute con una query SHOW MEASURES.
| measure\$1name | data\$1type | Dimensioni |
| --- | --- | --- |
| metriche del pannello di controllo | multi | [\$1'dimension\$1name': 'regione', 'data\$1type': 'varchar'\$1] |
## Esempio: utilizzo del nome della misura da una query pianificata in record multimisura
In questo esempio, vedrete una query che legge da una tabella con record a misura singola e materializza i risultati in record a più misure. In questo caso, il risultato della query pianificata ha una colonna i cui valori possono essere utilizzati come nomi di misure nella tabella di destinazione in cui vengono materializzati i risultati dell'interrogazione pianificata. È quindi possibile specificare il nome della misura per il record multimisura nella tabella derivata utilizzando la MeasureNameColumn proprietà in. TargetConfiguration TimestreamConfiguration.
```
{
"Name" : "UsingMeasureNameFromQueryResult",
"QueryString" : "SELECT region, bin(time, 1h) as hour, measure_name, AVG(CASE WHEN measure_name IN ('memory_cached', 'disk_used', 'disk_free') THEN measure_value::double ELSE NULL END) as avg_1h, MIN(CASE WHEN measure_name IN ('memory_free', 'cpu_idle') THEN measure_value::double ELSE NULL END) as min_1h, SUM(CASE WHEN measure_name IN ('disk_io_writes') THEN measure_value::double ELSE NULL END) as sum_1h, MAX(CASE WHEN measure_name IN ('memory_used', 'cpu_user', 'cpu_system') THEN measure_value::double ELSE NULL END) as max_1h FROM raw_data.devops WHERE time BETWEEN bin(@scheduled_runtime, 1h) - 14h AND bin(@scheduled_runtime, 1h) - 2h AND measure_name IN ('memory_free', 'memory_used', 'memory_cached', 'disk_io_writes', 'disk_used', 'disk_free', 'cpu_user', 'cpu_system', 'cpu_idle') GROUP BY region, measure_name, bin(time, 1h)",
"ScheduleConfiguration" : {
"ScheduleExpression" : "cron(0 0/1 * * ? *)"
},
"NotificationConfiguration" : {
"SnsConfiguration" : {
"TopicArn" : "******"
}
},
"ScheduledQueryExecutionRoleArn": "******",
"TargetConfiguration": {
"TimestreamConfiguration": {
"DatabaseName" : "derived",
"TableName" : "dashboard_metrics_1h_agg_2",
"TimeColumn" : "hour",
"DimensionMappings" : [
{
"Name": "region",
"DimensionValueType" : "VARCHAR"
}
],
"MeasureNameColumn" : "measure_name",
"MultiMeasureMappings" : {
"MultiMeasureAttributeMappings" : [
{
"SourceColumn" : "avg_1h",
"MeasureValueType" : "DOUBLE"
},
{
"SourceColumn" : "min_1h",
"MeasureValueType" : "DOUBLE",
"TargetMultiMeasureAttributeName": "p0_1h"
},
{
"SourceColumn" : "sum_1h",
"MeasureValueType" : "DOUBLE"
},
{
"SourceColumn" : "max_1h",
"MeasureValueType" : "DOUBLE",
"TargetMultiMeasureAttributeName": "p100_1h"
}
]
}
}
},
"ErrorReportConfiguration": {
"S3Configuration" : {
"BucketName" : "******",
"ObjectKeyPrefix": "errors",
"EncryptionOption": "SSE_S3"
}
}
}
```
La mappatura in questo esempio creerà record multimisura con gli attributi avg\$11h, p0\$11h, sum\$11h, p100\$11h e utilizzerà i valori della colonna measure\$1name nel risultato della query come nome della misura per i record multimisura nella tabella di destinazione. Si noti inoltre che gli esempi precedenti utilizzano facoltativamente il con un sottoinsieme delle mappature per rinominare gli attributi. TargetMultiMeasureAttributeName Ad esempio, min\$11h è stato rinominato in p0\$11h e max\$11h è stato rinominato in p100\$11h.
Di seguito è riportato lo schema per la tabella di destinazione una volta materializzata questa query pianificata. Come si può vedere dal Timestream per il tipo di LiveAnalytics attributo nel risultato seguente, i risultati vengono materializzati in un record multimisura. Se si esamina lo schema di misura, sono stati inseriti nove diversi nomi di misure che corrispondono ai valori visualizzati nei risultati della query.
| Colonna | Tipo | Timestream per il tipo di attributo LiveAnalytics |
| --- | --- | --- |
| region | varchar | DIMENSIONE |
| measure\$1name | varchar | MEASURE\$1NAME |
| time | timestamp | TIMESTAMP |
| sum\$11h | virgola mobile a doppia precisione | MULTI |
| p100\$11h | virgola mobile a doppia precisione | MULTI |
| p0\$11h | virgola mobile a doppia precisione | MULTI |
| avg\$11h | virgola mobile a doppia precisione | MULTI |
Di seguito sono riportate le misure corrispondenti ottenute con una query SHOW MEASURES.
| measure\$1name | data\$1type | Dimensioni |
| --- | --- | --- |
| cpu\$1idle | multi | [\$1'dimension\$1name': 'regione', 'data\$1type': 'varchar'\$1] |
| sistema\$1cpu | multiplo | [\$1'dimension\$1name': 'regione', 'data\$1type': 'varchar'\$1] |
| cpu\$1user | multiplo | [\$1'dimension\$1name': 'regione', 'data\$1type': 'varchar'\$1] |
| disk\$1free | multi | [\$1'dimension\$1name': 'regione', 'data\$1type': 'varchar'\$1] |
| disk\$1io\$1write | multi | [\$1'dimension\$1name': 'regione', 'data\$1type': 'varchar'\$1] |
| disk\$1used | multi | [\$1'dimension\$1name': 'regione', 'data\$1type': 'varchar'\$1] |
| memoria\$1memorizzata nella cache | multi | [\$1'dimension\$1name': 'regione', 'data\$1type': 'varchar'\$1] |
| senza memoria | multiplo | [\$1'dimension\$1name': 'regione', 'data\$1type': 'varchar'\$1] |
| senza memoria | multiplo | [\$1'dimension\$1name': 'regione', 'data\$1type': 'varchar'\$1] |
## Esempio: mappatura dei risultati su diversi record multimisura con attributi diversi
L'esempio seguente mostra come è possibile mappare diverse colonne del risultato della query in diversi record multimisura con nomi di misure diversi. Se viene visualizzata la seguente definizione di query pianificata, il risultato della query ha le seguenti colonne: region, hour, avg\$1mem\$1cached\$11h, min\$1mem\$1free\$11h, max\$1mem\$1used\$11h, total\$1disk\$1io\$1writes\$11h, avg\$1disk\$1used\$11h, avg\$1disk\$1free\$11h, max\$1cpu\$1utente\$11h, sistema\$1cpu\$1max\$11h, min\$1cpu\$1sistema\$11h. `region`è mappato alla dimensione ed `hour` è mappato alla colonna del tempo.
La MixedMeasureMappings proprietà in. TargetConfiguration TimestreamConfigurationspecifica come mappare le misure su record multimisura nella tabella derivata.
In questo esempio specifico, avg\$1mem\$1cached\$11h, min\$1mem\$1free\$11h, max\$1mem\$1used\$11h vengono utilizzati in un record multimisura con nome di misura mem\$1aggregates, total\$1disk\$1io\$1writes\$11h, avg\$1disk\$1used\$11h, avg\$1disk\$1free\$11h vengono utilizzati in un altro record multimisura con misura name of disk\$1aggregates e infine max\$1cpu\$1user\$11h, max\$1cpu\$1system\$11h, min\$1cpu\$1system\$11h vengono utilizzati in un altro record multimisura con nome di misura cpu\$1aggregates.
In queste mappature, è anche possibile utilizzare facoltativamente TargetMultiMeasureAttributeName per rinominare la colonna dei risultati della query in modo che abbia un nome di attributo diverso nella tabella di destinazione. Ad esempio, la colonna dei risultati avg\$1mem\$1cached\$11h viene rinominata in, total\$1disk\$1io\$1writes\$11h viene rinominata total, ecc. avgMemCached IOWrites
Quando definisci le mappature per i record multimisura, Timestream for ispeziona ogni riga dei risultati della query e ignora automaticamente i valori delle colonne con valori NULL. LiveAnalytics Di conseguenza, nel caso di mappature con più nomi di misure, se tutti i valori di colonna per quel gruppo nella mappatura sono NULL per una determinata riga, per quella riga non viene inserito alcun valore per il nome di quella misura.
Ad esempio, nella mappatura seguente, avg\$1mem\$1cached\$11h, min\$1mem\$1free\$11h e max\$1mem\$1used\$11h vengono mappati per misurare il nome mem\$1aggregates. Se per una determinata riga del risultato della query, tutti questi valori della colonna sono NULL, Timestream for non inserirà la misura mem\$1aggregates per quella riga. LiveAnalytics Se tutte e nove le colonne di una determinata riga sono NULL, nel rapporto di errore verrà riportato un errore utente.
```
{
"Name" : "AggsInDifferentMultiMeasureRecords",
"QueryString" : "SELECT region, bin(time, 1h) as hour, AVG(CASE WHEN measure_name = 'memory_cached' THEN measure_value::double ELSE NULL END) as avg_mem_cached_1h, MIN(CASE WHEN measure_name = 'memory_free' THEN measure_value::double ELSE NULL END) as min_mem_free_1h, MAX(CASE WHEN measure_name = 'memory_used' THEN measure_value::double ELSE NULL END) as max_mem_used_1h, SUM(CASE WHEN measure_name = 'disk_io_writes' THEN measure_value::double ELSE NULL END) as total_disk_io_writes_1h, AVG(CASE WHEN measure_name = 'disk_used' THEN measure_value::double ELSE NULL END) as avg_disk_used_1h, AVG(CASE WHEN measure_name = 'disk_free' THEN measure_value::double ELSE NULL END) as avg_disk_free_1h, MAX(CASE WHEN measure_name = 'cpu_user' THEN measure_value::double ELSE NULL END) as max_cpu_user_1h, MAX(CASE WHEN measure_name = 'cpu_system' THEN measure_value::double ELSE NULL END) as max_cpu_system_1h, MIN(CASE WHEN measure_name = 'cpu_idle' THEN measure_value::double ELSE NULL END) as min_cpu_system_1h FROM raw_data.devops WHERE time BETWEEN bin(@scheduled_runtime, 1h) - 14h AND bin(@scheduled_runtime, 1h) - 2h AND measure_name IN ('memory_cached', 'memory_free', 'memory_used', 'disk_io_writes', 'disk_used', 'disk_free', 'cpu_user', 'cpu_system', 'cpu_idle') GROUP BY region, bin(time, 1h)",
"ScheduleConfiguration" : {
"ScheduleExpression" : "cron(0 0/1 * * ? *)"
},
"NotificationConfiguration" : {
"SnsConfiguration" : {
"TopicArn" : "******"
}
},
"ScheduledQueryExecutionRoleArn": "******",
"TargetConfiguration": {
"TimestreamConfiguration": {
"DatabaseName" : "derived",
"TableName" : "dashboard_metrics_1h_agg_3",
"TimeColumn" : "hour",
"DimensionMappings" : [
{
"Name": "region",
"DimensionValueType" : "VARCHAR"
}
],
"MixedMeasureMappings" : [
{
"MeasureValueType" : "MULTI",
"TargetMeasureName" : "mem_aggregates",
"MultiMeasureAttributeMappings" : [
{
"SourceColumn" : "avg_mem_cached_1h",
"MeasureValueType" : "DOUBLE",
"TargetMultiMeasureAttributeName": "avgMemCached"
},
{
"SourceColumn" : "min_mem_free_1h",
"MeasureValueType" : "DOUBLE"
},
{
"SourceColumn" : "max_mem_used_1h",
"MeasureValueType" : "DOUBLE",
"TargetMultiMeasureAttributeName": "maxMemUsed"
}
]
},
{
"MeasureValueType" : "MULTI",
"TargetMeasureName" : "disk_aggregates",
"MultiMeasureAttributeMappings" : [
{
"SourceColumn" : "total_disk_io_writes_1h",
"MeasureValueType" : "DOUBLE",
"TargetMultiMeasureAttributeName": "totalIOWrites"
},
{
"SourceColumn" : "avg_disk_used_1h",
"MeasureValueType" : "DOUBLE"
},
{
"SourceColumn" : "avg_disk_free_1h",
"MeasureValueType" : "DOUBLE"
}
]
},
{
"MeasureValueType" : "MULTI",
"TargetMeasureName" : "cpu_aggregates",
"MultiMeasureAttributeMappings" : [
{
"SourceColumn" : "max_cpu_user_1h",
"MeasureValueType" : "DOUBLE"
},
{
"SourceColumn" : "max_cpu_system_1h",
"MeasureValueType" : "DOUBLE"
},
{
"SourceColumn" : "min_cpu_idle_1h",
"MeasureValueType" : "DOUBLE",
"TargetMultiMeasureAttributeName": "minCpuIdle"
}
]
}
]
}
},
"ErrorReportConfiguration": {
"S3Configuration" : {
"BucketName" : "******",
"ObjectKeyPrefix": "errors",
"EncryptionOption": "SSE_S3"
}
}
}
```
Di seguito è riportato lo schema per la tabella di destinazione una volta materializzata questa query pianificata.
| Colonna | Tipo | Timestream per il tipo di attributo LiveAnalytics |
| --- | --- | --- |
| region | varchar | DIMENSIONE |
| measure\$1name | varchar | MEASURE\$1NAME |
| time | timestamp | TIMESTAMP |
| minCpuIdle | virgola mobile a doppia precisione | MULTIPLO |
| max\$1cpu\$1system\$11h | virgola mobile a doppia precisione | MULTIPLO |
| max\$1cpu\$1user\$11h | virgola mobile a doppia precisione | MULTIPLO |
| avgMemCached | virgola mobile a doppia precisione | MULTI |
| maxMemUsed | virgola mobile a doppia precisione | MULTI |
| min\$1mem\$1free\$11 h | virgola mobile a doppia precisione | MULTIPLO |
| avg\$1disk\$1free\$11h | virgola mobile a doppia precisione | MULTIPLO |
| avg\$1disk\$1used\$11h | virgola mobile a doppia precisione | MULTI |
| totale IOWrites | virgola mobile a doppia precisione | MULTIPLO |
Di seguito sono riportate le misure corrispondenti ottenute con una query SHOW MEASURES.
| measure\$1name | data\$1type | Dimensioni |
| --- | --- | --- |
| cpu\$1aggregates | multi | [\$1'dimension\$1name': 'regione', 'data\$1type': 'varchar'\$1] |
| disk\$1aggregates | multi | [\$1'dimension\$1name': 'regione', 'data\$1type': 'varchar'\$1] |
| mem\$1aggregates | multi | [\$1'dimension\$1name': 'regione', 'data\$1type': 'varchar'\$1] |
## Esempio: mappatura dei risultati su record a misura singola con il nome della misura dai risultati della query
Di seguito è riportato un esempio di interrogazione pianificata i cui risultati vengono materializzati in record a misura singola. In questo esempio, il risultato della query contiene la colonna measure\$1name i cui valori verranno utilizzati come nomi delle misure nella tabella di destinazione. Si utilizza l' MixedMeasureMappings attributo in. TargetConfiguration TimestreamConfiguration per specificare la mappatura della colonna dei risultati della query alla misura scalare nella tabella di destinazione.
Nella definizione dell'esempio seguente, il risultato della query è previsto in nove valori distinti di measure\$1name. Si elencano tutti i nomi di queste misure nella mappatura e si specifica quale colonna utilizzare per il valore di misura singola per quel nome di misura. Ad esempio, in questa mappatura, se il nome della misura di memory\$1cached viene visualizzato per una determinata riga di risultati, il valore nella colonna avg\$11h viene utilizzato come valore per la misura quando i dati vengono scritti nella tabella di destinazione. Facoltativamente, è possibile utilizzare per fornire un nuovo nome di misura per TargetMeasureName questo valore.
```
{
"Name" : "UsingMeasureNameColumnForSingleMeasureMapping",
"QueryString" : "SELECT region, bin(time, 1h) as hour, measure_name, AVG(CASE WHEN measure_name IN ('memory_cached', 'disk_used', 'disk_free') THEN measure_value::double ELSE NULL END) as avg_1h, MIN(CASE WHEN measure_name IN ('memory_free', 'cpu_idle') THEN measure_value::double ELSE NULL END) as min_1h, SUM(CASE WHEN measure_name IN ('disk_io_writes') THEN measure_value::double ELSE NULL END) as sum_1h, MAX(CASE WHEN measure_name IN ('memory_used', 'cpu_user', 'cpu_system') THEN measure_value::double ELSE NULL END) as max_1h FROM raw_data.devops WHERE time BETWEEN bin(@scheduled_runtime, 1h) - 14h AND bin(@scheduled_runtime, 1h) - 2h AND measure_name IN ('memory_free', 'memory_used', 'memory_cached', 'disk_io_writes', 'disk_used', 'disk_free', 'cpu_user', 'cpu_system', 'cpu_idle') GROUP BY region, bin(time, 1h), measure_name",
"ScheduleConfiguration" : {
"ScheduleExpression" : "cron(0 0/1 * * ? *)"
},
"NotificationConfiguration" : {
"SnsConfiguration" : {
"TopicArn" : "******"
}
},
"ScheduledQueryExecutionRoleArn": "******",
"TargetConfiguration": {
"TimestreamConfiguration": {
"DatabaseName" : "derived",
"TableName" : "dashboard_metrics_1h_agg_4",
"TimeColumn" : "hour",
"DimensionMappings" : [
{
"Name": "region",
"DimensionValueType" : "VARCHAR"
}
],
"MeasureNameColumn" : "measure_name",
"MixedMeasureMappings" : [
{
"MeasureName" : "memory_cached",
"MeasureValueType" : "DOUBLE",
"SourceColumn" : "avg_1h",
"TargetMeasureName" : "AvgMemCached"
},
{
"MeasureName" : "disk_used",
"MeasureValueType" : "DOUBLE",
"SourceColumn" : "avg_1h"
},
{
"MeasureName" : "disk_free",
"MeasureValueType" : "DOUBLE",
"SourceColumn" : "avg_1h"
},
{
"MeasureName" : "memory_free",
"MeasureValueType" : "DOUBLE",
"SourceColumn" : "min_1h",
"TargetMeasureName" : "MinMemFree"
},
{
"MeasureName" : "cpu_idle",
"MeasureValueType" : "DOUBLE",
"SourceColumn" : "min_1h"
},
{
"MeasureName" : "disk_io_writes",
"MeasureValueType" : "DOUBLE",
"SourceColumn" : "sum_1h",
"TargetMeasureName" : "total-disk-io-writes"
},
{
"MeasureName" : "memory_used",
"MeasureValueType" : "DOUBLE",
"SourceColumn" : "max_1h",
"TargetMeasureName" : "maxMemUsed"
},
{
"MeasureName" : "cpu_user",
"MeasureValueType" : "DOUBLE",
"SourceColumn" : "max_1h"
},
{
"MeasureName" : "cpu_system",
"MeasureValueType" : "DOUBLE",
"SourceColumn" : "max_1h"
}
]
}
},
"ErrorReportConfiguration": {
"S3Configuration" : {
"BucketName" : "******",
"ObjectKeyPrefix": "errors",
"EncryptionOption": "SSE_S3"
}
}
}
```
Di seguito è riportato lo schema per la tabella di destinazione una volta materializzata questa query pianificata. Come si può vedere dallo schema, la tabella utilizza record a misura singola. Se si elenca lo schema di misure per la tabella, verranno visualizzate le nove misure scritte in base alla mappatura fornita nelle specifiche.
| Colonna | Tipo | Timestream per il tipo di attributo LiveAnalytics |
| --- | --- | --- |
| region | varchar | DIMENSIONE |
| measure\$1name | varchar | MEASURE\$1NAME |
| time | timestamp | TIMESTAMP |
| measure\$1value::double | virgola mobile a doppia precisione | MISURA\$1VALORE |
Di seguito sono riportate le misure corrispondenti ottenute con una query SHOW MEASURES.
| measure\$1name | data\$1type | Dimensioni |
| --- | --- | --- |
| AvgMemCached | virgola mobile a doppia precisione | [\$1'dimension\$1name': 'region', 'data\$1type': 'varchar'\$1] |
| MinMemFree | virgola mobile a doppia precisione | [\$1'dimension\$1name': 'regione', 'data\$1type': 'varchar'\$1] |
| cpu\$1idle | virgola mobile a doppia precisione | [\$1'dimension\$1name': 'regione', 'data\$1type': 'varchar'\$1] |
| sistema\$1cpu | virgola mobile a doppia precisione | [\$1'dimension\$1name': 'regione', 'data\$1type': 'varchar'\$1] |
| cpu\$1user | virgola mobile a doppia precisione | [\$1'dimension\$1name': 'regione', 'data\$1type': 'varchar'\$1] |
| disk\$1free | virgola mobile a doppia precisione | [\$1'dimension\$1name': 'regione', 'data\$1type': 'varchar'\$1] |
| disk\$1used | virgola mobile a doppia precisione | [\$1'dimension\$1name': 'regione', 'data\$1type': 'varchar'\$1] |
| maxMemUsed | virgola mobile a doppia precisione | [\$1'dimension\$1name': 'regione', 'data\$1type': 'varchar'\$1] |
| total-disk-io-writes | virgola mobile a doppia precisione | [\$1'dimension\$1name': 'regione', 'data\$1type': 'varchar'\$1] |
## Esempio: mappatura dei risultati su record a misura singola con colonne di risultati di query come nomi di misure
In questo esempio, si dispone di una query i cui risultati non hanno una colonna con il nome della misura. Al contrario, si desidera utilizzare il nome della colonna dei risultati della query come nome della misura quando si esegue la mappatura dell'output su record a misura singola. In precedenza c'era un esempio in cui un risultato simile veniva scritto su un record a più misure. In questo esempio, vedrete come mapparlo su record a misura singola, se ciò si adatta allo scenario dell'applicazione.
Ancora una volta, si specifica questa mappatura utilizzando la MixedMeasureMappings proprietà in. TargetConfiguration TimestreamConfiguration. Nell'esempio seguente, si vede che il risultato della query ha nove colonne. Le colonne dei risultati vengono utilizzate come nomi di misure e i valori come valori di singola misura.
Ad esempio, per una determinata riga del risultato della query, il nome di colonna avg\$1mem\$1cached\$11h viene utilizzato come nome della colonna e valore associato alla colonna e avg\$1mem\$1cached\$11h viene utilizzato come valore di misura per il record a misura singola. È inoltre possibile utilizzare TargetMeasureName un nome di misura diverso nella tabella di destinazione. Ad esempio, per i valori nella colonna sum\$11h, la mappatura specifica di utilizzare total\$1disk\$1io\$1writes\$11h come nome della misura nella tabella di destinazione. Se il valore di una colonna è NULL, la misura corrispondente viene ignorata.
```
{
"Name" : "SingleMeasureMappingWithoutMeasureNameColumnInQueryResult",
"QueryString" : "SELECT region, bin(time, 1h) as hour, AVG(CASE WHEN measure_name = 'memory_cached' THEN measure_value::double ELSE NULL END) as avg_mem_cached_1h, AVG(CASE WHEN measure_name = 'disk_used' THEN measure_value::double ELSE NULL END) as avg_disk_used_1h, AVG(CASE WHEN measure_name = 'disk_free' THEN measure_value::double ELSE NULL END) as avg_disk_free_1h, MIN(CASE WHEN measure_name = 'memory_free' THEN measure_value::double ELSE NULL END) as min_mem_free_1h, MIN(CASE WHEN measure_name = 'cpu_idle' THEN measure_value::double ELSE NULL END) as min_cpu_idle_1h, SUM(CASE WHEN measure_name = 'disk_io_writes' THEN measure_value::double ELSE NULL END) as sum_1h, MAX(CASE WHEN measure_name = 'memory_used' THEN measure_value::double ELSE NULL END) as max_mem_used_1h, MAX(CASE WHEN measure_name = 'cpu_user' THEN measure_value::double ELSE NULL END) as max_cpu_user_1h, MAX(CASE WHEN measure_name = 'cpu_system' THEN measure_value::double ELSE NULL END) as max_cpu_system_1h FROM raw_data.devops WHERE time BETWEEN bin(@scheduled_runtime, 1h) - 14h AND bin(@scheduled_runtime, 1h) - 2h AND measure_name IN ('memory_free', 'memory_used', 'memory_cached', 'disk_io_writes', 'disk_used', 'disk_free', 'cpu_user', 'cpu_system', 'cpu_idle') GROUP BY region, bin(time, 1h)",
"ScheduleConfiguration" : {
"ScheduleExpression" : "cron(0 0/1 * * ? *)"
},
"NotificationConfiguration" : {
"SnsConfiguration" : {
"TopicArn" : "******"
}
},
"ScheduledQueryExecutionRoleArn": "******",
"TargetConfiguration": {
"TimestreamConfiguration": {
"DatabaseName" : "derived",
"TableName" : "dashboard_metrics_1h_agg_5",
"TimeColumn" : "hour",
"DimensionMappings" : [
{
"Name": "region",
"DimensionValueType" : "VARCHAR"
}
],
"MixedMeasureMappings" : [
{
"MeasureValueType" : "DOUBLE",
"SourceColumn" : "avg_mem_cached_1h"
},
{
"MeasureValueType" : "DOUBLE",
"SourceColumn" : "avg_disk_used_1h"
},
{
"MeasureValueType" : "DOUBLE",
"SourceColumn" : "avg_disk_free_1h"
},
{
"MeasureValueType" : "DOUBLE",
"SourceColumn" : "min_mem_free_1h"
},
{
"MeasureValueType" : "DOUBLE",
"SourceColumn" : "min_cpu_idle_1h"
},
{
"MeasureValueType" : "DOUBLE",
"SourceColumn" : "sum_1h",
"TargetMeasureName" : "total_disk_io_writes_1h"
},
{
"MeasureValueType" : "DOUBLE",
"SourceColumn" : "max_mem_used_1h"
},
{
"MeasureValueType" : "DOUBLE",
"SourceColumn" : "max_cpu_user_1h"
},
{
"MeasureValueType" : "DOUBLE",
"SourceColumn" : "max_cpu_system_1h"
}
]
}
},
"ErrorReportConfiguration": {
"S3Configuration" : {
"BucketName" : "******",
"ObjectKeyPrefix": "errors",
"EncryptionOption": "SSE_S3"
}
}
}
```
Di seguito è riportato lo schema per la tabella di destinazione una volta materializzata questa query pianificata. Come puoi vedere, la tabella di destinazione memorizza record con valori a misura singola di tipo double. Analogamente, lo schema delle misure per la tabella mostra i nomi delle nove misure. Notate inoltre che il nome della misura total\$1disk\$1io\$1writes\$11h è presente sin dalla mappatura rinominata sum\$11h in total\$1disk\$1io\$1writes\$11h.
| Colonna | Tipo | LiveAnalytics Timestream per il tipo di attributo |
| --- | --- | --- |
| region | varchar | DIMENSIONE |
| measure\$1name | varchar | MEASURE\$1NAME |
| time | timestamp | TIMESTAMP |
| measure\$1value::double | virgola mobile a doppia precisione | MISURA\$1VALORE |
Di seguito sono riportate le misure corrispondenti ottenute con una query SHOW MEASURES.
| measure\$1name | data\$1type | Dimensioni |
| --- | --- | --- |
| avg\$1disk\$1free\$11h | virgola mobile a doppia precisione | [\$1'dimension\$1name': 'regione', 'tipo\$1dati': 'varchar'\$1] |
| avg\$1disk\$1used\$11h | virgola mobile a doppia precisione | [\$1'dimension\$1name': 'regione', 'tipo\$1dati': 'varchar'\$1] |
| avg\$1mem\$1cached\$11h | virgola mobile a doppia precisione | [\$1'dimension\$1name': 'regione', 'tipo\$1dati': 'varchar'\$1] |
| max\$1cpu\$1system\$11h | virgola mobile a doppia precisione | [\$1'dimension\$1name': 'regione', 'tipo\$1dati': 'varchar'\$1] |
| max\$1cpu\$1user\$11h | virgola mobile a doppia precisione | [\$1'dimension\$1name': 'regione', 'tipo\$1dati': 'varchar'\$1] |
| max\$1mem\$1used\$11h | virgola mobile a doppia precisione | [\$1'dimension\$1name': 'regione', 'tipo\$1dati': 'varchar'\$1] |
| min\$1cpu\$1idle\$11h | virgola mobile a doppia precisione | [\$1'dimension\$1name': 'regione', 'tipo\$1dati': 'varchar'\$1] |
| min\$1mem\$1free\$11h | virgola mobile a doppia precisione | [\$1'dimension\$1name': 'regione', 'tipo\$1dati': 'varchar'\$1] |
| total-disk-io-writes | virgola mobile a doppia precisione | [\$1'dimension\$1name': 'regione', 'data\$1type': 'varchar'\$1] |
# Messaggi di notifica delle interrogazioni pianificate
Questa sezione descrive i messaggi inviati da Timestream per la LiveAnalytics creazione, l'eliminazione, l'esecuzione o l'aggiornamento dello stato di una query pianificata.
| Nome del messaggio di notifica | Struttura | Description |
| --- | --- | --- |
| CreatingNotificationMessage | CreatingNotificationMessage {
String arn;
NotificationType type;
} | Questo messaggio di notifica viene inviato prima dell'invio della risposta per`CreateScheduledQuery`. La query pianificata viene abilitata dopo l'invio di questa notifica. *arn* - L'ARN della query pianificata che viene creata. *tipo* - SCHEDULED\$1QUERY\$1CREATING |
| UpdateNotificationMessage | UpdateNotificationMessage {
String arn;
NotificationType type;
QueryState state;
} | Questo messaggio di notifica viene inviato quando viene aggiornata una query pianificata. Timestream for LiveAnalytics può disabilitare automaticamente la query pianificata, nel caso in cui si verifichi un errore non recuperabile, ad esempio: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/timestream/latest/developerguide/scheduledqueries-notification.html) *arn* - L'ARN della query pianificata che viene aggiornata. *tipo* - SCHEDULED\$1QUERY\$1UPDATE *stato*: ABILITATO o DISABILITATO |
| DeleteNotificationMessage | DeletionNotificationMessage {
String arn;
NotificationType type;
} | Questo messaggio di notifica viene inviato quando viene eliminata una query pianificata. *arn* - L'ARN della query pianificata che viene creata. *tipo* - SCHEDULED\$1QUERY\$1DELETED |
| SuccessNotificationMessage | SuccessNotificationMessage {
NotificationType type;
String arn;
Date nextInvocationEpochSecond;
ScheduledQueryRunSummary runSummary;
}
ScheduledQueryRunSummary {
Date invocationTime;
Date triggerTime;
String runStatus;
ExecutionStats executionstats;
ErrorReportLocation errorReportLocation;
String failureReason;
}
ExecutionStats {
Long bytesMetered;
Long dataWrites;
Long queryResultRows;
Long recordsIngested;
Long executionTimeInMillis;
}
ErrorReportLocation {
S3ReportLocation s3ReportLocation;
}
S3ReportLocation {
String bucketName;
String objectKey;
} | Questo messaggio di notifica viene inviato dopo l'esecuzione della query pianificata e l'inserimento dei risultati è stato completato correttamente. *ARN*: l'ARN della query pianificata che viene eliminata. *NotificationType*- AUTO\$1TRIGGER\$1SUCCESS o MANUAL\$1TRIGGER\$1SUCCESS. *nextInvocationEpochSecondo: la* prossima volta che Timestream for eseguirà la query pianificata. LiveAnalytics *RunSummary*: informazioni sull'esecuzione pianificata della query. |
| FailureNotificationMessage | FailureNotificationMessage {
NotificationType type;
String arn;
ScheduledQueryRunSummary runSummary;
}
ScheduledQueryRunSummary {
Date invocationTime;
Date triggerTime;
String runStatus;
ExecutionStats executionstats;
ErrorReportLocation errorReportLocation;
String failureReason;
}
ExecutionStats {
Long bytesMetered;
Long dataWrites;
Long queryResultRows;
Long recordsIngested;
Long executionTimeInMillis;
}
ErrorReportLocation {
S3ReportLocation s3ReportLocation;
}
S3ReportLocation {
String bucketName;
String objectKey;
} | Questo messaggio di notifica viene inviato quando si verifica un errore durante l'esecuzione di una query pianificata o durante l'acquisizione dei risultati della query. *arn* - L'ARN della query pianificata che viene eseguita. *tipo* - AUTO\$1TRIGGER\$1FAILURE o MANUAL\$1TRIGGER\$1FAILURE. *RunSummary: informazioni sull'esecuzione pianificata della query.* |
# Rapporti sugli errori delle query pianificate
Questa sezione descrive la posizione, il formato e i motivi delle segnalazioni di errori generate da Timestream relative agli errori rilevati LiveAnalytics durante l'esecuzione di query pianificate.
**Topics**
+ [Motivi](#scheduled-queries-error-report-reasons)
+ [Location (Ubicazione)](#scheduled-queries-error-report-location)
+ [Formato](#scheduled-queries-error-report-format)
+ [Tipi di errore](#scheduled-queries-error-report-error-types)
+ [Esempio](#scheduled-queries-error-report-example)
## I motivi delle segnalazioni di errore delle query pianificate
I report sugli errori vengono generati per errori ripristinabili. I report sugli errori non vengono generati per errori non recuperabili. Timestream for LiveAnalytics può disabilitare automaticamente le query pianificate quando si verificano errori non recuperabili. Ciò include:
+ `AssumeRole`fallimento
+ Eventuali errori 4xx riscontrati durante la comunicazione con KMS quando viene specificata una chiave KMS gestita dal cliente
+ Eventuali errori 4xx riscontrati durante l'esecuzione di una query pianificata
+ Eventuali errori 4xx riscontrati durante l'inserimento dei risultati della query
Per gli errori non recuperabili, Timestream for LiveAnalytics invia una notifica di errore con un messaggio di errore non recuperabile. Viene inoltre inviata una notifica di aggiornamento che indica che la query pianificata è disabilitata.
## Posizione dei report di errore delle interrogazioni pianificate
La posizione di segnalazione degli errori di interrogazione pianificata ha la seguente convenzione di denominazione:
```
s3://customer-bucket/customer-prefix/
```
Di seguito è riportato un esempio di query pianificata ARN:
```
arn:aws:timestream:us-east-1:000000000000:scheduled-query/test-query-hd734tegrgfd
```
```
s3://customer-bucket/customer-prefix/test-query-hd734tegrgfd///
```
*Auto*indica le query pianificate automaticamente da Timestream per LiveAnalytics e *Manual* indica le query pianificate attivate manualmente da un utente tramite un'azione API `ExecuteScheduledQuery` in Amazon Timestream for Query. LiveAnalytics Per ulteriori informazioni su `ExecuteScheduledQuery`, consultare [ExecuteScheduledQuery](https://docs.aws.amazon.com/timestream/latest/developerguide/API_query_ExecuteScheduledQuery.html).
## Formato dei report sugli errori delle query pianificate
Le segnalazioni di errore hanno il seguente formato JSON:
```
{
"reportId": , // A unique string ID for all error reports belonging to a particular scheduled query run
"errors": [ , ... ], // One or more errors
}
```
## Tipi di errori di interrogazione pianificati
L'`Error`oggetto può essere di tre tipi:
+ Registra gli errori di inserimento
```
{
"reason": , // The error message String
"records": [ , ... ], // One or more rejected records )
}
```
+ Errori di analisi e convalida delle righe
```
{
"reason": , // The error message String
"rawLine": , // [Optional] The raw line String that is being parsed into record(s) to be ingested. This line has encountered the above-mentioned parse error.
}
```
+ Errori generali
```
{
"reason": , // The error message
}
```
## Esempio di report sugli errori di interrogazione pianificata
Di seguito è riportato un esempio di segnalazione di errori prodotta a causa di errori di inserimento.
```
{
"reportId": "C9494AABE012D1FBC162A67EA2C18255",
"errors": [
{
"reason": "The record timestamp is outside the time range [2021-11-12T14:18:13.354Z, 2021-11-12T16:58:13.354Z) of the memory store.",
"records": [
{
"dimensions": [
{
"name": "dim0",
"value": "d0_1",
"dimensionValueType": null
},
{
"name": "dim1",
"value": "d1_1",
"dimensionValueType": null
}
],
"measureName": "random_measure_value",
"measureValue": "3.141592653589793",
"measureValues": null,
"measureValueType": "DOUBLE",
"time": "1637166175635000000",
"timeUnit": "NANOSECONDS",
"version": null
},
{
"dimensions": [
{
"name": "dim0",
"value": "d0_2",
"dimensionValueType": null
},
{
"name": "dim1",
"value": "d1_2",
"dimensionValueType": null
}
],
"measureName": "random_measure_value",
"measureValue": "6.283185307179586",
"measureValues": null,
"measureValueType": "DOUBLE",
"time": "1637166175636000000",
"timeUnit": "NANOSECONDS",
"version": null
},
{
"dimensions": [
{
"name": "dim0",
"value": "d0_3",
"dimensionValueType": null
},
{
"name": "dim1",
"value": "d1_3",
"dimensionValueType": null
}
],
"measureName": "random_measure_value",
"measureValue": "9.42477796076938",
"measureValues": null,
"measureValueType": "DOUBLE",
"time": "1637166175637000000",
"timeUnit": "NANOSECONDS",
"version": null
},
{
"dimensions": [
{
"name": "dim0",
"value": "d0_4",
"dimensionValueType": null
},
{
"name": "dim1",
"value": "d1_4",
"dimensionValueType": null
}
],
"measureName": "random_measure_value",
"measureValue": "12.566370614359172",
"measureValues": null,
"measureValueType": "DOUBLE",
"time": "1637166175638000000",
"timeUnit": "NANOSECONDS",
"version": null
}
]
}
]
}
```
# Modelli ed esempi di interrogazioni pianificate
Questa sezione descrive i modelli di utilizzo per le query pianificate e end-to-end alcuni esempi.
**Topics**
+ [Schema di esempio](scheduledqueries-common-schema-example.md)
+ [Pattern](scheduledqueries-patterns.md)
+ [Esempi](scheduledqueries-examples.md)
# Schema di esempio per le interrogazioni pianificate
In questo esempio utilizzeremo un'applicazione di esempio che imita uno DevOps scenario di monitoraggio delle metriche di un'ampia flotta di server. Gli utenti desiderano avvisare sull'utilizzo anomalo delle risorse, creare dashboard sul comportamento e sull'utilizzo aggregati della flotta ed eseguire analisi sofisticate su dati recenti e storici per trovare correlazioni. Il diagramma seguente fornisce un'illustrazione della configurazione in cui un insieme di istanze monitorate emette metriche a Timestream for. LiveAnalytics Un altro gruppo di utenti simultanei invia query per avvisi, dashboard o analisi ad hoc, in cui le query e l'inserimento vengono eseguite in parallelo.
![\[Diagram showing data flow from servers to Timestream database, with users querying for analytics.\]](http://docs.aws.amazon.com/it_it/timestream/latest/developerguide/images/schedquery_common_schema_example.png)
L'applicazione monitorata è modellata come un servizio altamente scalabile distribuito in diverse regioni del mondo. Ogni regione è ulteriormente suddivisa in una serie di unità di scala chiamate celle che presentano un livello di isolamento in termini di infrastruttura all'interno della regione. Ogni cella è ulteriormente suddivisa in silos, che rappresentano un livello di isolamento del software. Ogni silo dispone di cinque microservizi che comprendono un'istanza isolata del servizio. Ogni microservizio dispone di diversi server con diversi tipi di istanze e versioni del sistema operativo, che vengono distribuiti in tre zone di disponibilità. [Questi attributi che identificano i server che emettono le metriche sono modellati come dimensioni in Timestream for.](https://docs.aws.amazon.com/timestream/latest/developerguide/concepts.html) LiveAnalytics In questa architettura, abbiamo una gerarchia di dimensioni (come region, cell, silo e microservice\$1name) e altre dimensioni che attraversano la gerarchia (come instance\$1type e availability\$1zone).
L'applicazione emette una varietà di metriche (come cpu\$1user e memory\$1free) ed eventi (come task\$1completed e gc\$1reclaimed). Ogni metrica o evento è associato a otto dimensioni (come regione o cella) che identificano in modo univoco il server che lo emette. I dati vengono scritti con le 20 metriche archiviate insieme in un record multimisura con metriche relative ai nomi delle misure e tutti e 5 gli eventi vengono archiviati insieme in un altro record multimisura con eventi relativi ai nomi delle misure. [Il modello di dati, lo schema e la generazione dei dati sono disponibili nel generatore di dati open source.](https://github.com/awslabs/amazon-timestream-tools/tree/mainline/tools/python/perf-scale-workload) Oltre allo schema e alle distribuzioni dei dati, il generatore di dati fornisce un esempio di utilizzo di più scrittori per inserire dati in parallelo, utilizzando la scalabilità di ingestione di Timestream per importare milioni di misurazioni LiveAnalytics al secondo. Di seguito mostriamo lo schema (tabella e schema di misura) e alcuni dati di esempio dal set di dati.
**Topics**
+ [Record multimisura](#scheduledqueries-common-schema-example-mmr)
+ [Record a misura singola](#scheduledqueries-common-schema-example-smr)
## Record multimisura
**Schema della tabella**
Di seguito è riportato lo schema della tabella una volta che i dati vengono inseriti utilizzando record multimisura. È l'output della query DESCRIBE. Supponendo che i dati vengano inseriti in un database raw\$1data e nella tabella devops, di seguito è riportata la query.
```
DESCRIBE "raw_data"."devops"
```
| Colonna | Tipo | LiveAnalytics Timestream per il tipo di attributo |
| --- | --- | --- |
| availability\$1zone | varchar | DIMENSIONE |
| microservice\$1name | varchar | DIMENSIONE |
| nome\$1istanza | varchar | DIMENSIONE |
| nome\$1processo | varchar | DIMENSIONE |
| os\$1version | varchar | DIMENSIONE |
| versione jdk | varchar | DIMENSIONE |
| cellula | varchar | DIMENSIONE |
| region | varchar | DIMENSIONE |
| silo | varchar | DIMENSIONE |
| instance\$1type | varchar | DIMENSIONE |
| measure\$1name | varchar | MEASURE\$1NAME |
| time | timestamp | TIMESTAMP |
| senza memoria | virgola mobile a doppia precisione | MULTIPLO |
| cpu\$1steal | virgola mobile a doppia precisione | MULTI |
| cpu\$1iowait | virgola mobile a doppia precisione | MULTI |
| cpu\$1user | virgola mobile a doppia precisione | MULTI |
| memoria\$1memorizzata | virgola mobile a doppia precisione | MULTI |
| disk\$1io\$1reads | virgola mobile a doppia precisione | MULTIPLO |
| cpu\$1hi | virgola mobile a doppia precisione | MULTI |
| latenza\$1per\$1lettura | virgola mobile a doppia precisione | MULTI |
| network\$1bytes\$1out | virgola mobile a doppia precisione | MULTIPLO |
| cpu\$1idle | virgola mobile a doppia precisione | MULTI |
| disk\$1free | virgola mobile a doppia precisione | MULTI |
| memoria\$1usata | virgola mobile a doppia precisione | MULTIPLO |
| sistema\$1CPU | virgola mobile a doppia precisione | MULTIPLO |
| descrittori di file in uso | virgola mobile a doppia precisione | MULTIPLO |
| disk\$1used | virgola mobile a doppia precisione | MULTI |
| cpu\$1nice | virgola mobile a doppia precisione | MULTI |
| disk\$1io\$1write | virgola mobile a doppia precisione | MULTI |
| cpu\$1si | virgola mobile a doppia precisione | MULTI |
| latenza\$1per\$1scrittura | virgola mobile a doppia precisione | MULTI |
| bytes\$1in di rete | virgola mobile a doppia precisione | MULTIPLO |
| stato\$1finale dell'attività | varchar | MULTIPLO |
| gc\$1pause | virgola mobile a doppia precisione | MULTI |
| task\$1completato | bigint | MULTIPLO |
| gc\$1reclaimed | virgola mobile a doppia precisione | MULTI |
**Schema di misura**
Di seguito è riportato lo schema di misura restituito dalla query SHOW MEASURES.
```
SHOW MEASURES FROM "raw_data"."devops"
```
| measure\$1name | data\$1type | Dimensioni |
| --- | --- | --- |
| eventi | multi | [\$1"data\$1type» :"varchar», "dimension\$1name» :"availability\$1zone "\$1, \$1" data\$1type» :"varchar», "dimension\$1name» :"microservice\$1name "\$1, \$1" data\$1type» :"varchar», "dimension\$1name» :"nome\$1istanza "\$1, \$1" tipo\$1dati» :"varchar» :"varchar» :"nome\$1istanza "\$1, \$1" tipo\$1dati» :"varchar»», "dimension\$1name» :"process\$1name "\$1, \$1" data\$1type» :"varchar», "dimension\$1name» :"jdk\$1version "\$1, \$1" data\$1type» :"varchar», "dimension\$1name» :"cell "\$1, \$1" data\$1type» :"varchar», "dimension\$1name» :"region "\$1, \$1" tipo\$1dati» :"varchar», "dimension\$1name» :"region "\$1, \$1" tipo\$1dati» :"varchar», "dimension\$1name» :"region "\$1, \$1" tipo\$1dati» :"varchar»» :"varchar», "nome\$1dimensione» :"silo "\$1] |
| metriche | multi | [\$1"data\$1type» :"varchar», "dimension\$1name» :"availability\$1zone "\$1, \$1" data\$1type» :"varchar», "dimension\$1name» :"microservice\$1name "\$1, \$1" data\$1type» :"varchar», "dimension\$1name» :"nome\$1istanza "\$1, \$1" tipo\$1dati» :"varchar» :"varchar» :"nome\$1istanza "\$1, \$1" tipo\$1dati» :"varchar»», "dimension\$1name» :"os\$1version "\$1, \$1" data\$1type» :"varchar», "dimension\$1name» :"cell "\$1, \$1" data\$1type» :"varchar», "dimension\$1name» :"region "\$1, \$1" data\$1type» :"varchar», "dimension\$1name» :"silo "\$1, \$1" tipo\$1dati» :"varchar» :"dimension\$1name» :"silo "\$1, \$1" tipo\$1dati» :"varchar» :"dimension\$1name» :"silo "\$1, \$1" tipo\$1dati» :"varchar» :"dimension\$1name» :"silo "\$1, \$1" tipo\$1dati» :"varchar» :"dimension\$1name» :"silo "\$1 «varchar», "nome\$1dimensione» :"tipo\$1istanza "\$1] |
**Dati di esempio**
| region | Cella | Silo | availability\$1zone | nome\$1servizio | nome\$1istanza | instance\$1type | os\$1version | nome\$1processo | versione jdk | measure\$1name | Orario | cpu\$1user | sistema\$1cpu | cpu\$1idle | cpu\$1steal | cpu\$1iowait | cpu\$1nice | cpu\$1hi | cpu\$1si | memoria\$1usata | memoria\$1memorizzata nella cache | disk\$1io\$1reads | latenza\$1per\$1lettura | disk\$1io\$1write | latenza\$1per\$1scrittura | disk\$1used | disk\$1free | bytes\$1in di rete | network\$1bytes\$1out | descrizioni\$1di\$1file in uso | senza memoria | stato\$1finale dell'attività | gc\$1pause | task\$1completato | gc\$1reclaimed |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| us-east-2 | us-east-2-cell-1 | us-east-2-celle-1-silo-2 | Stati Uniti est-2-1 | atena | i- - zaZswmJk -2-cell-1-silo-2-00000216.amazonaws.com athena-us-east | m5.8xlarge | AL2012 | | | metriche | 12/11/2021 12:43 | 62,8 | 0,408 | 34.2 | 0,972 | 0,0877 | 0,103 | 0,567 | 0,844 | 57,6 | 88,9 | 52,6 | 91,9 | 31,7 | 2,25 | 63,5 | 29,2 | 85,3 | 49,8 | 32,3 | 57,6 | | | | |
| us-east-2 | us-east-2-cell-1 | us-east-2-celle-1-silo-2 | Stati Uniti est-2-1 | atena | i- - zaZswmJk -2-cell-1-silo-2-00000216.amazonaws.com athena-us-east | m5.8xlarge | AL2012 | | | metriche | 12/11/2021 12:41 | 56 | 0,923 | 39,9 | 0,799 | 0,532 | 0,655 | 0,851 | 0,317 | 90,5 | 31,9 | 56,6 | 37,1 | 25 | 93,3 | 52,2 | 33,1 | 7,14 | 53,7 | 65,9 | 20,4 | | | | |
| us-east-2 | us-east-2-cell-1 | us-east-2-celle-1-silo-2 | Stati Uniti est-2-1 | atena | i- - zaZswmJk -2-cell-1-silo-2-00000216.amazonaws.com athena-us-east | m5.8xlarge | AL2012 | | | metriche | 12/11/2021 12:39 | 48,5 | 0,801 | 48,2 | 0,18 | 0,943 | 0,0316 | 0,844 | 0,54 | 97,4 | 41,4 | 55,1 | 32,7 | 86,2 | 33,7 | 72,7 | 61,5 | 80,8 | 5,15 | 44,3 | 8,5 | | | | |
| us-east-2 | us-east-2-cell-1 | us-east-2-celle-1-silo-2 | Stati Uniti est-2-1 | atena | i- - zaZswmJk -2-cell-1-silo-2-00000216.amazonaws.com athena-us-east | m5.8xlarge | AL2012 | | | metriche | 12/11/2021 12:38 | 37,5 | 0,723 | 58,8 | 0,317 | 0,608 | 0,859 | 0,791 | 0,3393 | 4,84 | 78,9 | 20,3 | 41,4 | 46,8 | 3,87 | 84,6 | 60,6 | 21,1 | 11.8 | 2,76 | 10 | | | | |
| us-east-2 | us-east-2-cell-1 | us-east-2-celle-1-silo-2 | Stati Uniti est-2-1 | atena | i- - zaZswmJk -2-cell-1-silo-2-00000216.amazonaws.com athena-us-east | m5.8xlarge | AL2012 | | | metriche | 12/11/2021 12:36 | 58 | 0,786 | 38,7 | 0.219 | 0,436 | 0,829 | 0,331 | 0,734 | 51 | 36,8 | 81,8 | 50,5 | 77,9 | 17,8 | 82,3 | 64 | 7,69 | 66,5 | 56,2 | 31,3 | | | | |
| us-east-2 | us-east-2-cell-1 | us-east-2-celle-1-silo-2 | Stati Uniti est-2-1 | atena | i- - zaZswmJk -2-cell-1-silo-2-00000216.amazonaws.com athena-us-east | | | host\$1manager | JDK\$18 | eventi | 12/11/2021 12:43 | | | | | | | | | | | | | | | | | | | | 75,8 | SUCCESSO\$1CON\$1NO\$1RISULTATO | 85,5 | 348 | 64,8 |
| us-east-2 | us-east-2-cell-1 | us-east-2-celle-1-silo-2 | Stati Uniti est-2-1 | atena | i- - zaZswmJk -2-cell-1-silo-2-00000216.amazonaws.com athena-us-east | | | host\$1manager | JDK\$18 | eventi | 12/11/2021 12:41 | | | | | | | | | | | | | | | | | | | | 7,47 | SUCCESSO\$1CON\$1RISULTATO | 22.8 | 42 | 7,45 |
| us-east-2 | us-east-2-cell-1 | us-east-2-celle-1-silo-2 | Stati Uniti est-2-1 | atena | i- - zaZswmJk -2-cell-1-silo-2-00000216.amazonaws.com athena-us-east | | | host\$1manager | JDK\$18 | eventi | 12/11/2021 12:39 | | | | | | | | | | | | | | | | | | | | 64,1 | SUCCESSO\$1CON\$1RISULTATO | 6.77 | 249 | 72,3 |
| us-east-2 | us-east-2-cell-1 | us-east-2-celle-1-silo-2 | Stati Uniti est-2-1 | atena | i- - zaZswmJk -2-cell-1-silo-2-00000216.amazonaws.com athena-us-east | | | host\$1manager | JDK\$18 | eventi | 12/11/2021 12:38 | | | | | | | | | | | | | | | | | | | | 23 | SUCCESSO\$1CON\$1RISULTATO | 53,3 | 138 | 99 |
| us-east-2 | us-east-2-cell-1 | us-east-2-celle-1-silo-2 | Stati Uniti est-2-1 | atena | i- - zaZswmJk -2-cell-1-silo-2-00000216.amazonaws.com athena-us-east | | | host\$1manager | JDK\$18 | eventi | 12/11/2021 12:36 | | | | | | | | | | | | | | | | | | | | 39,4 | SUCCESSO\$1CON\$1NO\$1RISULTATO | 79,6 | 254 | 82,9 |
## Record a misura singola
Timestream for consente LiveAnalytics inoltre di inserire i dati con una misura per record di serie temporali. Di seguito sono riportati i dettagli dello schema quando vengono inseriti utilizzando record a misura singola.
**Schema della tabella**
Di seguito è riportato lo schema della tabella una volta che i dati vengono inseriti utilizzando record multimisura. È l'output della query DESCRIBE. Supponendo che i dati vengano inseriti in un database raw\$1data e nella tabella devops, di seguito è riportata la query.
```
DESCRIBE "raw_data"."devops_single"
```
| Colonna | Tipo | LiveAnalytics Timestream per il tipo di attributo |
| --- | --- | --- |
| availability\$1zone | varchar | DIMENSIONE |
| microservice\$1name | varchar | DIMENSIONE |
| nome\$1istanza | varchar | DIMENSIONE |
| nome\$1processo | varchar | DIMENSIONE |
| os\$1version | varchar | DIMENSIONE |
| versione jdk | varchar | DIMENSIONE |
| cellula | varchar | DIMENSIONE |
| region | varchar | DIMENSIONE |
| silo | varchar | DIMENSIONE |
| instance\$1type | varchar | DIMENSIONE |
| measure\$1name | varchar | MEASURE\$1NAME |
| time | timestamp | TIMESTAMP |
| measure\$1value::double | virgola mobile a doppia precisione | MISURA\$1VALORE |
| measure\$1value::bigint | bigint | MISURA\$1VALORE |
| measure\$1value::varchar | varchar | MISURA\$1VALORE |
**Schema di misura**
Di seguito è riportato lo schema di misura restituito dalla query SHOW MEASURES.
```
SHOW MEASURES FROM "raw_data"."devops_single"
```
| measure\$1name | data\$1type | Dimensioni |
| --- | --- | --- |
| cpu\$1hi | virgola mobile a doppia precisione | [\$1'dimension\$1name': 'availability\$1zone', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'microservice\$1name', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'instance\$1name', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'os\$1version', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'cell', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'region', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'silo', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'varchar'\$1, \$1'dimension\$1name': 'data\$1name': 'varchar'\$1: 'dimension\$1name': 'varchar': 'instance\$1type', 'data\$1type': 'varchar'\$1] |
| cpu\$1idle | virgola mobile a doppia precisione | [\$1'dimension\$1name': 'availability\$1zone', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'microservice\$1name', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'instance\$1name', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'os\$1version', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'cell', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'region', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'silo', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'varchar'\$1, \$1'dimension\$1name': 'data\$1name': 'varchar'\$1: 'dimension\$1name': 'varchar': 'instance\$1type', 'data\$1type': 'varchar'\$1] |
| cpu\$1iowait | virgola mobile a doppia precisione | [\$1'dimension\$1name': 'availability\$1zone', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'microservice\$1name', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'instance\$1name', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'os\$1version', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'cell', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'region', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'silo', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'varchar'\$1, \$1'dimension\$1name': 'data\$1name': 'varchar'\$1: 'dimension\$1name': 'varchar': 'instance\$1type', 'data\$1type': 'varchar'\$1] |
| cpu\$1nice | virgola mobile a doppia precisione | [\$1'dimension\$1name': 'availability\$1zone', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'microservice\$1name', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'instance\$1name', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'os\$1version', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'cell', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'region', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'silo', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'varchar'\$1, \$1'dimension\$1name': 'data\$1name': 'varchar'\$1: 'dimension\$1name': 'varchar': 'instance\$1type', 'data\$1type': 'varchar'\$1] |
| cpu\$1si | virgola mobile a doppia precisione | [\$1'dimension\$1name': 'availability\$1zone', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'microservice\$1name', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'instance\$1name', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'os\$1version', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'cell', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'region', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'silo', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'varchar'\$1, \$1'dimension\$1name': 'data\$1name': 'varchar'\$1: 'dimension\$1name': 'varchar': 'instance\$1type', 'data\$1type': 'varchar'\$1] |
| cpu\$1steal | virgola mobile a doppia precisione | [\$1'dimension\$1name': 'availability\$1zone', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'microservice\$1name', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'instance\$1name', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'os\$1version', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'cell', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'region', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'silo', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'varchar'\$1, \$1'dimension\$1name': 'data\$1name': 'varchar'\$1: 'dimension\$1name': 'varchar': 'instance\$1type', 'data\$1type': 'varchar'\$1] |
| sistema\$1CPU | virgola mobile a doppia precisione | [\$1'dimension\$1name': 'availability\$1zone', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'microservice\$1name', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'instance\$1name', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'os\$1version', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'cell', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'region', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'silo', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'varchar'\$1, \$1'dimension\$1name': 'data\$1name': 'varchar'\$1: 'dimension\$1name': 'varchar': 'instance\$1type', 'data\$1type': 'varchar'\$1] |
| cpu\$1user | virgola mobile a doppia precisione | [\$1'dimension\$1name': 'availability\$1zone', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'microservice\$1name', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'instance\$1name', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'os\$1version', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'cell', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'region', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'silo', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'varchar'\$1, \$1'dimension\$1name': 'data\$1name': 'varchar'\$1: 'dimension\$1name': 'varchar': 'instance\$1type', 'data\$1type': 'varchar'\$1] |
| disk\$1free | virgola mobile a doppia precisione | [\$1'dimension\$1name': 'availability\$1zone', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'microservice\$1name', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'instance\$1name', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'os\$1version', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'cell', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'region', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'silo', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'varchar'\$1, \$1'dimension\$1name': 'data\$1name': 'varchar'\$1: 'dimension\$1name': 'varchar': 'instance\$1type', 'data\$1type': 'varchar'\$1] |
| disk\$1io\$1reads | virgola mobile a doppia precisione | [\$1'dimension\$1name': 'availability\$1zone', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'microservice\$1name', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'instance\$1name', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'os\$1version', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'cell', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'region', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'silo', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'varchar'\$1, \$1'dimension\$1name': 'data\$1name': 'varchar'\$1: 'dimension\$1name': 'varchar': 'instance\$1type', 'data\$1type': 'varchar'\$1] |
| disk\$1io\$1write | virgola mobile a doppia precisione | [\$1'dimension\$1name': 'availability\$1zone', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'microservice\$1name', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'instance\$1name', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'os\$1version', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'cell', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'region', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'silo', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'varchar'\$1, \$1'dimension\$1name': 'data\$1name': 'varchar'\$1: 'dimension\$1name': 'varchar': 'instance\$1type', 'data\$1type': 'varchar'\$1] |
| disk\$1used | virgola mobile a doppia precisione | [\$1'dimension\$1name': 'availability\$1zone', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'microservice\$1name', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'instance\$1name', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'os\$1version', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'cell', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'region', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'silo', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'varchar'\$1, \$1'dimension\$1name': 'data\$1name': 'varchar'\$1: 'dimension\$1name': 'varchar': 'instance\$1type', 'data\$1type': 'varchar'\$1] |
| descrittori di file in uso | virgola mobile a doppia precisione | [\$1'dimension\$1name': 'availability\$1zone', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'microservice\$1name', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'instance\$1name', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'os\$1version', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'cell', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'region', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'silo', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'varchar'\$1, \$1'dimension\$1name': 'data\$1name': 'varchar'\$1: 'dimension\$1name': 'varchar': 'instance\$1type', 'data\$1type': 'varchar'\$1] |
| gc\$1pause | virgola mobile a doppia precisione | [\$1'dimension\$1name': 'availability\$1zone', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'microservice\$1name', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'nome\$1istanza', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'process\$1name': 'process\$1name' ',' data\$1type ':' varchar '\$1, \$1' dimension\$1name ':' jdk\$1version ',' data\$1type ':' varchar '\$1, \$1' dimension\$1name ':' cell ',' data\$1type ':' varchar '\$1, \$1' dimension\$1name ':' region ',' data\$1type ':' varchar '\$1, \$1' dimension\$1name ':' varchar '\$1, \$1' dimension\$1name ':' varchar '\$1, \$1' dimension\$1name ':' varchar '\$1, \$1' dimension\$1name ':' varchar '\$1': 'silo', 'data\$1type': 'varchar'\$1] |
| gc\$1reclaimed | virgola mobile a doppia precisione | [\$1'dimension\$1name': 'availability\$1zone', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'microservice\$1name', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'nome\$1istanza', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'process\$1name': 'process\$1name' ',' data\$1type ':' varchar '\$1, \$1' dimension\$1name ':' jdk\$1version ',' data\$1type ':' varchar '\$1, \$1' dimension\$1name ':' cell ',' data\$1type ':' varchar '\$1, \$1' dimension\$1name ':' region ',' data\$1type ':' varchar '\$1, \$1' dimension\$1name ':' varchar '\$1, \$1' dimension\$1name ':' varchar '\$1, \$1' dimension\$1name ':' varchar '\$1, \$1' dimension\$1name ':' varchar '\$1': 'silo', 'data\$1type': 'varchar'\$1] |
| latenza\$1per\$1lettura | virgola mobile a doppia precisione | [\$1'dimension\$1name': 'availability\$1zone', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'microservice\$1name', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'instance\$1name', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'os\$1version', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'cell', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'region', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'silo', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'varchar'\$1, \$1'dimension\$1name': 'data\$1name': 'varchar'\$1: 'dimension\$1name': 'varchar': 'instance\$1type', 'data\$1type': 'varchar'\$1] |
| latenza\$1per\$1scrittura | virgola mobile a doppia precisione | [\$1'dimension\$1name': 'availability\$1zone', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'microservice\$1name', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'instance\$1name', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'os\$1version', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'cell', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'region', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'silo', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'varchar'\$1, \$1'dimension\$1name': 'data\$1name': 'varchar'\$1: 'dimension\$1name': 'varchar': 'instance\$1type', 'data\$1type': 'varchar'\$1] |
| memoria\$1memorizzata nella cache | virgola mobile a doppia precisione | [\$1'dimension\$1name': 'availability\$1zone', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'microservice\$1name', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'instance\$1name', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'os\$1version', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'cell', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'region', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'silo', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'varchar'\$1, \$1'dimension\$1name': 'data\$1name': 'varchar'\$1: 'dimension\$1name': 'varchar': 'instance\$1type', 'data\$1type': 'varchar'\$1] |
| senza memoria | virgola mobile a doppia precisione | [\$1'dimension\$1name': 'availability\$1zone', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'microservice\$1name', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'nome\$1istanza', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'process\$1name': 'process\$1name' ',' data\$1type ':' varchar '\$1, \$1' dimension\$1name ':' os\$1version ',' data\$1type ':' varchar '\$1, \$1' dimension\$1name ':' jdk\$1version ',' data\$1type ':' varchar '\$1, \$1' dimension\$1name ':' cell ',' data\$1type ':' varchar '\$1, \$1' dimension\$1name ':' cell ',' data\$1type ':' varchar '\$1, \$1' dimension\$1name ':' cell ',' data\$1type ':' varchar '\$1, \$1' dimension\$1name ':' cella ',' data\$1type ':' varchar '\$1, \$1' dimension\$1name ':' cella ',' data\$1type ':' varchar '\$1, \$1' dimension\$1name ':' region ',' data\$1type ':' varchar '\$1, \$1' dimension\$1name ':' silo ',' data\$1type ':' varchar '\$1, \$1' dimension\$1name ':' instance\$1type ', 'data\$1 tipo': 'varchar'\$1] |
| memoria\$1usata | virgola mobile a doppia precisione | [\$1'dimension\$1name': 'availability\$1zone', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'microservice\$1name', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'instance\$1name', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'os\$1version', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'cell', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'region', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'silo', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'varchar'\$1, \$1'dimension\$1name': 'data\$1name': 'varchar'\$1: 'dimension\$1name': 'varchar': 'instance\$1type', 'data\$1type': 'varchar'\$1] |
| bytes\$1in di rete | virgola mobile a doppia precisione | [\$1'dimension\$1name': 'availability\$1zone', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'microservice\$1name', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'instance\$1name', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'os\$1version', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'cell', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'region', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'silo', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'varchar'\$1, \$1'dimension\$1name': 'data\$1name': 'varchar'\$1: 'dimension\$1name': 'varchar': 'instance\$1type', 'data\$1type': 'varchar'\$1] |
| network\$1bytes\$1out | virgola mobile a doppia precisione | [\$1'dimension\$1name': 'availability\$1zone', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'microservice\$1name', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'instance\$1name', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'os\$1version', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'cell', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'region', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'silo', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'varchar'\$1, \$1'dimension\$1name': 'data\$1name': 'varchar'\$1: 'dimension\$1name': 'varchar': 'instance\$1type', 'data\$1type': 'varchar'\$1] |
| attività\$1completata | bigint | [\$1'dimension\$1name': 'availability\$1zone', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'microservice\$1name', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'nome\$1istanza', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'process\$1name': 'process\$1name' ',' data\$1type ':' varchar '\$1, \$1' dimension\$1name ':' jdk\$1version ',' data\$1type ':' varchar '\$1, \$1' dimension\$1name ':' cell ',' data\$1type ':' varchar '\$1, \$1' dimension\$1name ':' region ',' data\$1type ':' varchar '\$1, \$1' dimension\$1name ':' varchar '\$1, \$1' dimension\$1name ':' varchar '\$1, \$1' dimension\$1name ':' varchar '\$1, \$1' dimension\$1name ':' varchar '\$1': 'silo', 'data\$1type': 'varchar'\$1] |
| stato\$1finale dell'attività | varchar | [\$1'dimension\$1name': 'availability\$1zone', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'microservice\$1name', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'nome\$1istanza', 'data\$1type': 'varchar'\$1, \$1'dimension\$1name': 'process\$1name': 'process\$1name' ',' data\$1type ':' varchar '\$1, \$1' dimension\$1name ':' jdk\$1version ',' data\$1type ':' varchar '\$1, \$1' dimension\$1name ':' cell ',' data\$1type ':' varchar '\$1, \$1' dimension\$1name ':' region ',' data\$1type ':' varchar '\$1, \$1' dimension\$1name ':' varchar '\$1, \$1' dimension\$1name ':' varchar '\$1, \$1' dimension\$1name ':' varchar '\$1, \$1' dimension\$1name ':' varchar '\$1': 'silo', 'data\$1type': 'varchar'\$1] |
**Dati di esempio**
| availability\$1zone | microservice\$1name | nome\$1istanza | nome\$1processo | os\$1version | versione jdk | Cella | region | Silo | instance\$1type | measure\$1name | Orario | measure\$1value::double | measure\$1value::bigint | measure\$1value::varchar |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| eu-west-1-1 | ercole | i- - 1-cell-9-silo-2-00000027.amazonaws.com zaZswmJk hercules-eu-west | | AL2012 | | eu-west-1-cell-9 | eu-west-1 | eu-west-1-celle-9-silo-2 | r5.4xlarge | cpu\$1it | 34:57,2 | 0,87169 | | |
| eu-west-1-1 | ercole | i- - 1-cell-9-silo-2-00000027.amazonaws.com zaZswmJk hercules-eu-west | | AL2012 | | eu-west-1-cell-9 | eu-west-1 | eu-west-1-celle-9-silo-2 | r5.4xlarge | cpu\$1idle | 34:57,2 | 3,46266 | | |
| eu-west-1-1 | ercole | i- - 1-cell-9-silo-2-00000027.amazonaws.com zaZswmJk hercules-eu-west | | AL2012 | | eu-west-1-cell-9 | eu-west-1 | eu-west-1-celle-9-silo-2 | r5.4xlarge | cpu\$1iowait | 34:57,2 | 0,10226 | | |
| eu-west-1-1 | ercole | i- - 1-cell-9-silo-2-00000027.amazonaws.com zaZswmJk hercules-eu-west | | AL2012 | | eu-west-1-cell-9 | eu-west-1 | eu-west-1-celle-9-silo-2 | r5.4xlarge | cpu\$1nice | 34:57,2 | 0,63013 | | |
| eu-west-1-1 | ercole | i- - 1-cell-9-silo-2-00000027.amazonaws.com zaZswmJk hercules-eu-west | | AL2012 | | eu-west-1-cell-9 | eu-west-1 | eu-west-1-celle-9-silo-2 | r5.4xlarge | cpu\$1it | 34:57,2 | 0,16441 | | |
| eu-west-1-1 | ercole | i- - 1-cell-9-silo-2-00000027.amazonaws.com zaZswmJk hercules-eu-west | | AL2012 | | eu-west-1-cell-9 | eu-west-1 | eu-west-1-celle-9-silo-2 | r5.4xlarge | cpu\$1steal | 34:57,2 | 0,10729 | | |
| eu-west-1-1 | ercole | i- - 1-cell-9-silo-2-00000027.amazonaws.com zaZswmJk hercules-eu-west | | AL2012 | | eu-west-1-cell-9 | eu-west-1 | eu-west-1-celle-9-silo-2 | r5.4xlarge | sistema\$1cpu | 34:57,2 | 0,45709 | | |
| eu-west-1-1 | ercole | i- - 1-cell-9-silo-2-00000027.amazonaws.com zaZswmJk hercules-eu-west | | AL2012 | | eu-west-1-cell-9 | eu-west-1 | eu-west-1-celle-9-silo-2 | r5.4xlarge | cpu\$1user | 34:57,2 | 94,20448 | | |
| eu-west-1-1 | ercole | i- - 1-cell-9-silo-2-00000027.amazonaws.com zaZswmJk hercules-eu-west | | AL2012 | | eu-west-1-cell-9 | eu-west-1 | eu-west-1-celle-9-silo-2 | r5.4xlarge | disk\$1free | 34:57.2 | 72,51895 | | |
| eu-west-1-1 | ercole | i- - 1-cell-9-silo-2-00000027.amazonaws.com zaZswmJk hercules-eu-west | | AL2012 | | eu-west-1-cell-9 | eu-west-1 | eu-west-1-celle-9-silo-2 | r5.4xlarge | disk\$1io\$1reads | 34:57,2 | 81,73383 | | |
| eu-west-1-1 | ercole | i- - 1-cell-9-silo-2-00000027.amazonaws.com zaZswmJk hercules-eu-west | | AL2012 | | eu-west-1-cell-9 | eu-west-1 | eu-west-1-celle-9-silo-2 | r5.4xlarge | disk\$1io\$1write | 34:57,2 | 77,11665 | | |
| eu-west-1-1 | ercole | i- - 1-cell-9-silo-2-00000027.amazonaws.com zaZswmJk hercules-eu-west | | AL2012 | | eu-west-1-cell-9 | eu-west-1 | eu-west-1-celle-9-silo-2 | r5.4xlarge | disk\$1used | 34:57.2 | 89,4235 | | |
| eu-west-1-1 | ercole | i- - 1-cell-9-silo-2-00000027.amazonaws.com zaZswmJk hercules-eu-west | | AL2012 | | eu-west-1-cell-9 | eu-west-1 | eu-west-1-celle-9-silo-2 | r5.4xlarge | descrizioni\$1di\$1file in uso | 34:57,2 | 30,08254 | | |
| eu-west-1-1 | ercole | i- - 1-cell-9-silo-2-00000027.amazonaws.com zaZswmJk hercules-eu-west | server | | JDK\$18 | eu-west-1-cell-9 | eu-west-1 | eu-west-1-celle-9-silo-2 | | gc\$1pause | 34:57,2 | 60,28679 | | |
| eu-west-1-1 | ercole | i- - 1-cell-9-silo-2-00000027.amazonaws.com zaZswmJk hercules-eu-west | server | | JDK\$18 | eu-west-1-cell-9 | eu-west-1 | eu-west-1-celle-9-silo-2 | | gc\$1reclaimed | 34:57,2 | 75,28839 | | |
| eu-west-1-1 | ercole | i- - 1-cell-9-silo-2-00000027.amazonaws.com zaZswmJk hercules-eu-west | | AL2012 | | eu-west-1-cell-9 | eu-west-1 | eu-west-1-celle-9-silo-2 | r5.4xlarge | latenza\$1per\$1lettura | 34:57,2 | 8,07605 | | |
| eu-west-1-1 | ercole | i- - 1-cell-9-silo-2-00000027.amazonaws.com zaZswmJk hercules-eu-west | | AL2012 | | eu-west-1-cell-9 | eu-west-1 | eu-west-1-celle-9-silo-2 | r5.4xlarge | latenza\$1per\$1scrittura | 34:57,2 | 58,11223 | | |
| eu-west-1-1 | ercole | i- - 1-cell-9-silo-2-00000027.amazonaws.com zaZswmJk hercules-eu-west | | AL2012 | | eu-west-1-cell-9 | eu-west-1 | eu-west-1-celle-9-silo-2 | r5.4xlarge | memoria\$1memorizzata nella cache | 34:57,2 | 87,56481 | | |
| eu-west-1-1 | ercole | i- - 1-cell-9-silo-2-00000027.amazonaws.com zaZswmJk hercules-eu-west | server | | JDK\$18 | eu-west-1-cell-9 | eu-west-1 | eu-west-1-celle-9-silo-2 | | senza memoria | 34:57,2 | 18,95768 | | |
| eu-west-1-1 | ercole | i- - 1-cell-9-silo-2-00000027.amazonaws.com zaZswmJk hercules-eu-west | | AL2012 | | eu-west-1-cell-9 | eu-west-1 | eu-west-1-celle-9-silo-2 | r5.4xlarge | senza memoria | 34:57,2 | 9720523 | | |
| eu-west-1-1 | ercole | i- - 1-cell-9-silo-2-00000027.amazonaws.com zaZswmJk hercules-eu-west | | AL2012 | | eu-west-1-cell-9 | eu-west-1 | eu-west-1-celle-9-silo-2 | r5.4xlarge | memoria\$1usata | 34:57,2 | 12,37723 | | |
| eu-west-1-1 | ercole | i- - 1-cell-9-silo-2-00000027.amazonaws.com zaZswmJk hercules-eu-west | | AL2012 | | eu-west-1-cell-9 | eu-west-1 | eu-west-1-cell-9-silo-2 | r5.4xlarge | network\$1bytes\$1it | 34:57,2 | 31,02065 | | |
| eu-west-1-1 | ercole | i- - 1-cell-9-silo-2-00000027.amazonaws.com zaZswmJk hercules-eu-west | | AL2012 | | eu-west-1-cell-9 | eu-west-1 | eu-west-1-cell-9-silo-2 | r5.4xlarge | network\$1bytes\$1out | 34:57,2 | 0,51424 | | |
| eu-west-1-1 | ercole | i- - 1-cell-9-silo-2-00000027.amazonaws.com zaZswmJk hercules-eu-west | server | | JDK\$18 | eu-west-1-cell-9 | eu-west-1 | eu-west-1-cell-9-silo-2 | | task\$1completato | 34:57.2 | | 69 | |
| eu-west-1-1 | ercole | i- - 1-cell-9-silo-2-00000027.amazonaws.com zaZswmJk hercules-eu-west | server | | JDK\$18 | eu-west-1-cell-9 | eu-west-1 | eu-west-1-cell-9-silo-2 | | stato\$1finale dell'attività | 34:57,2 | | | SUCCESSO\$1CON\$1RISULTATO |
# Schemi di interrogazione pianificati
In questa sezione troverai alcuni modelli comuni su come utilizzare Amazon Timestream LiveAnalytics for Scheduled Queries per ottimizzare i dashboard in modo che vengano caricati più velocemente e a costi ridotti. Gli esempi seguenti utilizzano uno scenario DevOps applicativo per illustrare i concetti chiave che si applicano alle query pianificate in generale, indipendentemente dallo scenario dell'applicazione.
Le query pianificate in Timestream for LiveAnalytics consentono di esprimere le query utilizzando l'intera area di superficie SQL di Timestream for. LiveAnalytics La tua query può includere una o più tabelle di origine, eseguire aggregazioni o qualsiasi altra query consentita dal linguaggio SQL di Timestream for e quindi materializzare i risultati LiveAnalytics della query in un'altra tabella di destinazione in Timestream for. LiveAnalytics *Per facilitare l'esposizione, questa sezione fa riferimento a questa tabella di destinazione di una query pianificata come tabella derivata.*
Di seguito sono riportati i punti chiave trattati in questa sezione.
+ Utilizzo di un semplice aggregato a livello di flotta per spiegare come definire un'interrogazione pianificata e comprendere alcuni concetti di base.
+ Come combinare i risultati della destinazione di una query pianificata (la tabella derivata) con i risultati della tabella di origine per ottenere i vantaggi in termini di costi e prestazioni delle query pianificate.
+ Quali sono i compromessi che si ottengono quando si configura il periodo di aggiornamento delle interrogazioni pianificate.
+ Utilizzo di interrogazioni pianificate per alcuni scenari comuni.
+ Monitoraggio dell'ultimo punto dati di ogni istanza prima di una data specifica.
+ Valori distinti per una dimensione da utilizzare per popolare le variabili in una dashboard.
+ Come gestire i dati in arrivo in ritardo nel contesto delle interrogazioni pianificate.
+ In che modo è possibile utilizzare esecuzioni manuali una tantum per gestire una varietà di scenari non direttamente coperti dai trigger automatici per le query pianificate.
**Topics**
+ [Scenario](scheduledqueries-patterns-scenario.md)
+ [Aggregati semplici a livello di flotta](scheduledqueries-patterns-simplefleet.md)
+ [Ultimo punto di ogni dispositivo](scheduledqueries-patterns-lastpointfromdevice.md)
+ [Valori di dimensione univoci](scheduledqueries-patterns-uniquedimvalues.md)
+ [Gestione dei dati in arrivo tardivo](scheduledqueries-patterns-latearrive.md)
+ [Riempimento dei precalcoli storici](scheduledqueries-patterns-backfilling.md)
# Scenario
Gli esempi seguenti utilizzano uno scenario di DevOps monitoraggio descritto in. [Schema di esempio per le interrogazioni pianificate](scheduledqueries-common-schema-example.md)
Gli esempi forniscono la definizione delle query pianificate in cui è possibile inserire le configurazioni appropriate per ricevere le notifiche sullo stato di esecuzione per le query pianificate, dove ricevere i report sugli errori riscontrati durante l'esecuzione di una query pianificata e il ruolo IAM utilizzato dalla query pianificata per eseguire le sue operazioni.
È possibile creare queste query pianificate dopo aver compilato le opzioni precedenti, aver [creato la tabella di destinazione](https://docs.aws.amazon.com/timestream/latest/developerguide/code-samples.create-table.html) (o derivata) ed eseguirle tramite la AWS CLI. Ad esempio, si supponga che la definizione di una query pianificata sia archiviata in un file,. `scheduled_query_example.json` È possibile creare la query utilizzando il comando CLI.
```
aws timestream-query create-scheduled-query --cli-input-json file://scheduled_query_example.json --profile aws_profile --region us-east-1
```
Nel comando precedente, il profilo passato utilizzando l'opzione --profile deve disporre delle autorizzazioni appropriate per creare query pianificate. Vedi [Politiche basate sull'identità per le interrogazioni pianificate per istruzioni dettagliate sulle politiche](https://docs.aws.amazon.com/timestream/latest/developerguide/security_iam_id-based-policy-examples.html#security_iam_id-based-policy-examples-sheduledqueries) e le autorizzazioni.
# Aggregati semplici a livello di flotta
Questo primo esempio illustra alcuni dei concetti di base relativi all'utilizzo di query pianificate utilizzando un semplice esempio di calcolo degli aggregati a livello di flotta. Utilizzando questo esempio, imparerai quanto segue.
+ Come prendere la query del dashboard utilizzata per ottenere statistiche aggregate e mapparla a una query pianificata.
+ In che modo Timestream for LiveAnalytics gestisce l'esecuzione delle diverse istanze della query pianificata.
+ Come è possibile sovrapporre diverse istanze di query pianificate negli intervalli di tempo e in che modo la correttezza dei dati viene mantenuta nella tabella di destinazione per garantire che la dashboard che utilizza i risultati della query pianificata fornisca risultati corrispondenti allo stesso aggregato calcolato sui dati grezzi.
+ Come impostare l'intervallo di tempo e la cadenza di aggiornamento per la query pianificata.
+ In che modo è possibile monitorare autonomamente i risultati delle query pianificate per ottimizzarle in modo che la latenza di esecuzione delle istanze di query rientri nei ritardi accettabili associati all'aggiornamento delle dashboard.
**Topics**
+ [Aggrega dalle tabelle di origine](#scheduledqueries-patterns-simplefleet-aggrfromsourcetable)
+ [Interrogazione pianificata per precalcolare gli aggregati](#scheduledqueries-patterns-simplefleet-schedtoprecomputeaggr)
+ [Aggregazione da tabella derivata](#scheduledqueries-patterns-simplefleet-aggrfromderived)
+ [Aggregazione che combina tabelle di origine e derivate](#scheduledqueries-patterns-simplefleet-aggrcombsourceandderived)
+ [Aggregazione basata su calcoli pianificati aggiornati di frequente](#scheduledqueries-patterns-simplefleet-aggregatefromrequently)
## Aggrega dalle tabelle di origine
In questo esempio, stai monitorando il numero di metriche emesse dai server all'interno di una determinata regione in ogni minuto. Il grafico seguente è un esempio di rappresentazione di questa serie temporale per la regione us-east-1.
![\[Time series graph showing fluctuating number of metrics emitted by servers in us-east-1 region.\]](http://docs.aws.amazon.com/it_it/timestream/latest/developerguide/images/schedquery_aggrfromsourcetable.png)
Di seguito è riportato un esempio di query per calcolare questo aggregato dai dati grezzi. Filtra le righe per la regione us-east-1 e quindi calcola la somma al minuto tenendo conto delle 20 metriche (se measure\$1name è metrica) o dei 5 eventi (se measure\$1name è eventi). In questo esempio, l'illustrazione del grafico mostra che il numero di metriche emesse varia tra 1,5 milioni e 6 milioni al minuto. Quando si traccia questa serie temporale per diverse ore (le ultime 12 ore in questa figura), questa interrogazione sui dati grezzi analizza centinaia di milioni di righe.
```
WITH grouped_data AS (
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 from_milliseconds(1636699996445) AND from_milliseconds(1636743196445)
AND region = 'us-east-1'
GROUP BY region, measure_name, bin(time, 1m)
)
SELECT minute, SUM(numDataPoints) AS numDataPoints
FROM grouped_data
GROUP BY minute
ORDER BY 1 desc, 2 desc
```
## Interrogazione pianificata per precalcolare gli aggregati
Se desideri ottimizzare i dashboard per velocizzare il caricamento e ridurre i costi scansionando meno dati, puoi utilizzare una query pianificata per precalcolare questi aggregati. Le query pianificate in Timestream for ti LiveAnalytics consentono di materializzare questi precalcoli in un altro Timestream for table, che puoi utilizzare successivamente per i tuoi dashboard. LiveAnalytics
Il primo passaggio per creare una query pianificata consiste nell'identificare la query che si desidera precalcolare. Nota che la dashboard precedente è stata disegnata per la regione us-east-1. Tuttavia, un utente diverso potrebbe desiderare lo stesso aggregato per una regione diversa, ad esempio us-west-2 o eu-west-1. Per evitare di creare un'interrogazione pianificata per ciascuna di queste query, puoi precalcolare l'aggregato per ogni regione e materializzare gli aggregati per regione in un altro Timestream per tabella. LiveAnalytics
La query riportata di seguito fornisce un esempio del precalcolo corrispondente. Come puoi vedere, è simile all'espressione di tabella comune grouped\$1data utilizzata nella query sui dati grezzi, ad eccezione di due differenze: 1) non utilizza un predicato di regione, quindi possiamo usare una query per il precalcolo per tutte le regioni; e 2) utilizza un predicato temporale parametrizzato con un parametro speciale @scheduled\$1runtime, che viene spiegato in dettaglio di seguito.
```
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
```
L'interrogazione precedente può essere convertita in un'interrogazione pianificata utilizzando le seguenti specifiche. All'interrogazione pianificata viene assegnato un nome, che è un mnemonico di facile utilizzo. [Include quindi, a QueryString ScheduleConfiguration, che è un'espressione cron.](https://docs.aws.amazon.com/timestream/latest/developerguide/scheduledqueries-schedule.html) Specifica TargetConfiguration quale mappa i risultati della query alla tabella di destinazione in Timestream for. LiveAnalytics Infine, specifica una serie di altre configurazioni, come la NotificationConfiguration, in cui vengono inviate le notifiche per le singole esecuzioni della query, in cui viene scritto un rapporto nel caso in ErrorReportConfiguration cui la query riscontri errori e la ScheduledQueryExecutionRoleArn, che è il ruolo utilizzato per eseguire le operazioni per la query pianificata.
```
{
"Name": "MultiPT5mPerMinutePerRegionMeasureCount",
"QueryString": "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",
"ScheduleConfiguration": {
"ScheduleExpression": "cron(0/5 * * * ? *)"
},
"NotificationConfiguration": {
"SnsConfiguration": {
"TopicArn": "******"
}
},
"TargetConfiguration": {
"TimestreamConfiguration": {
"DatabaseName": "derived",
"TableName": "per_minute_aggs_pt5m",
"TimeColumn": "minute",
"DimensionMappings": [
{
"Name": "region",
"DimensionValueType": "VARCHAR"
}
],
"MultiMeasureMappings": {
"TargetMultiMeasureName": "numDataPoints",
"MultiMeasureAttributeMappings": [
{
"SourceColumn": "numDataPoints",
"MeasureValueType": "BIGINT"
}
]
}
}
},
"ErrorReportConfiguration": {
"S3Configuration" : {
"BucketName" : "******",
"ObjectKeyPrefix": "errors",
"EncryptionOption": "SSE_S3"
}
},
"ScheduledQueryExecutionRoleArn": "******"
}
```
Nell'esempio, il ScheduleExpression cron (0/5 \$1 \$1 \$1? \$1) implica che la query venga eseguita una volta ogni 5 minuti al 5, 10, 15... minuti di ogni ora di ogni giorno. Questi timestamp quando viene attivata un'istanza specifica di questa query sono ciò che si traduce nel parametro @scheduled\$1runtime utilizzato nella query. Ad esempio, si consideri l'istanza di questa query pianificata in esecuzione il 01/12/2021 00:00:00. In questo caso, il parametro @scheduled\$1runtime viene inizializzato con il timestamp 2021-12-01 00:00:00 quando si richiama la query. Pertanto, questa istanza specifica verrà eseguita al timestamp 2021-12-01 00:00:00 e calcolerà gli aggregati al minuto dall'intervallo temporale 2021-11-30 23:50:00 al 01/12/2021 00:01:00. Allo stesso modo, l'istanza successiva di questa query viene attivata al timestamp 2021-12-01 00:05:00 e in tal caso, la query calcolerà gli aggregati al minuto dall'intervallo di tempo 2021-11-30 23:55:00 al 2021-12-01 00:06:00. Pertanto, il parametro @scheduled\$1runtime fornisce una query pianificata per precalcolare gli aggregati per gli intervalli di tempo configurati utilizzando il tempo di invocazione per le query.
Nota che due istanze successive della query si sovrappongono nei rispettivi intervalli di tempo. Questo è qualcosa che puoi controllare in base alle tue esigenze. In questo caso, questa sovrapposizione consente a queste query di aggiornare gli aggregati sulla base di tutti i dati il cui arrivo è stato leggermente ritardato, fino a 5 minuti in questo esempio. Per garantire la correttezza delle query materializzate, Timestream for LiveAnalytics assicura che la query al 2021-12-01 00:05:00 venga eseguita solo dopo il completamento della query del 2021-12-01 00:00:00 e che i risultati di queste ultime query possano aggiornare qualsiasi aggregato precedentemente materializzato utilizzando se viene generato un valore più recente. Ad esempio, se alcuni dati al timestamp 2021-11-30 23:59:00 sono arrivati dopo l'esecuzione della query per il 2021-12-01 00:00:00 ma prima della query per il 2021-12-01 00:05:00, l'esecuzione del 2021-12-01 00:05:00 ricalcola gli aggregati per il minuto 2021-11-30 23:59:00 e ciò comporterà l'aggiornamento dell'aggregato precedente con il valore appena calcolato. Puoi fare affidamento su questa semantica delle query pianificate per trovare un compromesso tra la rapidità con cui aggiorni i tuoi precalcoli e la capacità di gestire con garbo alcuni dati con arrivo ritardato. Di seguito vengono illustrate ulteriori considerazioni su come bilanciare questa cadenza di aggiornamento con l'aggiornamento dei dati e su come affrontare l'aggiornamento degli aggregati per i dati che arrivano con un ritardo ancora maggiore o se la fonte del calcolo pianificato ha valori aggiornati che richiederebbero il ricalcolo degli aggregati.
Ogni calcolo pianificato ha una configurazione di notifica in cui Timestream for invia una notifica di ogni esecuzione di una configurazione pianificata. LiveAnalytics È possibile configurare un argomento SNS per ricevere notifiche per ogni chiamata. Oltre allo stato di successo o di fallimento di un'istanza specifica, dispone anche di diverse statistiche come il tempo impiegato per l'esecuzione del calcolo, il numero di byte scansionati dal calcolo e il numero di byte scritti dal calcolo nella tabella di destinazione. È possibile utilizzare queste statistiche per ottimizzare ulteriormente la query, pianificare la configurazione o tenere traccia della spesa per le query pianificate. Un aspetto degno di nota è il tempo di esecuzione di un'istanza. In questo esempio, il calcolo pianificato è configurato per l'esecuzione ogni 5 minuti. Il tempo di esecuzione determinerà il ritardo con cui il precalcolo sarà disponibile, il che definirà anche il ritardo nella dashboard quando si utilizzano i dati precalcolati nelle dashboard. Inoltre, se questo ritardo è costantemente superiore all'intervallo di aggiornamento, ad esempio, se il tempo di esecuzione è superiore a 5 minuti per un calcolo configurato per l'aggiornamento ogni 5 minuti, è importante ottimizzare il calcolo in modo che venga eseguito più velocemente per evitare ulteriori ritardi nelle dashboard.
## Aggregazione da tabella derivata
Ora che hai impostato le query pianificate e che gli aggregati sono stati precalcolati e materializzati in un altro Timestream per la LiveAnalytics tabella specificata nella configurazione di destinazione del calcolo pianificato, puoi utilizzare i dati in quella tabella per scrivere query SQL per potenziare le tue dashboard. Di seguito è riportato un equivalente della query che utilizza i preaggregati materializzati per generare l'aggregato di conteggio dei punti dati al minuto per us-east-1.
```
SELECT bin(time, 1m) as minute, SUM(numDataPoints) as numDatapoints
FROM "derived"."per_minute_aggs_pt5m"
WHERE time BETWEEN from_milliseconds(1636699996445) AND from_milliseconds(1636743196445)
AND region = 'us-east-1'
GROUP BY bin(time, 1m)
ORDER BY 1 desc
```
![\[Graph showing data points fluctuating between 0 and 6 million over time from 23:00 to 10:00.\]](http://docs.aws.amazon.com/it_it/timestream/latest/developerguide/images/schedquery_aggrfromderived.png)
La figura precedente riporta l'aggregato calcolato dalla tabella degli aggregati. Confrontando questo pannello con il pannello calcolato a partire dai dati di origine non elaborati, noterete che corrispondono esattamente, anche se questi aggregati subiscono un ritardo di alcuni minuti, a causa dell'intervallo di aggiornamento configurato per il calcolo programmato più il tempo necessario per eseguirlo.
Questa interrogazione sui dati precalcolati analizza dati di diversi ordini di grandezza inferiori rispetto agli aggregati calcolati sui dati di origine grezza. A seconda della granularità delle aggregazioni, questa riduzione può facilmente ridurre di 100 volte i costi e la latenza delle query. L'esecuzione di questo calcolo pianificato comporta un costo. Tuttavia, a seconda della frequenza con cui questi dashboard vengono aggiornati e del numero di utenti simultanei che li caricano, si finisce per ridurre in modo significativo i costi complessivi utilizzando questi precalcoli. E questo si aggiunge ai tempi di caricamento delle dashboard da 10 a 100 volte più rapidi.
## Aggregazione che combina tabelle di origine e derivate
I dashboard creati utilizzando le tabelle derivate possono presentare un ritardo. Se lo scenario applicativo richiede che i dashboard contengano i dati più recenti, puoi utilizzare la potenza e la flessibilità del supporto SQL di Timestream for per LiveAnalytics combinare i dati più recenti della tabella di origine con gli aggregati storici della tabella derivata per formare una vista unita. Questa vista unita utilizza la semantica di unione di SQL e gli intervalli di tempo non sovrapposti della tabella di origine e della tabella derivata. Nell'esempio seguente, stiamo usando il termine «derivato».» tabella derivata «per\$1minute\$1aggs\$1pt5m». Poiché il calcolo pianificato per quella tabella derivata si aggiorna una volta ogni 5 minuti (in base alla specifica dell'espressione di pianificazione), la seguente query utilizza i 15 minuti di dati più recenti della tabella di origine e tutti i dati più vecchi di 15 minuti dalla tabella derivata, quindi unisce i risultati per creare la vista unita che offre il meglio di entrambi i mondi: l'economia e la bassa latenza leggendo gli aggregati precalcolati più vecchi dalla tabella derivata e la freschezza dell'aggregazione proviene dalla tabella dei sorgenti per potenziare i casi d'uso dell'analisi in tempo reale.
Tieni presente che questo approccio di unione avrà una latenza di query leggermente superiore rispetto alla sola interrogazione della tabella derivata e avrà anche una scansione dei dati leggermente superiore, poiché aggrega i dati grezzi in tempo reale per riempire l'intervallo di tempo più recente. Tuttavia, questa visualizzazione unificata sarà comunque notevolmente più veloce ed economica rispetto all'aggregazione immediata dalla tabella di origine, in particolare per le dashboard che riproducono giorni o settimane di dati. Per questo esempio, puoi ottimizzare gli intervalli di tempo in base alle esigenze di aggiornamento e alla tolleranza al ritardo dell'applicazione.
```
WITH aggregated_source_data AS (
SELECT 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 bin(from_milliseconds(1636743196439), 1m) - 15m AND from_milliseconds(1636743196439)
AND region = 'us-east-1'
GROUP BY bin(time, 1m)
), aggregated_derived_data AS (
SELECT bin(time, 1m) as minute, SUM(numDataPoints) as numDatapoints
FROM "derived"."per_minute_aggs_pt5m"
WHERE time BETWEEN from_milliseconds(1636699996439) AND bin(from_milliseconds(1636743196439), 1m) - 15m
AND region = 'us-east-1'
GROUP BY bin(time, 1m)
)
SELECT minute, numDatapoints
FROM (
(
SELECT *
FROM aggregated_derived_data
)
UNION
(
SELECT *
FROM aggregated_source_data
)
)
ORDER BY 1 desc
```
Di seguito è riportato il pannello della dashboard con questa visualizzazione unificata. Come puoi vedere, la dashboard ha un aspetto quasi identico alla vista calcolata dalla tabella derivata, tranne per il fatto che avrà la parte più up-to-date aggregata nell'estremità più a destra.
![\[Time-series graph showing fluctuating data points over 11 hours, with peaks around 6 million.\]](http://docs.aws.amazon.com/it_it/timestream/latest/developerguide/images/schedquery_aggrcombsourceandderived.png)
## Aggregazione basata su calcoli pianificati aggiornati di frequente
A seconda della frequenza con cui vengono caricate le dashboard e della latenza desiderata per la dashboard, esiste un altro approccio per ottenere risultati più aggiornati nella dashboard: fare in modo che il calcolo pianificato aggiorni gli aggregati più frequentemente. Ad esempio, di seguito è riportata la configurazione dello stesso calcolo pianificato, tranne per il fatto che si aggiorna una volta al minuto (si noti lo schedule express cron (0/1 \$1 \$1 \$1)? \$1)). Con questa configurazione, la tabella derivata per\$1minute\$1aggs\$1pt1m avrà aggregati molto più recenti rispetto allo scenario in cui il calcolo specificava una pianificazione di aggiornamento di una volta ogni 5 minuti.
```
{
"Name": "MultiPT1mPerMinutePerRegionMeasureCount",
"QueryString": "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",
"ScheduleConfiguration": {
"ScheduleExpression": "cron(0/1 * * * ? *)"
},
"NotificationConfiguration": {
"SnsConfiguration": {
"TopicArn": "******"
}
},
"TargetConfiguration": {
"TimestreamConfiguration": {
"DatabaseName": "derived",
"TableName": "per_minute_aggs_pt1m",
"TimeColumn": "minute",
"DimensionMappings": [
{
"Name": "region",
"DimensionValueType": "VARCHAR"
}
],
"MultiMeasureMappings": {
"TargetMultiMeasureName": "numDataPoints",
"MultiMeasureAttributeMappings": [
{
"SourceColumn": "numDataPoints",
"MeasureValueType": "BIGINT"
}
]
}
}
},
"ErrorReportConfiguration": {
"S3Configuration" : {
"BucketName" : "******",
"ObjectKeyPrefix": "errors",
"EncryptionOption": "SSE_S3"
}
},
"ScheduledQueryExecutionRoleArn": "******"
}
```
```
SELECT bin(time, 1m) as minute, SUM(numDataPoints) as numDatapoints
FROM "derived"."per_minute_aggs_pt1m"
WHERE time BETWEEN from_milliseconds(1636699996446) AND from_milliseconds(1636743196446)
AND region = 'us-east-1'
GROUP BY bin(time, 1m), region
ORDER BY 1 desc
```
Poiché la tabella derivata contiene aggregati più recenti, ora puoi interrogare direttamente la tabella derivata per\$1minute\$1aggs\$1pt1m per ottenere aggregati più recenti, come si può vedere dalla query precedente e dallo snapshot della dashboard di seguito.
![\[Graph showing fluctuating data points over time, with peaks reaching 6 million and valleys near 1 million.\]](http://docs.aws.amazon.com/it_it/timestream/latest/developerguide/images/schedquery_aggregatefromrequently.png)
Tieni presente che l'aggiornamento del calcolo pianificato in base a una pianificazione più rapida (ad esempio 1 minuto rispetto a 5 minuti) aumenterà i costi di manutenzione per il calcolo pianificato. Il messaggio di notifica per l'esecuzione di ogni calcolo fornisce statistiche sulla quantità di dati scansionati e sulla quantità di scrittura nella tabella derivata. Allo stesso modo, se si utilizza la vista unita per unire la tabella derivata, si interrogano i costi sulla vista unita e la latenza di caricamento del dashboard sarà maggiore rispetto alla sola interrogazione della tabella derivata. Pertanto, l'approccio scelto dipenderà dalla frequenza di aggiornamento dei dashboard e dai costi di manutenzione delle query pianificate. Se decine di utenti aggiornano le dashboard una volta al minuto circa, un aggiornamento più frequente della tabella derivata comporterà probabilmente una riduzione dei costi complessivi.
# Ultimo punto di ogni dispositivo
L'applicazione potrebbe richiedere la lettura dell'ultima misurazione emessa da un dispositivo. Esistono casi d'uso più generali per ottenere l'ultima misurazione di un dispositivo prima di una determinata date/time o la prima misurazione di un dispositivo dopo una determinata data/ora. Quando si dispone di milioni di dispositivi e anni di dati, questa ricerca potrebbe richiedere la scansione di grandi quantità di dati.
Di seguito è riportato un esempio di come è possibile utilizzare le interrogazioni pianificate per ottimizzare la ricerca dell'ultimo punto emesso da un dispositivo. È possibile utilizzare lo stesso schema per ottimizzare anche la prima query, se l'applicazione ne ha bisogno.
**Topics**
+ [Calcolato dalla tabella di origine](#scheduledqueries-patterns-lastpointfromdevice-computedfromsrctable)
+ [Tabella derivata da precalcolare con granularità giornaliera](#scheduledqueries-patterns-lastpointfromdevice-derivedttabletoprecompute)
+ [Calcolato dalla tabella derivata](#scheduledqueries-patterns-lastpointfromdevice-computedfromderivedtable)
+ [Combinazione da tabella sorgente e derivata](#scheduledqueries-patterns-lastpointfromdevice-combinesourceandderived)
## Calcolato dalla tabella di origine
Di seguito è riportata una query di esempio per trovare l'ultima misurazione emessa dai servizi in una distribuzione specifica (ad esempio, server per un determinato microservizio all'interno di una determinata regione, cella, silo e availability\$1zone). Nell'applicazione di esempio, questa query restituirà l'ultima misurazione per centinaia di server. Si noti inoltre che questa query ha un predicato temporale illimitato e cerca tutti i dati più vecchi di un determinato timestamp.
**Nota**
Per informazioni sulle funzioni and, vedere. `max` `max_by` [Funzioni di aggregazione](aggregate-functions.md)
```
SELECT instance_name, MAX(time) AS time, MAX_BY(gc_pause, time) AS last_measure
FROM "raw_data"."devops"
WHERE time < from_milliseconds(1636685271872)
AND measure_name = 'events'
AND region = 'us-east-1'
AND cell = 'us-east-1-cell-10'
AND silo = 'us-east-1-cell-10-silo-3'
AND availability_zone = 'us-east-1-1'
AND microservice_name = 'hercules'
GROUP BY region, cell, silo, availability_zone, microservice_name,
instance_name, process_name, jdk_version
ORDER BY instance_name, time DESC
```
## Tabella derivata da precalcolare con granularità giornaliera
È possibile convertire il caso d'uso precedente in un calcolo pianificato. Se i requisiti dell'applicazione sono tali da richiedere l'ottenimento di questi valori per l'intero parco macchine in più aree, celle, silos, zone di disponibilità e microservizi, è possibile utilizzare un unico calcolo di pianificazione per precalcolare i valori per l'intero parco macchine. Questa è la potenza delle query pianificate senza server di Timestream for LiveAnalytics, che consente a queste query di adattarsi ai requisiti di scalabilità dell'applicazione.
Di seguito è riportata una query per precalcolare l'ultimo punto su tutti i server per un determinato giorno. Nota che la query ha solo un predicato temporale e non un predicato sulle dimensioni. Il predicato temporale limita la query al giorno trascorso dal momento in cui il calcolo viene attivato in base all'espressione di pianificazione specificata.
```
SELECT region, cell, silo, availability_zone, microservice_name,
instance_name, process_name, jdk_version,
MAX(time) AS time, MAX_BY(gc_pause, time) AS last_measure
FROM raw_data.devops
WHERE time BETWEEN bin(@scheduled_runtime, 1d) - 1d AND bin(@scheduled_runtime, 1d)
AND measure_name = 'events'
GROUP BY region, cell, silo, availability_zone, microservice_name,
instance_name, process_name, jdk_version
```
Di seguito è riportata una configurazione per il calcolo pianificato utilizzando la query precedente, che esegue tale query alle 01:00 UTC ogni giorno per calcolare l'aggregato del giorno precedente. L'espressione di pianificazione cron (0) \$1 \$1? \$1) controlla questo comportamento e viene eseguito un'ora dopo la fine della giornata, tenendo conto dei dati che arrivano fino a un giorno di ritardo.
```
{
"Name": "PT1DPerInstanceLastpoint",
"QueryString": "SELECT region, cell, silo, availability_zone, microservice_name, instance_name, process_name, jdk_version, MAX(time) AS time, MAX_BY(gc_pause, time) AS last_measure FROM raw_data.devops WHERE time BETWEEN bin(@scheduled_runtime, 1d) - 1d AND bin(@scheduled_runtime, 1d) AND measure_name = 'events' GROUP BY region, cell, silo, availability_zone, microservice_name, instance_name, process_name, jdk_version",
"ScheduleConfiguration": {
"ScheduleExpression": "cron(0 1 * * ? *)"
},
"NotificationConfiguration": {
"SnsConfiguration": {
"TopicArn": "******"
}
},
"TargetConfiguration": {
"TimestreamConfiguration": {
"DatabaseName": "derived",
"TableName": "per_timeseries_lastpoint_pt1d",
"TimeColumn": "time",
"DimensionMappings": [
{
"Name": "region",
"DimensionValueType": "VARCHAR"
},
{
"Name": "cell",
"DimensionValueType": "VARCHAR"
},
{
"Name": "silo",
"DimensionValueType": "VARCHAR"
},
{
"Name": "availability_zone",
"DimensionValueType": "VARCHAR"
},
{
"Name": "microservice_name",
"DimensionValueType": "VARCHAR"
},
{
"Name": "instance_name",
"DimensionValueType": "VARCHAR"
},
{
"Name": "process_name",
"DimensionValueType": "VARCHAR"
},
{
"Name": "jdk_version",
"DimensionValueType": "VARCHAR"
}
],
"MultiMeasureMappings": {
"TargetMultiMeasureName": "last_measure",
"MultiMeasureAttributeMappings": [
{
"SourceColumn": "last_measure",
"MeasureValueType": "DOUBLE"
}
]
}
}
},
"ErrorReportConfiguration": {
"S3Configuration" : {
"BucketName" : "******",
"ObjectKeyPrefix": "errors",
"EncryptionOption": "SSE_S3"
}
},
"ScheduledQueryExecutionRoleArn": "******"
}
```
## Calcolato dalla tabella derivata
Una volta definita la tabella derivata utilizzando la configurazione precedente e dopo che almeno un'istanza della query pianificata ha materializzato i dati nella tabella derivata, è ora possibile interrogare la tabella derivata per ottenere la misurazione più recente. Di seguito è riportato un esempio di query sulla tabella derivata.
```
SELECT instance_name, MAX(time) AS time, MAX_BY(last_measure, time) AS last_measure
FROM "derived"."per_timeseries_lastpoint_pt1d"
WHERE time < from_milliseconds(1636746715649)
AND measure_name = 'last_measure'
AND region = 'us-east-1'
AND cell = 'us-east-1-cell-10'
AND silo = 'us-east-1-cell-10-silo-3'
AND availability_zone = 'us-east-1-1'
AND microservice_name = 'hercules'
GROUP BY region, cell, silo, availability_zone, microservice_name,
instance_name, process_name, jdk_version
ORDER BY instance_name, time DESC
```
## Combinazione da tabella sorgente e derivata
Analogamente all'esempio precedente, tutti i dati della tabella derivata non avranno le scritture più recenti. Pertanto, è possibile utilizzare nuovamente uno schema simile a quello precedente per unire i dati della tabella derivata con i dati precedenti e utilizzare i dati di origine per il suggerimento rimanente. Di seguito è riportato un esempio di tale interrogazione che utilizza l'approccio UNION simile. Poiché il requisito dell'applicazione è quello di trovare la misurazione più recente prima di un periodo di tempo e l'ora di inizio può essere passata, il modo in cui si scrive questa query consiste nell'utilizzare l'ora fornita, utilizzare i dati di origine per un massimo di un giorno a partire dall'ora specificata e quindi utilizzare la tabella derivata sui dati più vecchi. Come si può vedere dall'esempio di query riportato di seguito, il predicato temporale sui dati di origine è limitato. Ciò garantisce un'elaborazione efficiente sulla tabella di origine, che contiene un volume di dati significativamente maggiore, e quindi il predicato temporale illimitato si trova sulla tabella derivata.
```
WITH last_point_derived AS (
SELECT instance_name, MAX(time) AS time, MAX_BY(last_measure, time) AS last_measure
FROM "derived"."per_timeseries_lastpoint_pt1d"
WHERE time < from_milliseconds(1636746715649)
AND measure_name = 'last_measure'
AND region = 'us-east-1'
AND cell = 'us-east-1-cell-10'
AND silo = 'us-east-1-cell-10-silo-3'
AND availability_zone = 'us-east-1-1'
AND microservice_name = 'hercules'
GROUP BY region, cell, silo, availability_zone, microservice_name,
instance_name, process_name, jdk_version
), last_point_source AS (
SELECT instance_name, MAX(time) AS time, MAX_BY(gc_pause, time) AS last_measure
FROM "raw_data"."devops"
WHERE time < from_milliseconds(1636746715649) AND time > from_milliseconds(1636746715649) - 26h
AND measure_name = 'events'
AND region = 'us-east-1'
AND cell = 'us-east-1-cell-10'
AND silo = 'us-east-1-cell-10-silo-3'
AND availability_zone = 'us-east-1-1'
AND microservice_name = 'hercules'
GROUP BY region, cell, silo, availability_zone, microservice_name,
instance_name, process_name, jdk_version
)
SELECT instance_name, MAX(time) AS time, MAX_BY(last_measure, time) AS last_measure
FROM (
SELECT * FROM last_point_derived
UNION
SELECT * FROM last_point_source
)
GROUP BY instance_name
ORDER BY instance_name, time DESC
```
La precedente è solo un'illustrazione di come è possibile strutturare le tabelle derivate. Se disponi di anni di dati, puoi utilizzare più livelli di aggregazioni. Ad esempio, puoi aggiungere aggregati mensili a quelli giornalieri e aggiungere aggregati orari prima di quelli giornalieri. In questo modo puoi unire i dati più recenti per inserire l'ultima ora, quelli con frequenza oraria per inserire l'ultimo giorno, quelli giornalieri per compilare l'ultimo mese e quelli mensili per inserire i dati più vecchi. Il numero di livelli impostati rispetto alla pianificazione degli aggiornamenti dipenderà dalle vostre esigenze relative alla frequenza con cui queste query vengono emesse e al numero di utenti che le emettono contemporaneamente.
# Valori di dimensione univoci
Potresti avere un caso d'uso in cui disponi di dashboard in cui desideri utilizzare i valori univoci delle dimensioni come variabili per approfondire le metriche corrispondenti a una specifica porzione di dati. L'istantanea seguente è un esempio in cui la dashboard precompila i valori univoci di diverse dimensioni come region, cell, silo, microservice e availability\$1zone. Qui mostriamo un esempio di come è possibile utilizzare le query pianificate per velocizzare in modo significativo il calcolo di questi valori distinti di queste variabili in base alle metriche che stai monitorando.
**Topics**
+ [Sui dati grezzi](#scheduledqueries-patterns-uniquedimvalues-onraw)
+ [Precalcola valori di dimensione univoci](#scheduledqueries-patterns-uniquedimvalues-precompute)
+ [Calcolo delle variabili dalla tabella derivata](#scheduledqueries-patterns-uniquedimvalues-fromderived)
## Sui dati grezzi
Puoi usare SELECT DISTINCT per calcolare i valori distinti visti dai tuoi dati. Ad esempio, se desideri ottenere i valori distinti della regione, puoi utilizzare la query di questo modulo.
```
SELECT DISTINCT region
FROM "raw_data"."devops"
WHERE time > ago(1h)
ORDER BY 1
```
Potresti tracciare milioni di dispositivi e miliardi di serie temporali. Tuttavia, nella maggior parte dei casi, queste variabili interessanti riguardano dimensioni di cardinalità inferiori, in cui sono presenti da poche a decine di valori. Il calcolo di DISTINCT dai dati grezzi può richiedere la scansione di grandi volumi di dati.
## Precalcola valori di dimensione univoci
Desideri che queste variabili si carichino rapidamente in modo che i dashboard siano interattivi. Inoltre, queste variabili vengono spesso calcolate su ogni caricamento del dashboard, quindi è necessario che siano anche convenienti. È possibile ottimizzare la ricerca di queste variabili utilizzando query pianificate e materializzandole in una tabella derivata.
Innanzitutto, è necessario identificare le dimensioni per le quali è necessario calcolare i valori o le colonne DISTINCT che verranno utilizzati nei predicati durante il calcolo del valore DISTINCT.
In questo esempio, puoi vedere che la dashboard sta inserendo valori distinti per le dimensioni region, cell, silo, availability\$1zone e microservice. Quindi puoi usare la query seguente per precalcolare questi valori unici.
```
SELECT region, cell, silo, availability_zone, microservice_name,
min(@scheduled_runtime) AS time, COUNT(*) as numDataPoints
FROM raw_data.devops
WHERE time BETWEEN @scheduled_runtime - 15m AND @scheduled_runtime
GROUP BY region, cell, silo, availability_zone, microservice_name
```
Ci sono alcune cose importanti da notare qui.
+ È possibile utilizzare un calcolo pianificato per precalcolare i valori per molte query diverse. Ad esempio, si utilizza la query precedente per precalcolare i valori per cinque diverse variabili. Quindi non è necessario uno per ogni variabile. È possibile utilizzare lo stesso schema per identificare calcoli condivisi su più pannelli per ottimizzare il numero di query pianificate da gestire.
+ I valori univoci delle dimensioni non sono intrinsecamente dati di serie temporali. Quindi li converti in serie temporali usando @scheduled\$1runtime. Associando questi dati al parametro @scheduled\$1runtime, puoi anche tenere traccia di quali valori univoci sono comparsi in un determinato momento, creando così dati di serie temporali a partire da essi.
+ Nell'esempio precedente, vedrete il tracciamento di un valore metrico. Questo esempio utilizza COUNT (\$1). Puoi calcolare altri aggregati significativi se desideri monitorarli per le tue dashboard.
Di seguito è riportata una configurazione per un calcolo pianificato utilizzando la query precedente. In questo esempio, è configurato per l'aggiornamento una volta ogni 15 minuti utilizzando l'espressione di pianificazione cron (0/15 \$1 \$1 \$1? \$1).
```
{
"Name": "PT15mHighCardPerUniqueDimensions",
"QueryString": "SELECT region, cell, silo, availability_zone, microservice_name, min(@scheduled_runtime) AS time, COUNT(*) as numDataPoints FROM raw_data.devops WHERE time BETWEEN @scheduled_runtime - 15m AND @scheduled_runtime GROUP BY region, cell, silo, availability_zone, microservice_name",
"ScheduleConfiguration": {
"ScheduleExpression": "cron(0/15 * * * ? *)"
},
"NotificationConfiguration": {
"SnsConfiguration": {
"TopicArn": "******"
}
},
"TargetConfiguration": {
"TimestreamConfiguration": {
"DatabaseName": "derived",
"TableName": "hc_unique_dimensions_pt15m",
"TimeColumn": "time",
"DimensionMappings": [
{
"Name": "region",
"DimensionValueType": "VARCHAR"
},
{
"Name": "cell",
"DimensionValueType": "VARCHAR"
},
{
"Name": "silo",
"DimensionValueType": "VARCHAR"
},
{
"Name": "availability_zone",
"DimensionValueType": "VARCHAR"
},
{
"Name": "microservice_name",
"DimensionValueType": "VARCHAR"
}
],
"MultiMeasureMappings": {
"TargetMultiMeasureName": "count_multi",
"MultiMeasureAttributeMappings": [
{
"SourceColumn": "numDataPoints",
"MeasureValueType": "BIGINT"
}
]
}
}
},
"ErrorReportConfiguration": {
"S3Configuration" : {
"BucketName" : "******",
"ObjectKeyPrefix": "errors",
"EncryptionOption": "SSE_S3"
}
},
"ScheduledQueryExecutionRoleArn": "******"
}
```
## Calcolo delle variabili dalla tabella derivata
Una volta che il calcolo pianificato ha prematerializzato i valori univoci nella tabella derivata hc\$1unique\$1dimensions\$1pt15m, è possibile utilizzare la tabella derivata per calcolare in modo efficiente i valori univoci delle dimensioni. Di seguito sono riportati alcuni esempi di query su come calcolare i valori univoci e su come utilizzare altre variabili come predicati in queste query con valori unici.
**Region**
```
SELECT DISTINCT region
FROM "derived"."hc_unique_dimensions_pt15m"
WHERE time > ago(1h)
ORDER BY 1
```
**Cella**
```
SELECT DISTINCT cell
FROM "derived"."hc_unique_dimensions_pt15m"
WHERE time > ago(1h)
AND region = '${region}'
ORDER BY 1
```
**Silo**
```
SELECT DISTINCT silo
FROM "derived"."hc_unique_dimensions_pt15m"
WHERE time > ago(1h)
AND region = '${region}' AND cell = '${cell}'
ORDER BY 1
```
**Microservizio**
```
SELECT DISTINCT microservice_name
FROM "derived"."hc_unique_dimensions_pt15m"
WHERE time > ago(1h)
AND region = '${region}' AND cell = '${cell}'
ORDER BY 1
```
**Zona di disponibilità**
```
SELECT DISTINCT availability_zone
FROM "derived"."hc_unique_dimensions_pt15m"
WHERE time > ago(1h)
AND region = '${region}' AND cell = '${cell}' AND silo = '${silo}'
ORDER BY 1
```
# Gestione dei dati in arrivo tardivo
Potrebbero verificarsi scenari in cui è possibile che i dati arrivino con notevole ritardo, ad esempio, il momento in cui i dati sono stati importati in Timestream for LiveAnalytics è notevolmente ritardato rispetto al timestamp associato alle righe che vengono importate. Negli esempi precedenti, avete visto come utilizzare gli intervalli di tempo definiti dal parametro @scheduled\$1runtime per tenere conto di alcuni dati che arrivano in ritardo. Tuttavia, se avete casi d'uso in cui i dati possono essere ritardati di ore o giorni, potrebbe essere necessario un modello diverso per assicurarvi che i calcoli preliminari nella tabella derivata siano aggiornati in modo appropriato per riflettere tali dati in arrivo in ritardo. Per informazioni generali sui dati in arrivo in ritardo, consulta. [Scrittura di dati (inserti e sconvolgimenti)](writes.md#writes.writing-data-inserts-upserts)
Di seguito verranno illustrati due modi diversi per gestire questi dati in arrivo in ritardo.
+ Se hai ritardi prevedibili nell'arrivo dei dati, puoi utilizzare un altro calcolo pianificato «recuperato» per aggiornare gli aggregati per i dati in arrivo in ritardo.
+ Se hai ritardi imprevedibili o dati occasionali relativi agli arrivi tardivi, puoi utilizzare le esecuzioni manuali per aggiornare le tabelle derivate.
Questa discussione tratta gli scenari di arrivo tardivo dei dati. Tuttavia, gli stessi principi si applicano alle correzioni dei dati, quando hai modificato i dati nella tabella di origine e desideri aggiornare gli aggregati nelle tabelle derivate.
**Topics**
+ [Interrogazioni di recupero pianificate](#scheduledqueries-patterns-latearrive-schedcatchup)
+ [Esecuzioni manuali per dati imprevedibili in arrivo in ritardo](#scheduledqueries-patterns-latearrive-manual)
## Interrogazioni di recupero pianificate
### Interroga i dati aggregati che sono arrivati in tempo
Di seguito è riportato uno schema che illustra come è possibile utilizzare un metodo automatizzato per aggiornare gli aggregati in caso di ritardi prevedibili nell'arrivo dei dati. Considera uno degli esempi precedenti di calcolo pianificato su dati in tempo reale riportati di seguito. Questo calcolo pianificato aggiorna la tabella derivata una volta ogni 30 minuti e tiene già conto dei dati con un ritardo fino a un'ora.
```
{
"Name": "MultiPT30mPerHrPerTimeseriesDPCount",
"QueryString": "SELECT region, cell, silo, availability_zone, microservice_name, instance_type, os_version, instance_name, process_name, jdk_version, bin(time, 1h) as hour, SUM(CASE WHEN measure_name = 'metrics' THEN 20 ELSE 5 END) as numDataPoints FROM raw_data.devops WHERE time BETWEEN bin(@scheduled_runtime, 1h) - 1h AND @scheduled_runtime + 1h GROUP BY region, cell, silo, availability_zone, microservice_name, instance_type, os_version, instance_name, process_name, jdk_version, bin(time, 1h)",
"ScheduleConfiguration": {
"ScheduleExpression": "cron(0/30 * * * ? *)"
},
"NotificationConfiguration": {
"SnsConfiguration": {
"TopicArn": "******"
}
},
"TargetConfiguration": {
"TimestreamConfiguration": {
"DatabaseName": "derived",
"TableName": "dp_per_timeseries_per_hr",
"TimeColumn": "hour",
"DimensionMappings": [
{
"Name": "region",
"DimensionValueType": "VARCHAR"
},
{
"Name": "cell",
"DimensionValueType": "VARCHAR"
},
{
"Name": "silo",
"DimensionValueType": "VARCHAR"
},
{
"Name": "availability_zone",
"DimensionValueType": "VARCHAR"
},
{
"Name": "microservice_name",
"DimensionValueType": "VARCHAR"
},
{
"Name": "instance_type",
"DimensionValueType": "VARCHAR"
},
{
"Name": "os_version",
"DimensionValueType": "VARCHAR"
},
{
"Name": "instance_name",
"DimensionValueType": "VARCHAR"
},
{
"Name": "process_name",
"DimensionValueType": "VARCHAR"
},
{
"Name": "jdk_version",
"DimensionValueType": "VARCHAR"
}
],
"MultiMeasureMappings": {
"TargetMultiMeasureName": "numDataPoints",
"MultiMeasureAttributeMappings": [
{
"SourceColumn": "numDataPoints",
"MeasureValueType": "BIGINT"
}
]
}
}
},
"ErrorReportConfiguration": {
"S3Configuration" : {
"BucketName" : "******",
"ObjectKeyPrefix": "errors",
"EncryptionOption": "SSE_S3"
}
},
"ScheduledQueryExecutionRoleArn": "******"
}
```
### Interrogazione di recupero che aggiorna gli aggregati per i dati in arrivo in ritardo
Ora, se consideri il caso, i tuoi dati possono subire un ritardo di circa 12 ore. Di seguito è riportata una variante della stessa query. Tuttavia, la differenza è che calcola gli aggregati sui dati che subiscono un ritardo fino a 12 ore rispetto a quando viene attivato il calcolo pianificato. Ad esempio, come vedi la query nell'esempio seguente, l'intervallo di tempo a cui si rivolge questa query è compreso tra 2 e 14 ore prima dell'attivazione della query. Inoltre, se notate l'espressione di pianificazione cron (0) 0,12 \$1 \$1? \$1), attiverà il calcolo ogni giorno alle 00:00 UTC e alle 12:00 UTC. Pertanto, quando la query viene attivata il 01/12/2021 00:00:00, aggiorna gli aggregati nell'intervallo di tempo 2021-11-30 10:00:00 e 2021-11-30 22:00:00. Le query pianificate utilizzano una semantica upsert simile alle scritture di Timestream for, in cui questa query LiveAnalytics di recupero aggiornerà i valori aggregati con valori più recenti se nella finestra sono presenti dati in arrivo in ritardo o se vengono trovati aggregati più recenti (ad esempio, in questo aggregato viene visualizzato un nuovo raggruppamento che non era presente quando è stato attivato il calcolo pianificato originale), quindi il nuovo aggregato verrà inserito nella tabella derivata. Allo stesso modo, quando l'istanza successiva viene attivata il 2021-12-01 12:00:00, quell'istanza aggiornerà gli aggregati nell'intervallo 2021-11-30 22:00:00 e 2021-12-01 10:00:00.
```
{
"Name": "MultiPT12HPerHrPerTimeseriesDPCountCatchUp",
"QueryString": "SELECT region, cell, silo, availability_zone, microservice_name, instance_type, os_version, instance_name, process_name, jdk_version, bin(time, 1h) as hour, SUM(CASE WHEN measure_name = 'metrics' THEN 20 ELSE 5 END) as numDataPoints FROM raw_data.devops WHERE time BETWEEN bin(@scheduled_runtime, 1h) - 14h AND bin(@scheduled_runtime, 1h) - 2h GROUP BY region, cell, silo, availability_zone, microservice_name, instance_type, os_version, instance_name, process_name, jdk_version, bin(time, 1h)",
"ScheduleConfiguration": {
"ScheduleExpression": "cron(0 0,12 * * ? *)"
},
"NotificationConfiguration": {
"SnsConfiguration": {
"TopicArn": "******"
}
},
"TargetConfiguration": {
"TimestreamConfiguration": {
"DatabaseName": "derived",
"TableName": "dp_per_timeseries_per_hr",
"TimeColumn": "hour",
"DimensionMappings": [
{
"Name": "region",
"DimensionValueType": "VARCHAR"
},
{
"Name": "cell",
"DimensionValueType": "VARCHAR"
},
{
"Name": "silo",
"DimensionValueType": "VARCHAR"
},
{
"Name": "availability_zone",
"DimensionValueType": "VARCHAR"
},
{
"Name": "microservice_name",
"DimensionValueType": "VARCHAR"
},
{
"Name": "instance_type",
"DimensionValueType": "VARCHAR"
},
{
"Name": "os_version",
"DimensionValueType": "VARCHAR"
},
{
"Name": "instance_name",
"DimensionValueType": "VARCHAR"
},
{
"Name": "process_name",
"DimensionValueType": "VARCHAR"
},
{
"Name": "jdk_version",
"DimensionValueType": "VARCHAR"
}
],
"MultiMeasureMappings": {
"TargetMultiMeasureName": "numDataPoints",
"MultiMeasureAttributeMappings": [
{
"SourceColumn": "numDataPoints",
"MeasureValueType": "BIGINT"
}
]
}
}
},
"ErrorReportConfiguration": {
"S3Configuration" : {
"BucketName" : "******",
"ObjectKeyPrefix": "errors",
"EncryptionOption": "SSE_S3"
}
},
"ScheduledQueryExecutionRoleArn": "******"
}
```
L'esempio precedente è un'illustrazione che presuppone che l'arrivo in ritardo sia limitato a 12 ore e che sia possibile aggiornare la tabella derivata una volta ogni 12 ore per i dati che arrivano dopo la finestra in tempo reale. È possibile adattare questo modello per aggiornare la tabella derivata una volta ogni ora in modo che rifletta prima i dati che arrivano in ritardo. Allo stesso modo, puoi adattare l'intervallo di tempo in modo che sia più vecchio di 12 ore, ad esempio un giorno o anche una settimana o più, per gestire dati prevedibili in arrivo tardivo.
## Esecuzioni manuali per dati imprevedibili in arrivo in ritardo
In alcuni casi possono esserci dati imprevedibili con arrivo tardivo o in cui si sono apportate modifiche ai dati di origine e si sono aggiornati alcuni valori a posteriori. In tutti questi casi, è possibile attivare manualmente le interrogazioni pianificate per aggiornare la tabella derivata. Di seguito è riportato un esempio di come è possibile raggiungere questo obiettivo.
Supponiamo di avere il caso d'uso in cui il calcolo è scritto nella tabella derivata dp\$1per\$1timeseries\$1per\$1hr. I tuoi dati di base nella tabella devops sono stati aggiornati nell'intervallo di tempo 2021-11-30 23:00:00 - 2021-12-01 00:00:00. Esistono due diverse query pianificate che possono essere utilizzate per aggiornare questa tabella derivata: Multi e Multi. PT30m PerHrPerTimeseries DPCount PT12 HPer HrPerTimeseries DPCount CatchUp Ogni calcolo pianificato per cui crei in Timestream LiveAnalytics ha un ARN univoco che ottieni quando crei il calcolo o quando esegui un'operazione sull'elenco. È possibile utilizzare l'ARN per il calcolo e un valore per il parametro @scheduled\$1runtime utilizzato dalla query per eseguire questa operazione.
Supponiamo che il calcolo per Multi PT30m PerHrPerTimeseries DPCount abbia un ARN arn\$11 e desideri utilizzare questo calcolo per aggiornare la tabella derivata. Poiché il calcolo pianificato precedente aggiorna gli aggregati 1 ora prima e 1 ora dopo il valore @scheduled\$1runtime, puoi coprire l'intervallo di tempo per l'aggiornamento (2021-11-30 23:00:00 - 2021-12-01 00:00:00) utilizzando un valore di 2021-12-01 00:00:00 per il parametro @scheduled\$1runtime. A tal fine, puoi utilizzare l' ExecuteScheduledQuery API per passare l'ARN di questo calcolo e il valore del parametro temporale in secondi epoch (in UTC). Di seguito è riportato un esempio che utilizza la AWS CLI e puoi seguire lo stesso schema utilizzando uno qualsiasi dei SDKs supportati da Timestream for. LiveAnalytics
```
aws timestream-query execute-scheduled-query --scheduled-query-arn arn_1 --invocation-time 1638316800 --profile profile --region us-east-1
```
Nell'esempio precedente, profile è il AWS profilo che dispone dei privilegi appropriati per effettuare questa chiamata API e 1638316800 corrisponde al secondo periodo del 2021-12-01 00:00:00. Questo trigger manuale si comporta quasi come il trigger automatico, presupponendo che il sistema abbia attivato questa chiamata nel periodo di tempo desiderato.
Se hai ricevuto un aggiornamento in un periodo di tempo più lungo, ad esempio i dati di base sono stati aggiornati per il 2021-11-30 23:00:00 - 01/12/2021 11:00:00, puoi attivare le query precedenti più volte per coprire l'intero intervallo di tempo. Ad esempio, potresti eseguire sei diverse esecuzioni come segue.
```
aws timestream-query execute-scheduled-query --scheduled-query-arn arn_1 --invocation-time 1638316800 --profile profile --region us-east-1
aws timestream-query execute-scheduled-query --scheduled-query-arn arn_1 --invocation-time 1638324000 --profile profile --region us-east-1
aws timestream-query execute-scheduled-query --scheduled-query-arn arn_1 --invocation-time 1638331200 --profile profile --region us-east-1
aws timestream-query execute-scheduled-query --scheduled-query-arn arn_1 --invocation-time 1638338400 --profile profile --region us-east-1
aws timestream-query execute-scheduled-query --scheduled-query-arn arn_1 --invocation-time 1638345600 --profile profile --region us-east-1
aws timestream-query execute-scheduled-query --scheduled-query-arn arn_1 --invocation-time 1638352800 --profile profile --region us-east-1
```
I sei comandi precedenti corrispondono al calcolo pianificato richiamato al 2021-12-01 00:00:00, 2021-12-01 02:00:00, 2021-12-01 04:0:00, 2021-12-01 06:00:00, 2021-12-01 08:00:00e 2021-12-01 10:00:
In alternativa, puoi utilizzare il calcolo Multi PT12 HPer HrPerTimeseries DPCount CatchUp attivato alle 13:00:00 del 01/12/2021 per un'esecuzione per aggiornare gli aggregati per l'intero intervallo di tempo di 12 ore. Ad esempio, se arn\$12 è l'ARN per quel calcolo, puoi eseguire il seguente comando dalla CLI.
```
aws timestream-query execute-scheduled-query --scheduled-query-arn arn_2 --invocation-time 1638363600 --profile profile --region us-east-1
```
Vale la pena notare che per un trigger manuale, è possibile utilizzare un timestamp per il parametro invocationtime che non deve essere allineato con i timestamp di quel trigger automatico. Ad esempio, nell'esempio precedente, hai attivato il calcolo all'ora 2021-12-01 13:00:00 anche se la pianificazione automatica si attiva solo nei timestamp 2021-12-01 10:00:00, 2021-12-01 12:00:00e 2021-12-02 00:00:00. Timestream for offre la flessibilità necessaria per attivarlo con i valori appropriati necessari per le operazioni manuali. LiveAnalytics
Di seguito sono riportate alcune considerazioni importanti sull'utilizzo dell'API. ExecuteScheduledQuery
+ Se state attivando più di queste chiamate, dovete assicurarvi che queste chiamate non generino risultati in intervalli di tempo sovrapposti. Ad esempio, negli esempi precedenti, c'erano sei invocazioni. Ogni chiamata copre un intervallo di tempo di 2 ore, quindi i timestamp di invocazione sono stati distribuiti di due ore ciascuno per evitare sovrapposizioni negli aggiornamenti. Ciò garantisce che i dati nella tabella derivata finiscano in uno stato in cui le corrispondenze siano aggregate dalla tabella di origine. Se non riesci a garantire intervalli di tempo non sovrapposti, assicurati che queste esecuzioni vengano attivate in sequenza una dopo l'altra. Se si attivano più esecuzioni contemporaneamente che si sovrappongono nei rispettivi intervalli di tempo, nei report sugli errori relativi a queste esecuzioni è possibile che si verifichino conflitti di versione. Ai risultati generati da una chiamata di interrogazione pianificata viene assegnata una versione in base a quando è stata attivata la chiamata. Pertanto, le righe generate da chiamate più recenti hanno versioni successive. Un record di versione superiore può sovrascrivere un record di versione inferiore. Per le query pianificate attivate automaticamente, Timestream for gestisce LiveAnalytics automaticamente le pianificazioni in modo da non visualizzare questi problemi anche se le chiamate successive hanno intervalli di tempo sovrapposti.
+ notato in precedenza, è possibile attivare le invocazioni con qualsiasi valore di timestamp per @scheduled\$1runtime. Quindi è tua responsabilità impostare i valori in modo appropriato in modo che gli intervalli di tempo appropriati vengano aggiornati nella tabella derivata corrispondente agli intervalli in cui i dati sono stati aggiornati nella tabella di origine.
+ È inoltre possibile utilizzare questi trigger manuali per le query pianificate che si trovano nello stato DISABILITATO. Ciò consente di definire interrogazioni speciali che non vengono eseguite in una pianificazione automatica, poiché si trovano nello stato DISABILITATO. Piuttosto, puoi utilizzare i trigger manuali su di essi per gestire le correzioni dei dati o i casi di utilizzo in ritardo.
# Riempimento dei precalcoli storici
Quando crei un calcolo pianificato, Timestream for LiveAnalytics gestisce le esecuzioni delle query in futuro, laddove l'aggiornamento è regolato dall'espressione di pianificazione fornita. A seconda della quantità di dati storici contenuta nella tabella di origine, potresti voler aggiornare la tabella derivata con aggregati corrispondenti ai dati storici. Puoi utilizzare la logica precedente per i trigger manuali per riempire nuovamente gli aggregati storici.
Ad esempio, se consideriamo la tabella derivata per\$1timeseries\$1lastpoint\$1pt1d, il calcolo pianificato viene aggiornato una volta al giorno per il giorno passato. Se la tabella di origine contiene un anno di dati, puoi utilizzare l'ARN per questo calcolo pianificato e attivarlo manualmente per ogni giorno fino a un anno in modo che la tabella derivata contenga tutte le query storiche popolate. Nota che qui si applicano tutte le avvertenze relative ai trigger manuali. Inoltre, se la tabella derivata è configurata in modo tale che l'acquisizione storica venga scritta nell'archivio magnetico della tabella derivata, tenete presente le [migliori pratiche](https://docs.aws.amazon.com/timestream/latest/developerguide/best-practices.html) e [i limiti per le scritture](https://docs.aws.amazon.com/timestream/latest/developerguide/ts-limits.html) sull'archivio magnetico.
# Esempi di interrogazioni pianificate
Questa sezione contiene esempi di come utilizzare Timestream for Scheduled Queries per LiveAnalytics ottimizzare i costi e i tempi di caricamento della dashboard durante la visualizzazione delle statistiche relative all'intera flotta e monitorare efficacemente la flotta di dispositivi. Le query pianificate in Timestream for ti LiveAnalytics consentono di esprimere le tue query utilizzando l'intera area di superficie SQL di Timestream for. LiveAnalytics La tua query può includere una o più tabelle di origine, eseguire aggregazioni o qualsiasi altra query consentita dal linguaggio SQL di Timestream for e quindi archiviare i risultati LiveAnalytics della query in un'altra tabella di destinazione in Timestream for. LiveAnalytics
*Questa sezione fa riferimento alla tabella di destinazione di una query pianificata come tabella derivata.*
Ad esempio, utilizzeremo un' DevOps applicazione in cui si monitora un'ampia flotta di server distribuiti in più distribuzioni (ad esempio regioni, celle e silos), più microservizi e si monitorano le statistiche a livello di flotta utilizzando Timestream for. LiveAnalytics [Lo schema di esempio che utilizzeremo è descritto in Schema di esempio per le query pianificate.](https://docs.aws.amazon.com/timestream/latest/developerguide/scheduledqueries-common-schema-example.html)
Verranno descritti i seguenti scenari.
+ Come convertire una dashboard, tracciare statistiche aggregate dai dati grezzi che inserite in Timestream per LiveAnalytics trasformarle in una query pianificata e quindi come utilizzare gli aggregati precalcolati per creare una nuova dashboard che mostri statistiche aggregate.
+ Come combinare le interrogazioni pianificate per ottenere una visualizzazione aggregata e i dati granulari non elaborati per approfondire i dettagli. Ciò consente di archiviare e analizzare i dati grezzi ottimizzando al contempo le operazioni comuni a livello di flotta utilizzando query pianificate.
+ Come ottimizzare i costi utilizzando le query pianificate individuando quali aggregati vengono utilizzati in più dashboard e hanno la stessa query pianificata per popolare più pannelli nello stesso o in più dashboard.
**Topics**
+ [Conversione di un pannello di controllo aggregato in una query pianificata](scheduledqueries-example1.md)
+ [Utilizzo di query pianificate e dati non elaborati per i drill down](scheduledqueries-example2.md)
+ [Ottimizzazione dei costi condividendo le query pianificate tra i dashboard](scheduledqueries-example3.md)
+ [Confronto di un'interrogazione su una tabella di base con un'interrogazione dei risultati di una query pianificata](scheduledqueries-example4-clickstream.md)
# Conversione di un pannello di controllo aggregato in una query pianificata
Supponiamo che stiate calcolando le statistiche relative all'intero parco macchine, ad esempio il numero di host presenti nel parco macchine in base ai cinque microservizi e alle sei regioni in cui viene distribuito il servizio. Dall'istantanea qui sotto, puoi vedere che ci sono 500.000 server che emettono metriche e alcune delle regioni più grandi (ad esempio, us-east-1) hanno più di 200.000 server.
Il calcolo di questi aggregati, in cui si calcolano nomi di istanze distinti su centinaia di gigabyte di dati, può comportare una latenza delle query di decine di secondi, oltre al costo della scansione dei dati.
![\[Instance counts for microservices: apollo and zeus 150k, hercules 100k, athena and demeter 50k each.\]](http://docs.aws.amazon.com/it_it/timestream/latest/developerguide/images/sched_query_ex1_img1.png)
**Interrogazione originale sulla dashboard**
L'aggregato mostrato nel pannello della dashboard viene calcolato, a partire da dati grezzi, utilizzando la query seguente. La query utilizza più costrutti SQL, come conteggi distinti e più funzioni di aggregazione.
```
SELECT CASE WHEN microservice_name = 'apollo' THEN num_instances ELSE NULL END AS apollo,
CASE WHEN microservice_name = 'athena' THEN num_instances ELSE NULL END AS athena,
CASE WHEN microservice_name = 'demeter' THEN num_instances ELSE NULL END AS demeter,
CASE WHEN microservice_name = 'hercules' THEN num_instances ELSE NULL END AS hercules,
CASE WHEN microservice_name = 'zeus' THEN num_instances ELSE NULL END AS zeus
FROM (
SELECT microservice_name, SUM(num_instances) AS num_instances
FROM (
SELECT microservice_name, COUNT(DISTINCT instance_name) as num_instances
FROM "raw_data"."devops"
WHERE time BETWEEN from_milliseconds(1636526171043) AND from_milliseconds(1636612571043)
AND measure_name = 'metrics'
GROUP BY region, cell, silo, availability_zone, microservice_name
)
GROUP BY microservice_name
)
```
**Conversione in una query pianificata**
L'interrogazione precedente può essere convertita in un'interrogazione pianificata come segue. Innanzitutto si calcolano i nomi host distinti all'interno di una determinata distribuzione in una regione, cella, silo, zona di disponibilità e microservizio. Quindi si sommano gli host per calcolare un numero di host all'ora per microservizio. Utilizzando il `@scheduled_runtime` parametro supportato dalle query pianificate, è possibile ricalcolarlo per l'ultima ora in cui viene richiamata la query. La `WHERE` clausola `bin(@scheduled_runtime, 1h)` in della query interna assicura che, anche se l'interrogazione è pianificata a metà ora, si ottengono comunque i dati per l'intera ora.
Anche se la query calcola aggregati orari, come illustrato nella configurazione di calcolo pianificata, è impostata per l'aggiornamento ogni mezz'ora, in modo da ottenere più rapidamente gli aggiornamenti nella tabella derivata. È possibile regolarlo in base ai requisiti di freschezza, ad esempio ricalcolando gli aggregati ogni 15 minuti o ricalcolandoli in base ai limiti delle ore.
```
SELECT microservice_name, hour, SUM(num_instances) AS num_instances
FROM (
SELECT microservice_name, bin(time, 1h) AS hour,
COUNT(DISTINCT instance_name) as num_instances
FROM raw_data.devops
WHERE time BETWEEN bin(@scheduled_runtime, 1h) - 1h AND @scheduled_runtime
AND measure_name = 'metrics'
GROUP BY region, cell, silo, availability_zone, microservice_name, bin(time, 1h)
)
GROUP BY microservice_name, hour
```
```
{
"Name": "MultiPT30mHostCountMicroservicePerHr",
"QueryString": "SELECT microservice_name, hour, SUM(num_instances) AS num_instances FROM ( SELECT microservice_name, bin(time, 1h) AS hour, COUNT(DISTINCT instance_name) as num_instances FROM raw_data.devops WHERE time BETWEEN bin(@scheduled_runtime, 1h) - 1h AND @scheduled_runtime AND measure_name = 'metrics' GROUP BY region, cell, silo, availability_zone, microservice_name, bin(time, 1h) ) GROUP BY microservice_name, hour",
"ScheduleConfiguration": {
"ScheduleExpression": "cron(0/30 * * * ? *)"
},
"NotificationConfiguration": {
"SnsConfiguration": {
"TopicArn": "******"
}
},
"TargetConfiguration": {
"TimestreamConfiguration": {
"DatabaseName": "derived",
"TableName": "host_count_pt1h",
"TimeColumn": "hour",
"DimensionMappings": [
{
"Name": "microservice_name",
"DimensionValueType": "VARCHAR"
}
],
"MultiMeasureMappings": {
"TargetMultiMeasureName": "num_instances",
"MultiMeasureAttributeMappings": [
{
"SourceColumn": "num_instances",
"MeasureValueType": "BIGINT"
}
]
}
}
},
"ErrorReportConfiguration": {
"S3Configuration" : {
"BucketName" : "******",
"ObjectKeyPrefix": "errors",
"EncryptionOption": "SSE_S3"
}
},
"ScheduledQueryExecutionRoleArn": "******"
}
```
**Utilizzo dei risultati precalcolati in una nuova dashboard**
Ora vedrai come creare la tua dashboard di visualizzazione aggregata utilizzando la tabella derivata dalla query pianificata che hai creato. Dall'istantanea del dashboard, potrai anche verificare che anche gli aggregati calcolati dalla tabella derivata e dalla tabella di base corrispondano. Una volta create le dashboard utilizzando le tabelle derivate, noterete i tempi di caricamento notevolmente più rapidi e i costi inferiori legati all'utilizzo delle tabelle derivate rispetto al calcolo di questi aggregati a partire dai dati grezzi. Di seguito è riportata un'istantanea della dashboard che utilizza dati precalcolati e la query utilizzata per il rendering di questo pannello utilizzando i dati precalcolati memorizzati nella tabella «derivata».» host\$1count\$1pt1h». Nota che la struttura della query è molto simile alla query utilizzata nella dashboard sui dati grezzi, tranne per il fatto che utilizza la tabella derivata che calcola già i conteggi distinti che questa query sta aggregando.
![\[Instance count by microservice showing values for apollo, athena, demeter, hercules, and zeus.\]](http://docs.aws.amazon.com/it_it/timestream/latest/developerguide/images/sched_query_ex1_img2.png)
```
SELECT CASE WHEN microservice_name = 'apollo' THEN num_instances ELSE NULL END AS apollo,
CASE WHEN microservice_name = 'athena' THEN num_instances ELSE NULL END AS athena,
CASE WHEN microservice_name = 'demeter' THEN num_instances ELSE NULL END AS demeter,
CASE WHEN microservice_name = 'hercules' THEN num_instances ELSE NULL END AS hercules,
CASE WHEN microservice_name = 'zeus' THEN num_instances ELSE NULL END AS zeus
FROM (
SELECT microservice_name, AVG(num_instances) AS num_instances
FROM (
SELECT microservice_name, bin(time, 1h), SUM(num_instances) as num_instances
FROM "derived"."host_count_pt1h"
WHERE time BETWEEN from_milliseconds(1636567785421) AND from_milliseconds(1636654185421)
AND measure_name = 'num_instances'
GROUP BY microservice_name, bin(time, 1h)
)
GROUP BY microservice_name
)
```
# Utilizzo di query pianificate e dati non elaborati per i drill down
Puoi utilizzare le statistiche aggregate del tuo parco macchine per identificare le aree che necessitano di approfondimenti e quindi utilizzare i dati grezzi per approfondire i dati granulari e ottenere informazioni più approfondite.
In questo esempio, vedrete come utilizzare la dashboard aggregata per identificare qualsiasi implementazione (una distribuzione riguarda un determinato microservizio all'interno di una determinata regione, cella, silo e zona di disponibilità) che sembra avere un utilizzo della CPU maggiore rispetto ad altre implementazioni. È quindi possibile approfondire per comprendere meglio l'utilizzo dei dati grezzi. Poiché questi approfondimenti potrebbero essere poco frequenti e accedere solo ai dati pertinenti alla distribuzione, è possibile utilizzare i dati grezzi per questa analisi e non è necessario utilizzare query pianificate.
**Drill down per distribuzione**
La dashboard seguente fornisce informazioni dettagliate su statistiche più granulari e a livello di server all'interno di una determinata implementazione. Per aiutarti ad analizzare in dettaglio le diverse parti della tua flotta, questa dashboard utilizza variabili come region, cell, silo, microservice e availability\$1zone. Quindi mostra alcune statistiche aggregate per quella distribuzione.
![\[Dashboard showing deployment statistics with filters for region, cell, silo, and other parameters.\]](http://docs.aws.amazon.com/it_it/timestream/latest/developerguide/images/sched_query_ex2_img1.png)
![\[CPU distribution graph showing consistent patterns for avg, p90, p95, and p99 values over 24 hours.\]](http://docs.aws.amazon.com/it_it/timestream/latest/developerguide/images/sched_query_ex2_img2.png)
Nella query riportata di seguito, puoi vedere che i valori scelti nell'elenco a discesa delle variabili vengono utilizzati come predicati nella `WHERE` clausola della query, il che consente di concentrarti solo sui dati per la distribuzione. Quindi il pannello traccia le metriche aggregate della CPU per le istanze di quella distribuzione. È possibile utilizzare i dati grezzi per eseguire questo drill down con la latenza delle query interattive per ottenere informazioni più approfondite.
```
SELECT bin(time, 5m) as minute,
ROUND(AVG(cpu_user), 2) AS avg_value,
ROUND(APPROX_PERCENTILE(cpu_user, 0.9), 2) AS p90_value,
ROUND(APPROX_PERCENTILE(cpu_user, 0.95), 2) AS p95_value,
ROUND(APPROX_PERCENTILE(cpu_user, 0.99), 2) AS p99_value
FROM "raw_data"."devops"
WHERE time BETWEEN from_milliseconds(1636527099476) AND from_milliseconds(1636613499476)
AND region = 'eu-west-1'
AND cell = 'eu-west-1-cell-10'
AND silo = 'eu-west-1-cell-10-silo-1'
AND microservice_name = 'demeter'
AND availability_zone = 'eu-west-1-3'
AND measure_name = 'metrics'
GROUP BY bin(time, 5m)
ORDER BY 1
```
**Statistiche a livello di istanza**
Questa dashboard calcola ulteriormente un'altra variabile che elenca anche quelle servers/instances con un elevato utilizzo della CPU, ordinate in ordine decrescente di utilizzo. La query utilizzata per calcolare questa variabile viene visualizzata di seguito.
```
WITH microservice_cell_avg AS (
SELECT AVG(cpu_user) AS microservice_avg_metric
FROM "raw_data"."devops"
WHERE $__timeFilter
AND measure_name = 'metrics'
AND region = '${region}'
AND cell = '${cell}'
AND silo = '${silo}'
AND availability_zone = '${availability_zone}'
AND microservice_name = '${microservice}'
), instance_avg AS (
SELECT instance_name,
AVG(cpu_user) AS instance_avg_metric
FROM "raw_data"."devops"
WHERE $__timeFilter
AND measure_name = 'metrics'
AND region = '${region}'
AND cell = '${cell}'
AND silo = '${silo}'
AND microservice_name = '${microservice}'
AND availability_zone = '${availability_zone}'
GROUP BY availability_zone, instance_name
)
SELECT i.instance_name
FROM instance_avg i CROSS JOIN microservice_cell_avg m
WHERE i.instance_avg_metric > (1 + ${utilization_threshold}) * m.microservice_avg_metric
ORDER BY i.instance_avg_metric DESC
```
Nella query precedente, la variabile viene ricalcolata dinamicamente in base ai valori scelti per le altre variabili. Una volta compilata la variabile per una distribuzione, puoi selezionare singole istanze dall'elenco per visualizzare ulteriormente le metriche di quell'istanza. Puoi scegliere le diverse istanze dal menu a discesa dei nomi delle istanze, come mostrato nell'istantanea qui sotto.
![\[List of Amazon Web Services (AWS) resource identifiers for Demeter instances in eu-west-1 region.\]](http://docs.aws.amazon.com/it_it/timestream/latest/developerguide/images/sched_query_ex2_img3.png)
![\[Dashboard showing CPU utilization, memory usage, GC pause events, and disk I/O metrics for an AWS instance.\]](http://docs.aws.amazon.com/it_it/timestream/latest/developerguide/images/sched_query_ex2_img4.png)
I pannelli precedenti mostrano le statistiche per l'istanza selezionata e di seguito sono riportate le query utilizzate per recuperare queste statistiche.
```
SELECT BIN(time, 30m) AS time_bin,
AVG(cpu_user) AS avg_cpu,
ROUND(APPROX_PERCENTILE(cpu_user, 0.99), 2) as p99_cpu
FROM "raw_data"."devops"
WHERE time BETWEEN from_milliseconds(1636527099477) AND from_milliseconds(1636613499477)
AND measure_name = 'metrics'
AND region = 'eu-west-1' AND cell = 'eu-west-1-cell-10' AND silo = 'eu-west-1-cell-10-silo-1'
AND availability_zone = 'eu-west-1-3' AND microservice_name = 'demeter'
AND instance_name = 'i-zaZswmJk-demeter-eu-west-1-cell-10-silo-1-00000272.amazonaws.com'
GROUP BY BIN(time, 30m)
ORDER BY time_bin desc
```
```
SELECT BIN(time, 30m) AS time_bin,
AVG(memory_used) AS avg_memory,
ROUND(APPROX_PERCENTILE(memory_used, 0.99), 2) as p99_memory
FROM "raw_data"."devops"
WHERE time BETWEEN from_milliseconds(1636527099477) AND from_milliseconds(1636613499477)
AND measure_name = 'metrics'
AND region = 'eu-west-1' AND cell = 'eu-west-1-cell-10' AND silo = 'eu-west-1-cell-10-silo-1'
AND availability_zone = 'eu-west-1-3' AND microservice_name = 'demeter'
AND instance_name = 'i-zaZswmJk-demeter-eu-west-1-cell-10-silo-1-00000272.amazonaws.com'
GROUP BY BIN(time, 30m)
ORDER BY time_bin desc
```
```
SELECT COUNT(gc_pause)
FROM "raw_data"."devops"
WHERE time BETWEEN from_milliseconds(1636527099477) AND from_milliseconds(1636613499478)
AND measure_name = 'events'
AND region = 'eu-west-1' AND cell = 'eu-west-1-cell-10' AND silo = 'eu-west-1-cell-10-silo-1'
AND availability_zone = 'eu-west-1-3' AND microservice_name = 'demeter'
AND instance_name = 'i-zaZswmJk-demeter-eu-west-1-cell-10-silo-1-00000272.amazonaws.com'
```
```
SELECT avg(gc_pause) as avg, round(approx_percentile(gc_pause, 0.99), 2) as p99
FROM "raw_data"."devops"
WHERE time BETWEEN from_milliseconds(1636527099478) AND from_milliseconds(1636613499478)
AND measure_name = 'events'
AND region = 'eu-west-1' AND cell = 'eu-west-1-cell-10' AND silo = 'eu-west-1-cell-10-silo-1'
AND availability_zone = 'eu-west-1-3' AND microservice_name = 'demeter'
AND instance_name = 'i-zaZswmJk-demeter-eu-west-1-cell-10-silo-1-00000272.amazonaws.com'
```
```
SELECT BIN(time, 30m) AS time_bin,
AVG(disk_io_reads) AS avg,
ROUND(APPROX_PERCENTILE(disk_io_reads, 0.99), 2) as p99
FROM "raw_data"."devops"
WHERE time BETWEEN from_milliseconds(1636527099478) AND from_milliseconds(1636613499478)
AND measure_name = 'metrics'
AND region = 'eu-west-1' AND cell = 'eu-west-1-cell-10' AND silo = 'eu-west-1-cell-10-silo-1'
AND availability_zone = 'eu-west-1-3' AND microservice_name = 'demeter'
AND instance_name = 'i-zaZswmJk-demeter-eu-west-1-cell-10-silo-1-00000272.amazonaws.com'
GROUP BY BIN(time, 30m)
ORDER BY time_bin desc
```
# Ottimizzazione dei costi condividendo le query pianificate tra i dashboard
In questo esempio, vedremo uno scenario in cui più pannelli di dashboard visualizzano variazioni di informazioni simili (individuando host di CPU elevati e una frazione del parco macchine con un elevato utilizzo della CPU) e come è possibile utilizzare la stessa query pianificata per precalcolare i risultati, che vengono poi utilizzati per popolare più pannelli. Questo riutilizzo ottimizza ulteriormente i costi laddove invece di utilizzare diverse query pianificate, una per ogni pannello, si utilizza only owner.
## Pannelli di controllo con dati grezzi
**Utilizzo della CPU per regione per microservizio**
Il primo pannello calcola le istanze il cui utilizzo medio della CPU è una soglia inferiore o superiore all'utilizzo della CPU indicato sopra per una determinata distribuzione all'interno di una regione, cella, silo, zona di disponibilità e microservizio. Quindi ordina la regione e il microservizio che hanno la più alta percentuale di host con un elevato utilizzo. Consente di identificare la temperatura di funzionamento dei server di una specifica implementazione e successivamente approfondisce i problemi per comprendere meglio i problemi.
La query per il pannello dimostra la flessibilità del supporto SQL di Timestream for per eseguire attività analitiche complesse con espressioni di tabella, funzioni di finestra, join e LiveAnalytics così via comuni.
![\[Table showing CPU utilization data for microservices across different regions.\]](http://docs.aws.amazon.com/it_it/timestream/latest/developerguide/images/sched_query_ex3_img1.png)
*Interrogazione:*
```
WITH microservice_cell_avg AS (
SELECT region, cell, silo, availability_zone, microservice_name, AVG(cpu_user) AS microservice_avg_metric
FROM "raw_data"."devops"
WHERE time BETWEEN from_milliseconds(1636526593876) AND from_milliseconds(1636612993876)
AND measure_name = 'metrics'
GROUP BY region, cell, silo, availability_zone, microservice_name
), instance_avg AS (
SELECT region, cell, silo, availability_zone, microservice_name, instance_name,
AVG(cpu_user) AS instance_avg_metric
FROM "raw_data"."devops"
WHERE time BETWEEN from_milliseconds(1636526593876) AND from_milliseconds(1636612993876)
AND measure_name = 'metrics'
GROUP BY region, cell, silo, availability_zone, microservice_name, instance_name
), instances_above_threshold AS (
SELECT i.*,
CASE WHEN i.instance_avg_metric > (1 + 0.2) * m.microservice_avg_metric THEN 1 ELSE 0 END AS high_utilization,
CASE WHEN i.instance_avg_metric < (1 - 0.2) * m.microservice_avg_metric THEN 1 ELSE 0 END AS low_utilization
FROM instance_avg i INNER JOIN microservice_cell_avg m
ON i.region = m.region AND i.cell = m.cell AND i.silo = m.silo AND i.availability_zone = m.availability_zone
AND m.microservice_name = i.microservice_name
), per_deployment_high AS (
SELECT region, microservice_name, COUNT(*) AS num_hosts, SUM(high_utilization) AS high_utilization_hosts, SUM(low_utilization) AS low_utilization_hosts,
ROUND(SUM(high_utilization) * 100.0 / COUNT(*), 0) AS percent_high_utilization_hosts,
ROUND(SUM(low_utilization) * 100.0 / COUNT(*), 0) AS percent_low_utilization_hosts
FROM instances_above_threshold
GROUP BY region, microservice_name
), per_region_ranked AS (
SELECT *,
DENSE_RANK() OVER (PARTITION BY region ORDER BY percent_high_utilization_hosts DESC, high_utilization_hosts DESC) AS rank
FROM per_deployment_high
)
SELECT *
FROM per_region_ranked
WHERE rank <= 2
ORDER BY percent_high_utilization_hosts desc, rank asc
```
**Approfondisci un microservizio per trovare gli hot spot**
La dashboard successiva consente di approfondire uno dei microservizi per scoprire la regione, la cella e il silo specifici in cui tale microservizio è in esecuzione, quale frazione della sua flotta utilizza un maggiore utilizzo della CPU. Ad esempio, nella dashboard a livello di flotta, hai visto il microservizio demeter apparire nelle prime posizioni in classifica, quindi in questa dashboard vuoi approfondire quel microservizio.
Questa dashboard utilizza una variabile per selezionare il microservizio da approfondire e i valori della variabile vengono compilati utilizzando valori univoci della dimensione. Una volta selezionato il microservizio, il resto della dashboard si aggiorna.
Come illustrato di seguito, il primo pannello riporta la percentuale di host in una distribuzione (una regione, una cella e un silo per un microservizio) nel tempo e la query corrispondente utilizzata per tracciare la dashboard. Questo grafico stesso identifica una distribuzione specifica con una percentuale più elevata di host con CPU elevata.
![\[Dropdown menu showing "microservice", "demeter", "topk", and "2" options.\]](http://docs.aws.amazon.com/it_it/timestream/latest/developerguide/images/sched_query_ex3_img2.png)
![\[Graph showing deployments with high CPU utilization over time, with multiple flat lines.\]](http://docs.aws.amazon.com/it_it/timestream/latest/developerguide/images/sched_query_ex3_img3.png)
*Interrogazione*:
```
WITH microservice_cell_avg AS (
SELECT region, cell, silo, availability_zone, microservice_name, bin(time, 1h) as hour, AVG(cpu_user) AS microservice_avg_metric
FROM "raw_data"."devops"
WHERE time BETWEEN from_milliseconds(1636526898831) AND from_milliseconds(1636613298831)
AND measure_name = 'metrics'
AND microservice_name = 'demeter'
GROUP BY region, cell, silo, availability_zone, microservice_name, bin(time, 1h)
), instance_avg AS (
SELECT region, cell, silo, availability_zone, microservice_name, instance_name, bin(time, 1h) as hour,
AVG(cpu_user) AS instance_avg_metric
FROM "raw_data"."devops"
WHERE time BETWEEN from_milliseconds(1636526898831) AND from_milliseconds(1636613298831)
AND measure_name = 'metrics'
AND microservice_name = 'demeter'
GROUP BY region, cell, silo, availability_zone, microservice_name, instance_name, bin(time, 1h)
), instances_above_threshold AS (
SELECT i.*,
CASE WHEN i.instance_avg_metric > (1 + 0.2) * m.microservice_avg_metric THEN 1 ELSE 0 END AS high_utilization
FROM instance_avg i INNER JOIN microservice_cell_avg m
ON i.region = m.region AND i.cell = m.cell AND i.silo = m.silo AND i.availability_zone = m.availability_zone
AND m.microservice_name = i.microservice_name AND m.hour = i.hour
), high_utilization_percent AS (
SELECT region, cell, silo, microservice_name, hour, COUNT(*) AS num_hosts, SUM(high_utilization) AS high_utilization_hosts,
ROUND(SUM(high_utilization) * 100.0 / COUNT(*), 0) AS percent_high_utilization_hosts
FROM instances_above_threshold
GROUP BY region, cell, silo, microservice_name, hour
), high_utilization_ranked AS (
SELECT region, cell, silo, microservice_name,
DENSE_RANK() OVER (PARTITION BY region ORDER BY AVG(percent_high_utilization_hosts) desc, AVG(high_utilization_hosts) desc) AS rank
FROM high_utilization_percent
GROUP BY region, cell, silo, microservice_name
)
SELECT hup.silo, CREATE_TIME_SERIES(hour, hup.percent_high_utilization_hosts) AS percent_high_utilization_hosts
FROM high_utilization_percent hup INNER JOIN high_utilization_ranked hur
ON hup.region = hur.region AND hup.cell = hur.cell AND hup.silo = hur.silo AND hup.microservice_name = hur.microservice_name
WHERE rank <= 2
GROUP BY hup.region, hup.cell, hup.silo
ORDER BY hup.silo
```
## Conversione in un'unica query pianificata che ne consente il riutilizzo
È importante notare che un calcolo simile viene eseguito nei diversi pannelli delle due dashboard. È possibile definire un'interrogazione pianificata separata per ogni pannello. Qui vedrete come ottimizzare ulteriormente i costi definendo un'interrogazione pianificata i cui risultati possono essere utilizzati per il rendering di tutti e tre i pannelli.
Di seguito è riportata la query che acquisisce gli aggregati calcolati e utilizzati per tutti i diversi pannelli. Osserverete diversi aspetti importanti nella definizione di questa interrogazione pianificata.
+ La flessibilità e la potenza dell'area di superficie SQL supportate dalle query pianificate, in cui è possibile utilizzare espressioni di tabella comuni, join, case statement, ecc.
+ È possibile utilizzare una query pianificata per calcolare le statistiche con una granularità più precisa di quella necessaria per un dashboard specifico e per tutti i valori che un dashboard potrebbe utilizzare per diverse variabili. Ad esempio, vedrai che gli aggregati vengono calcolati su una regione, una cella, un silo e un microservizio. Pertanto, puoi combinarli per creare aggregati a livello di regione o regione e a livello di microservizi. Analogamente, la stessa query calcola gli aggregati per tutte le regioni, le celle, i silos e i microservizi. Consente di applicare filtri su queste colonne per ottenere gli aggregati per un sottoinsieme di valori. Ad esempio, puoi calcolare gli aggregati per qualsiasi regione, ad esempio us-east-1, o qualsiasi microservizio, ad esempio demeter, o approfondire un'implementazione specifica all'interno di una regione, cella, silo e microservizio. Questo approccio ottimizza ulteriormente i costi di manutenzione degli aggregati precalcolati.
```
WITH microservice_cell_avg AS (
SELECT region, cell, silo, availability_zone, microservice_name, bin(time, 1h) as hour, AVG(cpu_user) AS microservice_avg_metric
FROM raw_data.devops
WHERE time BETWEEN bin(@scheduled_runtime, 1h) - 1h AND bin(@scheduled_runtime, 1h) + 1h
AND measure_name = 'metrics'
GROUP BY region, cell, silo, availability_zone, microservice_name, bin(time, 1h)
), instance_avg AS (
SELECT region, cell, silo, availability_zone, microservice_name, instance_name, bin(time, 1h) as hour,
AVG(cpu_user) AS instance_avg_metric
FROM raw_data.devops
WHERE time BETWEEN bin(@scheduled_runtime, 1h) - 1h AND bin(@scheduled_runtime, 1h) + 1h
AND measure_name = 'metrics'
GROUP BY region, cell, silo, availability_zone, microservice_name, instance_name, bin(time, 1h)
), instances_above_threshold AS (
SELECT i.*,
CASE WHEN i.instance_avg_metric > (1 + 0.2) * m.microservice_avg_metric THEN 1 ELSE 0 END AS high_utilization,
CASE WHEN i.instance_avg_metric < (1 - 0.2) * m.microservice_avg_metric THEN 1 ELSE 0 END AS low_utilization
FROM instance_avg i INNER JOIN microservice_cell_avg m
ON i.region = m.region AND i.cell = m.cell AND i.silo = m.silo AND i.availability_zone = m.availability_zone
AND m.microservice_name = i.microservice_name AND m.hour = i.hour
)
SELECT region, cell, silo, microservice_name, hour,
COUNT(*) AS num_hosts, SUM(high_utilization) AS high_utilization_hosts, SUM(low_utilization) AS low_utilization_hosts
FROM instances_above_threshold GROUP BY region, cell, silo, microservice_name, hour
```
Di seguito è riportata una definizione di interrogazione pianificata per la query precedente. L'espressione di pianificazione è configurata per l'aggiornamento ogni 30 minuti e aggiorna i dati fino a un'ora precedente, utilizzando sempre il costrutto bin (@scheduled\$1runtime, 1h) per ottenere gli eventi dell'intera ora. A seconda dei requisiti di aggiornamento dell'applicazione, è possibile configurarla in modo che si aggiorni più o meno frequentemente. Utilizzando WHERE time BETWEEN bin (@scheduled\$1runtime, 1h) - 1h AND bin (@scheduled\$1runtime, 1h) \$1 1h, possiamo garantire che anche se esegui l'aggiornamento una volta ogni 15 minuti, otterrai i dati dell'intera ora per l'ora corrente e l'ora precedente.
Più avanti, vedrai come i tre pannelli utilizzano questi aggregati scritti nella tabella deployment\$1cpu\$1stats\$1per\$1hr per visualizzare le metriche rilevanti per il pannello.
```
{
"Name": "MultiPT30mHighCpuDeploymentsPerHr",
"QueryString": "WITH microservice_cell_avg AS ( SELECT region, cell, silo, availability_zone, microservice_name, bin(time, 1h) as hour, AVG(cpu_user) AS microservice_avg_metric FROM raw_data.devops WHERE time BETWEEN bin(@scheduled_runtime, 1h) - 1h AND bin(@scheduled_runtime, 1h) + 1h AND measure_name = 'metrics' GROUP BY region, cell, silo, availability_zone, microservice_name, bin(time, 1h) ), instance_avg AS ( SELECT region, cell, silo, availability_zone, microservice_name, instance_name, bin(time, 1h) as hour, AVG(cpu_user) AS instance_avg_metric FROM raw_data.devops WHERE time BETWEEN bin(@scheduled_runtime, 1h) - 1h AND bin(@scheduled_runtime, 1h) + 1h AND measure_name = 'metrics' GROUP BY region, cell, silo, availability_zone, microservice_name, instance_name, bin(time, 1h) ), instances_above_threshold AS ( SELECT i.*, CASE WHEN i.instance_avg_metric > (1 + 0.2) * m.microservice_avg_metric THEN 1 ELSE 0 END AS high_utilization, CASE WHEN i.instance_avg_metric < (1 - 0.2) * m.microservice_avg_metric THEN 1 ELSE 0 END AS low_utilization FROM instance_avg i INNER JOIN microservice_cell_avg m ON i.region = m.region AND i.cell = m.cell AND i.silo = m.silo AND i.availability_zone = m.availability_zone AND m.microservice_name = i.microservice_name AND m.hour = i.hour ) SELECT region, cell, silo, microservice_name, hour, COUNT(*) AS num_hosts, SUM(high_utilization) AS high_utilization_hosts, SUM(low_utilization) AS low_utilization_hosts FROM instances_above_threshold GROUP BY region, cell, silo, microservice_name, hour",
"ScheduleConfiguration": {
"ScheduleExpression": "cron(0/30 * * * ? *)"
},
"NotificationConfiguration": {
"SnsConfiguration": {
"TopicArn": "******"
}
},
"TargetConfiguration": {
"TimestreamConfiguration": {
"DatabaseName": "derived",
"TableName": "deployment_cpu_stats_per_hr",
"TimeColumn": "hour",
"DimensionMappings": [
{
"Name": "region",
"DimensionValueType": "VARCHAR"
},
{
"Name": "cell",
"DimensionValueType": "VARCHAR"
},
{
"Name": "silo",
"DimensionValueType": "VARCHAR"
},
{
"Name": "microservice_name",
"DimensionValueType": "VARCHAR"
}
],
"MultiMeasureMappings": {
"TargetMultiMeasureName": "cpu_user",
"MultiMeasureAttributeMappings": [
{
"SourceColumn": "num_hosts",
"MeasureValueType": "BIGINT"
},
{
"SourceColumn": "high_utilization_hosts",
"MeasureValueType": "BIGINT"
},
{
"SourceColumn": "low_utilization_hosts",
"MeasureValueType": "BIGINT"
}
]
}
}
},
"ErrorReportConfiguration": {
"S3Configuration" : {
"BucketName" : "******",
"ObjectKeyPrefix": "errors",
"EncryptionOption": "SSE_S3"
}
},
"ScheduledQueryExecutionRoleArn": "******"
}
```
## Dashboard con risultati precalcolati
**Host ad alto utilizzo della CPU**
Per gli host ad alto utilizzo, vedrai come i diversi pannelli utilizzano i dati di deployment\$1cpu\$1stats\$1per\$1hr per calcolare i diversi aggregati necessari per i pannelli. Ad esempio, questo pannello fornisce informazioni a livello di regione, quindi riporta gli aggregati raggruppati per regione e microservizio, senza filtrare alcuna regione o microservizio.
![\[Table showing microservice utilization stats across regions, with high and low host percentages.\]](http://docs.aws.amazon.com/it_it/timestream/latest/developerguide/images/sched_query_ex3_img4.png)
```
WITH per_deployment_hosts AS (
SELECT region, cell, silo, microservice_name,
AVG(num_hosts) AS num_hosts,
AVG(high_utilization_hosts) AS high_utilization_hosts,
AVG(low_utilization_hosts) AS low_utilization_hosts
FROM "derived"."deployment_cpu_stats_per_hr"
WHERE time BETWEEN from_milliseconds(1636567785437) AND from_milliseconds(1636654185437)
AND measure_name = 'cpu_user'
GROUP BY region, cell, silo, microservice_name
), per_deployment_high AS (
SELECT region, microservice_name,
SUM(num_hosts) AS num_hosts,
ROUND(SUM(high_utilization_hosts), 0) AS high_utilization_hosts,
ROUND(SUM(low_utilization_hosts),0) AS low_utilization_hosts,
ROUND(SUM(high_utilization_hosts) * 100.0 / SUM(num_hosts)) AS percent_high_utilization_hosts,
ROUND(SUM(low_utilization_hosts) * 100.0 / SUM(num_hosts)) AS percent_low_utilization_hosts
FROM per_deployment_hosts
GROUP BY region, microservice_name
),
per_region_ranked AS (
SELECT *,
DENSE_RANK() OVER (PARTITION BY region ORDER BY percent_high_utilization_hosts DESC, high_utilization_hosts DESC) AS rank
FROM per_deployment_high
)
SELECT *
FROM per_region_ranked
WHERE rank <= 2
ORDER BY percent_high_utilization_hosts desc, rank asc
```
**Approfondisci un microservizio per individuare implementazioni con elevato utilizzo della CPU**
Il prossimo esempio utilizza nuovamente la tabella derivata deployment\$1cpu\$1stats\$1per\$1hr, ma ora applica un filtro per un microservizio specifico (demeter in questo esempio, poiché nella dashboard aggregata sono stati segnalati host ad alto utilizzo). Questo pannello tiene traccia della percentuale di host ad alto utilizzo della CPU nel tempo.
![\[Graph showing consistent high CPU utilization percentages for multiple deployments over 24 hours.\]](http://docs.aws.amazon.com/it_it/timestream/latest/developerguide/images/sched_query_ex3_img5.png)
```
WITH high_utilization_percent AS (
SELECT region, cell, silo, microservice_name, bin(time, 1h) AS hour, MAX(num_hosts) AS num_hosts,
MAX(high_utilization_hosts) AS high_utilization_hosts,
ROUND(MAX(high_utilization_hosts) * 100.0 / MAX(num_hosts)) AS percent_high_utilization_hosts
FROM "derived"."deployment_cpu_stats_per_hr"
WHERE time BETWEEN from_milliseconds(1636525800000) AND from_milliseconds(1636612200000)
AND measure_name = 'cpu_user'
AND microservice_name = 'demeter'
GROUP BY region, cell, silo, microservice_name, bin(time, 1h)
), high_utilization_ranked AS (
SELECT region, cell, silo, microservice_name,
DENSE_RANK() OVER (PARTITION BY region ORDER BY AVG(percent_high_utilization_hosts) desc, AVG(high_utilization_hosts) desc) AS rank
FROM high_utilization_percent
GROUP BY region, cell, silo, microservice_name
)
SELECT hup.silo, CREATE_TIME_SERIES(hour, hup.percent_high_utilization_hosts) AS percent_high_utilization_hosts
FROM high_utilization_percent hup INNER JOIN high_utilization_ranked hur
ON hup.region = hur.region AND hup.cell = hur.cell AND hup.silo = hur.silo AND hup.microservice_name = hur.microservice_name
WHERE rank <= 2
GROUP BY hup.region, hup.cell, hup.silo
ORDER BY hup.silo
```
# Confronto di un'interrogazione su una tabella di base con un'interrogazione dei risultati di una query pianificata
In questo esempio di query Timestream, utilizziamo lo schema, le query di esempio e gli output seguenti per confrontare una query su una tabella di base con una query su una tabella derivata di risultati di query pianificate. Con una query pianificata correttamente, è possibile ottenere una tabella derivata con un minor numero di righe e altre caratteristiche che possono portare a query più veloci di quelle possibili sulla tabella base originale.
Per un video che descrive questo scenario, consulta [Migliorare le prestazioni delle query e ridurre i costi utilizzando le query pianificate in Amazon Timestream](https://youtu.be/x8AgLhAydzY) for. LiveAnalytics
Per questo esempio, utilizziamo lo scenario seguente:
+ **Regione**: us-east-1
+ **Tavolo base** — `"clickstream"."shopping"`
+ **Tabella derivata** — `"clickstream"."aggregate"`
## Tabella di base
Di seguito viene descritto lo schema per la tabella di base.
| Colonna | Tipo | Timestream per LiveAnalytics il tipo di attributo |
| --- | --- | --- |
| channel | varchar | MULTIPLO |
| description | varchar | MULTI |
| evento | varchar | DIMENSIONE |
| ip\$1address | varchar | DIMENSIONE |
| measure\$1name | varchar | MEASURE\$1NAME |
| product | varchar | MULTI |
| product\$1id | varchar | MULTI |
| quantity | virgola mobile a doppia precisione | MULTI |
| query | varchar | MULTI |
| session\$1id | varchar | DIMENSIONE |
| gruppo\$1utenti | varchar | DIMENSIONE |
| user\$1id | varchar | DIMENSIONE |
Di seguito vengono descritte le misure per la tabella base. Una *tabella di base* si riferisce a una tabella in Timestream su cui viene eseguita la query pianificata.
+ **nome\$1misura —** `metrics`
+ **data** — multiplo
+ **dimensioni:**
```
[ ( user_group, varchar ),( user_id, varchar ),( session_id, varchar ),( ip_address, varchar ),( event, varchar ) ]
```
## Interrogazione su una tabella di base
Di seguito è riportata una query ad hoc che raccoglie i conteggi in base a un aggregato di 5 minuti in un determinato intervallo di tempo.
```
SELECT BIN(time, 5m) as time,
channel,
product_id,
SUM(quantity) as product_quantity
FROM "clickstream"."shopping"
WHERE BIN(time, 5m) BETWEEN '2023-05-11 10:10:00.000000000' AND '2023-05-11 10:30:00.000000000'
AND channel = 'Social media'
and product_id = '431412'
GROUP BY BIN(time, 5m),channel,product_id
```
Output:
```
duration:1.745 sec
Bytes scanned: 29.89 MB
Query Id: AEBQEANMHG7MHHBHCKJ3BSOE3QUGIDBGWCCP5I6J6YUW5CVJZ2M3JCJ27QRMM7A
Row count:5
```
## Query pianificata
Di seguito è riportata una query pianificata che viene eseguita ogni 5 minuti.
```
SELECT BIN(time, 5m) as time, channel as measure_name, product_id, product,
SUM(quantity) as product_quantity
FROM "clickstream"."shopping"
WHERE time BETWEEN BIN(@scheduled_runtime, 5m) - 10m AND BIN(@scheduled_runtime, 5m) - 5m
AND channel = 'Social media'
GROUP BY BIN(time, 5m), channel, product_id, product
```
## Interrogazione su una tabella derivata
Di seguito è riportata una query ad hoc su una tabella derivata. Una *tabella derivata* si riferisce a una tabella Timestream che contiene i risultati di una query pianificata.
```
SELECT time, measure_name, product_id,product_quantity
FROM "clickstream"."aggregate"
WHERE time BETWEEN '2023-05-11 10:10:00.000000000' AND '2023-05-11 10:30:00.000000000'
AND measure_name = 'Social media'
and product_id = '431412'
```
Output:
```
duration: 0.2960 sec
Bytes scanned: 235.00 B
QueryID: AEBQEANMHHAAQU4FFTT6CFM6UYXTL4SMLZV22MFP4KV2Z7IRVOPLOMLDD6BR33Q
Row count: 5
```
## Confronto
Di seguito è riportato un confronto tra i risultati di una query su una tabella di base e di un'interrogazione su una tabella derivata. La stessa query su una tabella derivata con risultati aggregati eseguiti tramite una query pianificata viene completata più rapidamente con un minor numero di byte scansionati.
Questi risultati mostrano l'utilità dell'utilizzo di query pianificate per aggregare i dati per ottenere query più rapide.
| | Interrogazione sulla tabella di base | Interrogazione sulla tabella derivata |
| --- | --- | --- |
| Durata | 1.745 sec | 0,2960 sec |
| Byte scansionati | 29,89 MB | 235 byte |
| Numero di righe | 5 | 5 |
# Utilizzo di UNLOAD per esportare i risultati delle query su S3 da Timestream per LiveAnalytics
Amazon Timestream LiveAnalytics per ora ti consente di esportare i risultati delle tue query su Amazon S3 in modo economico e sicuro utilizzando l'istruzione. `UNLOAD` Utilizzando l'`UNLOAD`istruzione, ora puoi esportare i dati delle serie temporali in bucket S3 selezionati in formato Apache Parquet o Comma Separated Values (CSV), il che offre la flessibilità necessaria per archiviare, combinare e analizzare i dati delle serie temporali con altri servizi. L'`UNLOAD`istruzione consente di esportare i dati in modo compresso, il che riduce i dati trasferiti e lo spazio di archiviazione richiesto. `UNLOAD`supporta anche il partizionamento basato su attributi selezionati durante l'esportazione dei dati, migliorando le prestazioni e riducendo i tempi di elaborazione dei servizi a valle che accedono ai dati. Inoltre, puoi utilizzare chiavi gestite Amazon S3 (SSE-S3) o AWS chiavi gestite da Amazon S3 (AWS SSE-KMS) per crittografare i dati esportati.
## Vantaggi di UNLOAD di Timestream per LiveAnalytics
I vantaggi principali dell'utilizzo della `UNLOAD` dichiarazione sono i seguenti.
+ **Facilità operativa**: con l'`UNLOAD`istruzione, è possibile esportare gigabyte di dati in un'unica richiesta di query in formato Apache Parquet o CSV, offrendo la flessibilità necessaria per selezionare il formato più adatto alle esigenze di elaborazione a valle e semplificando la creazione di data lake.
+ **Sicuro ed economico**: `UNLOAD` statement offre la possibilità di esportare i dati in un bucket S3 in modo compresso e di crittografare (SSE-KMS o SSE\$1S3) i dati utilizzando chiavi gestite dal cliente, riducendo i costi di archiviazione dei dati e proteggendo dall'accesso non autorizzato.
+ **Prestazioni**: utilizzando l'`UNLOAD`istruzione, puoi partizionare i dati durante l'esportazione in un bucket S3. Il partizionamento dei dati consente ai servizi a valle di elaborare i dati in parallelo, riducendone i tempi di elaborazione. Inoltre, i servizi a valle possono elaborare solo i dati di cui hanno bisogno, riducendo le risorse di elaborazione necessarie e quindi i costi associati.
## Casi d'uso di UNLOAD from Timestream per LiveAnalytics
Puoi utilizzare l'`UNLOAD`istruzione per scrivere dati nel tuo bucket S3 nei seguenti modi.
+ **Crea un data warehouse**: puoi esportare gigabyte di risultati delle query nel bucket S3 e aggiungere più facilmente dati di serie temporali al tuo data lake. Puoi utilizzare servizi come Amazon Athena e Amazon Redshift per combinare i dati delle tue serie temporali con altri dati pertinenti per ricavare informazioni aziendali complesse.
+ **Crea pipeline di dati AI e ML**: la `UNLOAD` dichiarazione ti consente di creare facilmente pipeline di dati per i tuoi modelli di machine learning che accedono ai dati delle serie temporali, semplificando l'utilizzo dei dati delle serie temporali con servizi come Amazon e SageMaker Amazon EMR.
+ **Semplifica l'elaborazione ETL**: l'esportazione dei dati in bucket S3 può semplificare il processo di esecuzione delle operazioni di estrazione, trasformazione, caricamento (ETL) sui dati, consentendoti di utilizzare senza problemi strumenti o servizi di terze parti AWS come AWS Glue per elaborare e trasformare i dati.
# SCARICA I CONCETTI
## Sintassi
```
UNLOAD (SELECT statement)
TO 's3://bucket-name/folder'
WITH ( option = expression [, ...] )
```
dov'è `option`
```
{ partitioned_by = ARRAY[ col_name[,…] ]
| format = [ '{ CSV | PARQUET }' ]
| compression = [ '{ GZIP | NONE }' ]
| encryption = [ '{ SSE_KMS | SSE_S3 }' ]
| kms_key = ''
| field_delimiter =''
| escaped_by = ''
| include_header = ['{true, false}']
| max_file_size = ''
| }
```
## Parameters
dichiarazione SELECT
L'istruzione di query utilizzata per selezionare e recuperare i dati da uno o più Timestream per le tabelle. LiveAnalytics
```
(SELECT column 1, column 2, column 3 from database.table
where measure_name = "ABC" and timestamp between ago (1d) and now() )
```
Clausola TO
```
TO 's3://bucket-name/folder'
```
or
```
TO 's3://access-point-alias/folder'
```
La `TO` clausola dell'`UNLOAD`istruzione specifica la destinazione dell'output dei risultati della query. È necessario fornire il percorso completo, incluso il nome del bucket Amazon S3 o Amazon S3 con access-point-alias posizione della cartella su Amazon S3 dove Timestream for scrive gli oggetti del file di output. LiveAnalytics Il bucket S3 deve appartenere allo stesso account e nella stessa regione. Oltre al set di risultati della query, Timestream for LiveAnalytics scrive i file manifest e di metadati nella cartella di destinazione specificata.
Clausola PARTITIONED\$1BY
```
partitioned_by = ARRAY [col_name[,…] , (default: none)
```
La `partitioned_by` clausola viene utilizzata nelle query per raggruppare e analizzare i dati a livello granulare. Quando esporti i risultati della query nel bucket S3, puoi scegliere di partizionare i dati in base a una o più colonne nella query di selezione. Durante il partizionamento dei dati, i dati esportati vengono suddivisi in sottoinsiemi in base alla colonna della partizione e ogni sottoinsieme viene archiviato in una cartella separata. All'interno della cartella dei risultati che contiene i dati esportati, viene creata automaticamente una sottocartella. `folder/results/partition column = partition value/` Tuttavia, tieni presente che le colonne partizionate non sono incluse nel file di output.
`partitioned_by`non è una clausola obbligatoria nella sintassi. Se si sceglie di esportare i dati senza alcun partizionamento, è possibile escludere la clausola nella sintassi.
**Example**
Supponendo che tu stia monitorando i dati clickstream del tuo sito Web e che tu abbia 5 canali di traffico, vale a dire,, e. `direct` `Social Media` `Organic Search` `Other` `Referral` Quando si esportano i dati, è possibile scegliere di partizionarli utilizzando la colonna. `Channel` All'interno della tua cartella dati`s3://bucketname/results`, avrai cinque cartelle ciascuna con il rispettivo nome del canale, ad esempio, `s3://bucketname/results/channel=Social Media/.` all'interno di questa cartella troverai i dati di tutti i clienti che sono arrivati sul tuo sito web attraverso il `Social Media` canale. Allo stesso modo, avrai altre cartelle per i canali rimanenti.
Dati esportati partizionati per colonna Channel
![\[Folder structure showing channels: Direct, Organic search, Other, Referral, and Social media.\]](http://docs.aws.amazon.com/it_it/timestream/latest/developerguide/images/unload-results.png)
FORMAT
```
format = [ '{ CSV | PARQUET }' , default: CSV
```
Le parole chiave per specificare il formato dei risultati della query scritti nel bucket S3. È possibile esportare i dati come valore separato da virgole (CSV) utilizzando una virgola (,) come delimitatore predefinito o nel formato Apache Parquet, un efficiente formato di archiviazione a colonne aperto per l'analisi.
COMPRESSIONE
```
compression = [ '{ GZIP | NONE }' ], default: GZIP
```
È possibile comprimere i dati esportati utilizzando l'algoritmo di compressione GZIP o decomprimerli specificando l'opzione. `NONE`
ENCRYPTION
```
encryption = [ '{ SSE_KMS | SSE_S3 }' ], default: SSE_S3
```
I file di output su Amazon S3 vengono crittografati utilizzando l'opzione di crittografia selezionata. Oltre ai dati, anche i file manifest e i file di metadati vengono crittografati in base all'opzione di crittografia selezionata. Attualmente supportiamo la crittografia SSE\$1S3 e SSE\$1KMS. SSE\$1S3 è una crittografia lato server con Amazon S3 che crittografa i dati utilizzando la crittografia AES (Advanced Encryption Standard) a 256 bit. SSE\$1KMS è una crittografia lato server per crittografare i dati utilizzando chiavi gestite dal cliente.
KMS\$1KEY
```
kms_key = ''
```
KMS Key è una chiave definita dal cliente per crittografare i risultati delle query esportate. KMS Key è gestita in modo sicuro da AWS Key Management Service (AWS KMS) e utilizzata per crittografare i file di dati su Amazon S3.
FIELD\$1DELIMITER
```
field_delimiter ='' , default: (,)
```
Quando si esportano i dati in formato CSV, questo campo specifica un singolo carattere ASCII utilizzato per separare i campi nel file di output, ad esempio il carattere pipe (\$1), la virgola (,) o il tab (/t). Il delimitatore predefinito per i file CSV è una virgola. Se un valore nei dati contiene il delimitatore scelto, il delimitatore verrà citato tra virgolette. Ad esempio, se il valore dei dati contiene`Time,stream`, questo valore verrà citato come nei dati esportati. `"Time,stream"` Il carattere di virgoletta usato da Timestream per sono le LiveAnalytics virgolette doppie («).
Evita di specificare il carattere di ritorno al carrello (ASCII 13`0D`, hex, text '\$1 r') o il carattere di interruzione di riga (ASCII 10, hex 0A, text'\$1n') come `FIELD_DELIMITER` se desideri includere le intestazioni nel CSV, poiché ciò impedirà a molti parser di analizzare correttamente le intestazioni nell'output CSV risultante.
ESCAPED\$1BY
```
escaped_by = '', default: (\)
```
Quando si esportano i dati in formato CSV, questo campo specifica il carattere che deve essere trattato come carattere di escape nel file di dati scritto nel bucket S3. L'escape avviene nei seguenti scenari:
1. Se il valore stesso contiene il carattere di virgoletta («), verrà eliminato utilizzando un carattere di escape. Ad esempio, se il valore è`Time"stream`, dove (\$1) è il carattere di escape configurato, allora verrà escluso come. `Time\"stream`
1. Se il valore contiene il carattere di escape configurato, verrà eliminato. Ad esempio, se il valore è`Time\stream`, allora verrà scappato come. `Time\\stream`
Se l'output esportato contiene tipi di dati complessi come Arrays, Rows o Timeseries, verrà serializzato come stringa JSON. Di seguito è riportato un esempio.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/timestream/latest/developerguide/export-unload-concepts.html)
INCLUDE\$1HEADER
```
include_header = 'true' , default: 'false'
```
Quando si esportano i dati in formato CSV, questo campo consente di includere i nomi delle colonne come prima riga dei file di dati CSV esportati.
I valori accettati sono «true» e «false» e il valore predefinito è «false». Le opzioni di trasformazione del testo come `escaped_by` e `field_delimiter` si applicano anche alle intestazioni.
Quando si includono le intestazioni, è importante non selezionare un carattere di ritorno (ASCII 13, hex 0D, testo '\$1 r') o un carattere di interruzione di riga (ASCII 10, hex 0A, text'\$1n') come carattere`FIELD_DELIMITER`, poiché ciò impedirà a molti parser di analizzare correttamente le intestazioni nell'output CSV risultante.
MAX\$1FILE\$1SIZE
```
max_file_size = 'X[MB|GB]' , default: '78GB'
```
Questo campo specifica la dimensione massima dei file che l'`UNLOAD`istruzione crea in Amazon S3. L'`UNLOAD`istruzione può creare più file, ma la dimensione massima di ogni file scritto in Amazon S3 sarà approssimativamente quella specificata in questo campo.
Il valore del campo deve essere compreso tra 16 MB e 78 GB, inclusi. È possibile specificarlo in numeri interi come `12GB` o in decimali come o. `0.5GB` `24.7MB` Il valore predefinito è 78 GB.
La dimensione effettiva del file è approssimativa al momento della scrittura del file, pertanto la dimensione massima effettiva potrebbe non essere esattamente uguale al numero specificato.
## Cosa viene scritto nel mio bucket S3?
Per ogni query UNLOAD eseguita correttamente, Timestream for LiveAnalytics scrive i risultati della query, il file di metadati e il file manifest nel bucket S3. Se hai partizionato i dati, hai tutte le cartelle delle partizioni nella cartella dei risultati. Il file manifesto contiene un elenco dei file che sono stati scritti dal comando UNLOAD. Il file di metadati contiene informazioni che descrivono le caratteristiche, le proprietà e gli attributi dei dati scritti.
## Qual è il nome del file esportato?
Il nome del file esportato contiene due componenti, il primo componente è il QueryID e il secondo è un identificatore univoco.
File CSV
```
S3://bucket_name/results/_.csv
S3://bucket_name/results/=/_.csv
```
File CSV compresso
```
S3://bucket_name/results/=/_.gz
```
File Parquet
```
S3://bucket_name/results/=/_.parquet
```
Metadati e file manifesto
```
S3://bucket_name/__manifest.json
S3://bucket_name/__metadata.json
```
Poiché i dati in formato CSV vengono archiviati a livello di file, quando si comprimono i dati durante l'esportazione in S3, il file avrà un'estensione «.gz». Tuttavia, i dati in Parquet vengono compressi a livello di colonna, quindi anche quando si comprimono i dati durante l'esportazione, il file avrà comunque l'estensione.parquet.
## Quali informazioni contiene ogni file?
### File manifest
Il file manifest fornisce informazioni sull'elenco dei file che vengono esportati con l'esecuzione UNLOAD. Il file manifest è disponibile nel bucket S3 fornito con un nome di file:. `s3:///__manifest.json` Il file manifest conterrà l'URL dei file nella cartella dei risultati, il numero di record e le dimensioni dei rispettivi file, e i metadati della query (ovvero i byte totali e le righe totali esportati in S3 per la query).
```
{
"result_files": [
{
"url":"s3://my_timestream_unloads/ec2_metrics/AEDAGANLHLBH4OLISD3CVOZZRWPX5GV2XCXRBKCVD554N6GWPWWXBP7LSG74V2Q_1448466917_szCL4YgVYzGXj2lS.gz",
"file_metadata":
{
"content_length_in_bytes": 32295,
"row_count": 10
}
},
{
"url":"s3://my_timestream_unloads/ec2_metrics/AEDAGANLHLBH4OLISD3CVOZZRWPX5GV2XCXRBKCVD554N6GWPWWXBP7LSG74V2Q_1448466917_szCL4YgVYzGXj2lS.gz",
"file_metadata":
{
"content_length_in_bytes": 62295,
"row_count": 20
}
},
],
"query_metadata":
{
"content_length_in_bytes": 94590,
"total_row_count": 30,
"result_format": "CSV",
"result_version": "Amazon Timestream version 1.0.0"
},
"author": {
"name": "Amazon Timestream",
"manifest_file_version": "1.0"
}
}
```
### Metadati
Il file di metadati fornisce informazioni aggiuntive sul set di dati come il nome della colonna, il tipo di colonna e lo schema. Il file di metadati è disponibile nel bucket S3 fornito con un nome di file: S3: //bucket\$1name/ \$1 \$1metadata.json
Di seguito è riportato un esempio di file di metadati.
```
{
"ColumnInfo": [
{
"Name": "hostname",
"Type": {
"ScalarType": "VARCHAR"
}
},
{
"Name": "region",
"Type": {
"ScalarType": "VARCHAR"
}
},
{
"Name": "measure_name",
"Type": {
"ScalarType": "VARCHAR"
}
},
{
"Name": "cpu_utilization",
"Type": {
"TimeSeriesMeasureValueColumnInfo": {
"Type": {
"ScalarType": "DOUBLE"
}
}
}
}
],
"Author": {
"Name": "Amazon Timestream",
"MetadataFileVersion": "1.0"
}
}
```
Le informazioni sulle colonne condivise nel file di metadati hanno la stessa struttura di quelle `ColumnInfo` inviate nella risposta dell'API Query per le `SELECT` query.
### Risultati
La cartella dei risultati contiene i dati esportati in formato Apache Parquet o CSV.
## Esempio
Quando invii una richiesta come quella riportata di seguito tramite l'API `UNLOAD` Query,
```
UNLOAD(SELECT user_id, ip_address, event, session_id, measure_name, time, query, quantity, product_id, channel
FROM sample_clickstream.sample_shopping WHERE time BETWEEN ago(2d) AND now())
TO 's3://my_timestream_unloads/withoutpartition/' WITH ( format='CSV', compression='GZIP')
```
`UNLOAD`la risposta alla query avrà 1 riga \$1 3 colonne. Queste 3 colonne sono:
+ righe di tipo BIGINT, che indicano il numero di righe esportate
+ MetadataFile di tipo VARCHAR, che è l'URI S3 del file di metadati esportato
+ manifestFile di tipo VARCHAR, che è l'URI S3 del file manifesto esportato
Riceverai la seguente risposta dall'API Query:
```
{
"Rows": [
{
"Data": [
{
"ScalarValue": "20" # No of rows in output across all files
},
{
"ScalarValue": "s3://my_timestream_unloads/withoutpartition/AEDAAANGH3D7FYHOBQGQQMEAISCJ45B42OWWJMOT4N6RRJICZUA7R25VYVOHJIY__metadata.json" #Metadata file
},
{
"ScalarValue": "s3://my_timestream_unloads/withoutpartition/AEDAAANGH3D7FYHOBQGQQMEAISCJ45B42OWWJMOT4N6RRJICZUA7R25VYVOHJIY__manifest.json" #Manifest file
}
]
}
],
"ColumnInfo": [
{
"Name": "rows",
"Type": {
"ScalarType": "BIGINT"
}
},
{
"Name": "metadataFile",
"Type": {
"ScalarType": "VARCHAR"
}
},
{
"Name": "manifestFile",
"Type": {
"ScalarType": "VARCHAR"
}
}
],
"QueryId": "AEDAAANGH3D7FYHOBQGQQMEAISCJ45B42OWWJMOT4N6RRJICZUA7R25VYVOHJIY",
"QueryStatus": {
"ProgressPercentage": 100.0,
"CumulativeBytesScanned": 1000,
"CumulativeBytesMetered": 10000000
}
}
```
## Tipi di dati
L'`UNLOAD`istruzione supporta tutti i tipi di dati del linguaggio di query LiveAnalytics di Timestream for descritto in [Tipi di dati supportati](supported-data-types.md) tranne `time` e. `unknown`
# Prerequisiti per UNLOAD from Timestream per LiveAnalytics
Di seguito sono riportati i prerequisiti per la scrittura di dati su S3 utilizzando from Timestream for. `UNLOAD` LiveAnalytics
+ È necessario disporre dell'autorizzazione a leggere i dati dal Timestream per le LiveAnalytics tabelle da utilizzare in un comando. `UNLOAD`
+ Devi avere un bucket Amazon S3 nella stessa AWS regione del tuo Timestream per le risorse. LiveAnalytics
+ Per il bucket S3 selezionato, assicurati che la [policy del bucket S3 disponga anche delle autorizzazioni per consentire a Timestream](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-bucket-policies.html) di esportare i dati. LiveAnalytics
+ Le credenziali utilizzate per eseguire la `UNLOAD` query devono disporre delle autorizzazioni AWS Identity and Access Management (IAM) necessarie che consentano a Timestream di scrivere i dati LiveAnalytics su S3. Un esempio di politica potrebbe essere il seguente:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"timestream:Select",
"timestream:ListMeasures",
"timestream:WriteRecords",
"timestream:Unload"
],
"Resource": "arn:aws:timestream:us-east-2:111122223333:database/database_name/table/table_name"
},
{
"Effect": "Allow",
"Action": [
"s3:GetBucketAcl",
"s3:PutObject",
"s3:GetObject",
"s3:AbortMultipartUpload"
],
"Resource": [
"arn:aws:s3:::S3_Bucket_Created",
"arn:aws:s3:::S3_Bucket_Created/*"
]
}
]
}
```
------
Per ulteriori informazioni su queste autorizzazioni di scrittura S3, consulta la guida di [Amazon Simple Storage Service](https://docs.aws.amazon.com/AmazonS3/latest/userguide/mpuoverview.html#mpuAndPermissions). Se utilizzi una chiave KMS per crittografare i dati esportati, consulta quanto segue per le politiche IAM aggiuntive richieste.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:DescribeKey",
"kms:Decrypt",
"kms:GenerateDataKey*"
],
"Resource": "arn:aws:kms:us-east-2:111122223333:key/*",
"Condition": {
"ForAnyValue:StringLike": {
"kms:ResourceAliases": "alias/Alias_For_Generated_Key"
}
}
}, {
"Effect": "Allow",
"Action": [
"kms:CreateGrant"
],
"Resource": "arn:aws:kms:us-east-2:111122223333:key/*",
"Condition": {
"ForAnyValue:StringEquals": {
"kms:EncryptionContextKeys": "aws:timestream:database_name"
},
"Bool": {
"kms:GrantIsForAWSResource": true
},
"StringLike": {
"kms:ViaService": "timestream.us-east-2.amazonaws.com"
},
"ForAnyValue:StringLike": {
"kms:ResourceAliases": "alias/Alias_For_Generated_Key"
}
}
}
]
}
```
------
# Le migliori pratiche per UNLOAD from Timestream per LiveAnalytics
Di seguito sono riportate le procedure consigliate relative al comando UNLOAD.
+ La quantità di dati che può essere esportata nel bucket S3 utilizzando il `UNLOAD` comando non è limitata. Tuttavia, la query scade dopo 60 minuti e consigliamo di esportare non più di 60 GB di dati in una singola query. Se devi esportare più di 60 GB di dati, suddividi il lavoro su più query.
+ Sebbene sia possibile inviare migliaia di richieste a S3 per caricare i dati, si consiglia di parallelizzare le operazioni di scrittura su più prefissi S3. [Fai](https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance.html) riferimento alla documentazione qui. La velocità di chiamata all'API S3 potrebbe essere limitata quando più readers/writers utenti accedono alla stessa cartella.
+ Dato il limite alla lunghezza della chiave S3 per la definizione di un prefisso, consigliamo di avere nomi di bucket e cartelle entro 10-15 caratteri, specialmente quando si utilizza la clausola. `partitioned_by`
+ Quando ricevi un 4XX o 5XX per le query contenenti l'`UNLOAD`istruzione, è possibile che i risultati parziali vengano scritti nel bucket S3. Timestream for LiveAnalytics non elimina alcun dato dal bucket. Prima di eseguire un'altra `UNLOAD` query con la stessa destinazione S3, consigliamo di eliminare manualmente i file creati dalla query fallita. È possibile identificare i file scritti da una query fallita con i file corrispondenti`QueryExecutionId`. Per le query non riuscite, Timestream for LiveAnalytics non esporta un file manifest nel bucket S3.
+ Timestream for LiveAnalytics utilizza il caricamento in più parti per esportare i risultati delle query su S3. Quando ricevi un 4XX o 5XX da Timestream per le query contenenti un'istruzione UNLOAD, Timestream LiveAnalytics for evita al massimo il caricamento in più parti, LiveAnalytics ma è possibile che alcune parti incomplete rimangano incomplete. [Pertanto, ti consigliamo di impostare una pulizia automatica dei caricamenti incompleti in più parti nel tuo bucket S3 seguendo le linee guida riportate qui.](https://aws.amazon.com/blogs/aws-cloud-financial-management/discovering-and-deleting-incomplete-multipart-uploads-to-lower-amazon-s3-costs/)
## Consigli per accedere ai dati in formato CSV utilizzando il parser CSV
+ I parser CSV non consentono di avere lo stesso carattere nei caratteri delimiter, escape e quote.
+ Alcuni parser CSV non sono in grado di interpretare tipi di dati complessi come gli array, consigliamo di interpretarli tramite il deserializzatore JSON.
## Raccomandazioni per l'accesso ai dati in formato Parquet
1. Se il tuo caso d'uso richiede il supporto dei caratteri UTF-8 nello schema, noto anche come nome della colonna, ti consigliamo di utilizzare la libreria [Parquet-MR](https://github.com/apache/parquet-mr).
1. Il timestamp nei risultati è rappresentato da un numero intero a 12 byte () INT96
1. Le serie temporali verranno rappresentate come`array>`, le altre strutture annidate utilizzeranno i tipi di dati corrispondenti supportati nel formato Parquet
## Utilizzo della clausola partition\$1by