如需與 Amazon Timestream for LiveAnalytics 類似的功能，請考慮使用 Amazon Timestream for InfluxDB。它提供簡化的資料擷取和單一位數毫秒查詢回應時間，以進行即時分析。[在這裡](https://docs.aws.amazon.com//timestream/latest/developerguide/timestream-for-influxdb.html)進一步了解。

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 排程查詢概念
<a name="scheduledqueries-concepts"></a>

**查詢字串** - 這是您在另一個 Timestream for LiveAnalytics 資料表中預先計算和儲存結果的查詢。您可以使用 Timestream for LiveAnalytics 的完整 SQL 表面積來定義排程查詢，這可讓您靈活地使用常見的資料表表達式、巢狀查詢、視窗函數，或任何 [Timestream for LiveAnalytics 查詢語言支援的彙總和純量函數來撰寫查詢](https://docs.aws.amazon.com/timestream/latest/developerguide/reference.html)。

**排程表達**式 - 可讓您指定排程查詢執行個體的執行時間。您可以使用 Cron 表達式 （例如每天上午 8 點 UTC 執行） 或 Rate 表達式 （例如每 10 分鐘執行一次） 來指定表達式。

**目標組態** - 可讓您指定如何將排程查詢的結果映射到儲存此排程查詢結果的目的地資料表。

**通知組態** - LiveAnalytics 的 Timestream 會根據您的排程表達式自動執行排程查詢的執行個體。您在建立排程查詢時所設定的 SNS 主題上執行的每個此類查詢都會收到通知。此通知會指定執行個體是否已成功執行或遇到任何錯誤。此外，它還提供諸如計量位元組、寫入目標資料表的資料、下次調用時間等資訊。

以下是這類通知訊息的範例。

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

在此通知訊息中， `bytesMetered`是查詢在來源資料表上掃描的位元組，而 dataWrites 是寫入目標資料表的位元組。

**注意**  
 如果您以程式設計方式使用這些通知，請注意，未來可能會將新欄位新增至通知訊息。

**錯誤報告位置** - 以非同步方式執行排程查詢，並將資料儲存在目標資料表中。如果執行個體發生任何錯誤 （例如，無法儲存的無效資料），則會將發生錯誤的記錄寫入您在建立排程查詢時指定的錯誤報告位置中的錯誤報告。您可以指定位置的 S3 儲存貯體和字首。LiveAnalytics 的 Timestream 會將排程查詢名稱和調用時間附加至此字首，以協助您識別與排程查詢的特定執行個體相關聯的錯誤。

**標記** - 您可以選擇性地指定可與排程查詢建立關聯的標籤。如需詳細資訊，請參閱[標記 LiveAnalytics 資源的 Timestream](https://docs.aws.amazon.com/timestream/latest/developerguide/tagging-keyspaces.html)。

**範例**

在下列範例中，您會使用排程查詢來計算簡單的彙總：

```
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` - 在此範例中，您會注意到查詢接受特殊的具名參數 `@scheduled_runtime`。這是特殊參數 （時間戳記類型），服務會在叫用排程查詢的特定執行個體時設定，讓您可以決定性地控制排程查詢的特定執行個體分析來源資料表中資料的時間範圍。您可以在預期時間戳記類型的任何位置的查詢`@scheduled_runtime`中使用 。

請考慮您設定排程表達式的範例：cron(0/5 \* \* ？ \*)，其中排程查詢會在每小時的分鐘 0、5、10、15、20、25、30、35、40、45、50、55 執行。對於在 2021-12-01 00：05：00 觸發的執行個體，@scheduled\_runtime 參數會初始化為此值，因此目前執行個體會操作範圍為 2021-11-30 23：55：00 到 2021-12-01 00：06：00 的資料。

**具有重疊時間範圍的執行個體** - 如本範例所示，排程查詢的兩個後續執行個體可能會在其時間範圍中重疊。這是您可以根據您的需求、您指定的時間述詞和排程表達式來控制的內容。在這種情況下，此重疊允許這些運算根據其到達稍微延遲的任何資料更新彙總，在此範例中最多 10 分鐘。 2021-12-01 00：00：00 觸發的查詢執行將涵蓋時間範圍 2021-11-30 23：50：00 至 2021-12-30 00：01：00，而 2021-12-01 00：05：00 觸發的查詢執行將涵蓋範圍 2021-11-30 23：55：00 至 2021-12-01 00：06：00。

為了確保正確性，並確保儲存在目標資料表中的彙總符合從來源資料表計算的彙總，Timestream for LiveAnalytics 可確保 2021-12-01 00：05：00 的運算只會在 2021-12-01 00：00：00 的運算完成後執行。如果產生較新的值，後者運算的結果可以更新任何先前具體化的彙總。在內部，Timestream for LiveAnalytics 會使用記錄版本，其中排程查詢後者執行個體產生的記錄將獲指派較高的版本編號。因此，在 2021-12-01 00：05：00 由調用計算的彙總可以更新在 2021-12-01 00：00：00 由調用計算的彙總，假設來源資料表上有較新的資料可用。

**自動觸發與手動觸發 **- 建立排程查詢後，LiveAnalytics 的 Timestream 會根據指定的排程自動執行執行個體。這類自動觸發程序完全由 服務管理。

不過，在某些情況下，您可能想要手動啟動排程查詢的某些執行個體。範例包括查詢執行中特定執行個體失敗、自動排程執行後來源資料表中有延遲抵達的資料或更新，或您想要針對自動查詢執行未涵蓋的時間範圍 （例如，建立排程查詢之前的時間範圍） 更新目標資料表。

您可以使用 ExecuteScheduledQuery API，透過傳遞 InvocationTime 參數手動啟動排程查詢的特定執行個體，這是用於 @scheduled\_runtime 參數的值。以下是使用 ExecuteScheduledQuery API 時的一些重要考量：
+ 如果您要觸發多個這些調用，您需要確保這些調用不會產生重疊時間範圍的結果。如果您無法確保非重疊的時間範圍，請確定這些查詢執行依序啟動。如果您同時啟動在其時間範圍內重疊的多個查詢執行，則可以看到觸發失敗，您可能會在這些查詢執行的錯誤報告中看到版本衝突。
+ 您可以使用 @scheduled\_runtime 的任何時間戳記值來啟動調用。因此，您有責任適當地設定值，以便在目標資料表中更新適當的時間範圍，對應到來源資料表中更新資料的範圍。
+ ExecuteScheduledQuery API 會以非同步方式運作。成功呼叫後，服務會傳送 200 個回應並繼續執行查詢。不過，如果有多個排程查詢執行同時執行，則 會預期執行手動觸發的排程執行時可能發生延遲。