如需與 Amazon Timestream for LiveAnalytics 類似的功能，請考慮使用 Amazon Timestream for InfluxDB。它提供簡化的資料擷取和單一位數毫秒查詢回應時間，以進行即時分析。[在這裡](https://docs.aws.amazon.com//timestream/latest/developerguide/timestream-for-influxdb.html)進一步了解。 本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 處理延遲抵達的資料 在某些情況下，資料可能會大量延遲送達，例如，與擷取的資料列相關聯的時間戳記相比，資料擷取到 Timestream for LiveAnalytics 的時間會大幅延遲。在上述範例中，您已看到如何使用 @scheduled\_runtime 參數定義的時間範圍來考慮一些延遲抵達的資料。不過，如果您的使用案例資料可能會延遲數小時或數天，您可能需要不同的模式，以確保衍生資料表中的預先運算已適當更新，以反映此類延遲抵達的資料。如需延遲抵達資料的一般資訊，請參閱 [寫入資料 （插入 和 upsert)](writes.md#writes.writing-data-inserts-upserts)。 在以下，您將看到兩種不同的方法來解決此延遲到達資料。 + 如果您的資料到達有可預測的延遲，您可以使用另一個「追趕」排程運算來更新延遲到達資料的彙總。 + 如果您有無法預測的延遲或偶爾的延遲抵達資料，您可以使用手動執行來更新衍生的資料表。 此討論涵蓋延遲資料抵達的情況。不過，相同的原則適用於資料更正，其中您已修改來源資料表中的資料，並想要更新衍生資料表中的彙總。 **Topics** + [排程的追蹤查詢](#scheduledqueries-patterns-latearrive-schedcatchup) + [無法預測的延遲到達資料的手動執行](#scheduledqueries-patterns-latearrive-manual) ## 排程的追蹤查詢 ### 查詢彙總及時抵達的資料 以下模式將說明如何在資料到達時發生可預測的延遲時，使用自動化方法來更新彙總。請考慮下列其中一個先前已排程的即時資料運算範例。此排程運算每 30 分鐘重新整理衍生的資料表一次，並已考量資料延遲長達一小時。 ``` { "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": "******" } ``` ### 更新延遲到達資料彙總的趕上查詢 現在，如果您考慮資料延遲約 12 小時的情況。以下是相同查詢的變體。不過，差別在於，與觸發排程運算時相比，它會計算延遲長達 12 小時的資料彙總。例如，您會在以下範例中看到查詢，此查詢的目標時間範圍是在觸發查詢之前 2 小時到 14 小時之間。此外，如果您注意到排程表達式 cron(0 0，12 \* ？ \*)，它會在每天 00：00 UTC 和 12：00 UTC 時觸發運算。因此，在 2021-12-01 00：00：00 觸發查詢時，查詢更新彙總的時間範圍為 2021-11-30 10：00：00 到 2021-11-30 22：00：00。排程查詢使用類似於 Timestream for LiveAnalytics 寫入的 upsert 語意，如果視窗中有延遲到達的資料或發現較新的彙總 （例如，觸發原始排程運算時不存在的新群組），則新的彙總將插入衍生的資料表中，則新的彙總值會以較新的值更新。同樣地，當下一個執行個體在 2021-12-01 12：00：00 觸發時，該執行個體會將範圍 2021-11-30 22：00：00 的彙總更新為 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": "******" } ``` 上述範例是一個圖，假設您的延遲到達限制為 12 小時，並且可以每 12 小時更新一次衍生的資料表，以用於晚於即時時段的資料。您可以調整此模式，每小時更新一次衍生的資料表，以便衍生的資料表更快反映延遲到達的資料。同樣地，您可以將時間範圍調整為超過 12 小時，例如一天或甚至一週或更長時間，以處理可預測的延遲抵達資料。 ## 無法預測的延遲到達資料的手動執行 在某些情況下，您可能有無法預測的延遲到達資料，或者您對來源資料進行了變更，並在事實之後更新了一些值。在所有這類情況下，您可以手動觸發排程查詢以更新衍生的資料表。以下是如何達成此目標的範例。 假設您有使用案例，其中將運算寫入衍生的資料表 dp\_per\_timeseries\_per\_hr。資料表開發工具中的基本資料已更新至時間範圍 2021-11-30 23：00：00 - 2021-12-01 00：00：00。有兩種不同的排程查詢可用於更新此衍生資料表：MultiPT30mPerHrPerTimeseriesDPCount 和 MultiPT12HPerHrPerTimeseriesDPCountCatchUp。您在 Timestream for LiveAnalytics 中建立的每個排程運算都有一個唯一的 ARN，您可以在建立運算或執行清單操作時取得該 ARN。您可以使用 ARN 進行運算，以及查詢為執行此操作而取得的參數 @scheduled\_runtime 值。 假設 MultiPT30mPerHrPerTimeseriesDPCount 的運算具有 ARN arn\_1，而且您想要使用此運算來更新衍生的資料表。由於上述排定的運算會在 @scheduled\_runtime 值之前 1 小時和之後 1 小時更新彙總，因此您可以使用 @scheduled\_runtime 參數的值 2021-12-01 00：00：00 涵蓋更新 (2021-11-30 的時間範圍 23：00：00 - 2021-12-01 00：00：00。您可以使用 ExecuteScheduledQuery API，以 epoch 秒 (UTC) 為單位傳遞此運算的 ARN 和時間參數值來達成此目標。以下是使用 AWS CLI 的範例，您可以使用 Timestream for LiveAnalytics 支援的任何SDKs遵循相同的模式。 ``` aws timestream-query execute-scheduled-query --scheduled-query-arn arn_1 --invocation-time 1638316800 --profile profile --region us-east-1 ``` 在上述範例中，設定檔是具有適當權限的 AWS 設定檔，可進行此 API 呼叫，而 1638316800 對應至 2021-12-01 00：00：00 的 epoch 秒。此手動觸發程序的行為與假設系統在所需時段觸發此呼叫的自動觸發程序差不多。 如果您在較長的時間內進行更新，假設基礎資料已在 2021-11-30 23：00：00 - 2021-12-01 11：00：00 進行更新，則您可以多次觸發上述查詢，以涵蓋整個時間範圍。例如，您可以執行六個不同的執行，如下所示。 ``` 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 ``` 前六個命令對應於在 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：00 和 2021-12-01 10：00 叫用的排程運算： 或者，您可以使用在 2021-12-01 13：00：00 觸發的計算 MultiPT12HPerHrPerTimeseriesDPCountCatchUp 進行一次執行，以更新整個 12 小時時間範圍的彙總。例如，如果 arn\_2 是該運算的 ARN，您可以從 CLI 執行下列命令。 ``` aws timestream-query execute-scheduled-query --scheduled-query-arn arn_2 --invocation-time 1638363600 --profile profile --region us-east-1 ``` 值得注意的是，對於手動觸發，您可以將時間戳記用於不需要與該自動觸發時間戳記對齊的調用時間參數。例如，在先前的範例中，即使自動化排程只在時間戳記 2021-12-01 10：00：00、2021-12-01 12021-12-012：00：00 和 00：00：00 觸發，您也在 2021-12-02 13：00：00 時觸發運算。Timestream for LiveAnalytics 可讓您靈活地使用手動操作所需的適當值來觸發它。 以下是使用 ExecuteScheduledQuery API 時的一些重要考量。 + 如果您要觸發多個這些調用，您需要確保這些調用不會產生重疊時間範圍的結果。例如，在先前的範例中，有六個叫用。每個調用涵蓋 2 小時的時間範圍，因此調用時間戳記會分散兩個小時，以避免更新中的任何重疊。這可確保衍生資料表中的資料最終處於與來源資料表相符的彙總狀態。如果您無法確保非重疊的時間範圍，請確定這些執行依序觸發。如果您同時觸發多個執行，而這些執行在其時間範圍內重疊，則可以看到觸發失敗，您可能會在這些執行的錯誤報告中看到版本衝突。排程查詢調用產生的結果會根據調用觸發的時間指派版本。因此，較新調用產生的資料列具有較高的版本。較高的版本記錄可以覆寫較低的版本記錄。對於自動觸發的排程查詢，Timestream for LiveAnalytics 會自動管理排程，因此即使後續調用具有重疊的時間範圍，您也不會看到這些問題。 + 如前所述，您可以為 @scheduled\_runtime 觸發具有任何時間戳記值的調用。因此，您有責任適當地設定值，以便在衍生資料表中更新適當的時間範圍，對應至來源資料表中更新資料的範圍。 + 對於處於 DISABLED 狀態的排程查詢，您也可以使用這些手動觸發。這可讓您定義未在自動排程中執行的特殊查詢，因為它們處於 DISABLED 狀態。反之，您可以使用手動觸發來管理資料更正或延遲到達使用案例。