如需與 Amazon Timestream for LiveAnalytics 類似的功能，請考慮使用 Amazon Timestream for InfluxDB。它提供簡化的資料擷取和單一位數毫秒查詢回應時間，以進行即時分析。[在這裡](https://docs.aws.amazon.com//timestream/latest/developerguide/timestream-for-influxdb.html)進一步了解。
本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 簡單機群層級彙總
第一個範例會逐步解說使用簡單範例運算機群層級彙總處理排程查詢時的一些基本概念。使用此範例，您將學到以下內容。
+ 如何取得用於取得彙總統計資料的儀表板查詢，並將其對應至排程查詢。
+ Timestream for LiveAnalytics 如何管理排程查詢不同執行個體的執行。
+ 如何讓排程查詢的不同執行個體在時間範圍中重疊，以及如何在目標資料表上維護資料的正確性，以確保您使用排程查詢結果的儀表板為您提供的結果與原始資料上計算的相同彙總相符。
+ 如何設定排程查詢的時間範圍和重新整理節奏。
+ 如何自助追蹤排程查詢的結果以進行調校，讓查詢執行個體的執行延遲落在重新整理儀表板的可接受延遲內。
**Topics**
+ [從來源資料表彙總](#scheduledqueries-patterns-simplefleet-aggrfromsourcetable)
+ [預先運算彙總的排程查詢](#scheduledqueries-patterns-simplefleet-schedtoprecomputeaggr)
+ [從衍生資料表彙總](#scheduledqueries-patterns-simplefleet-aggrfromderived)
+ [合併來源和衍生資料表的彙總](#scheduledqueries-patterns-simplefleet-aggrcombsourceandderived)
+ [從經常重新整理的排程運算彙總](#scheduledqueries-patterns-simplefleet-aggregatefromrequently)
## 從來源資料表彙總
在此範例中，您要每分鐘追蹤指定區域內伺服器發出的指標數量。下圖是繪製 us-east-1 區域此時間序列的範例。
![\[Time series graph showing fluctuating number of metrics emitted by servers in us-east-1 region.\]](http://docs.aws.amazon.com/zh_tw/timestream/latest/developerguide/images/schedquery_aggrfromsourcetable.png)
以下是從原始資料運算此彙總的範例查詢。它會篩選 us-east-1 區域的列，然後考慮 20 個指標 （如果 measure\$1name 是指標） 或 5 個事件 （如果 measure\$1name 是事件） 來計算每分鐘總和。在此範例中，圖表圖顯示發出的指標數量介於每分鐘 150 萬到 600 萬之間。繪製此時間序列數小時 （此圖中過去 12 小時） 時，此原始資料的查詢會分析數億個資料列。
```
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
```
## 預先運算彙總的排程查詢
如果您想要最佳化儀表板以更快地載入，並透過掃描較少的資料來降低成本，您可以使用排程查詢來預先計算這些彙總。Timestream for LiveAnalytics 中的排程查詢可讓您在另一個 Timestream for LiveAnalytics 資料表中具體化這些預先運算，之後可用於儀表板。
建立排程查詢的第一個步驟是識別您要預先運算的查詢。請注意，上述儀表板已繪製為 us-east-1 區域。不過，不同的使用者可能想要不同區域的相同彙總，例如 us-west-2 或 eu-west-1。若要避免為每個此類查詢建立排程查詢，您可以預先計算每個區域的彙總，並將另一個 Timestream for LiveAnalytics 資料表中的每個區域彙總具體化。
以下查詢提供對應的預先運算範例。如您所見，它類似於原始資料查詢中使用的常見資料表表達式 grouped\$1data，除了兩個差異：1) 不使用區域述詞，因此我們可以針對所有區域使用一個查詢來預先計算；以及 2) 使用參數化時間述詞搭配特殊參數 @scheduled\$1runtime，詳細說明如下。
```
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
```
上述查詢可以使用下列規格轉換為排程查詢。排程查詢會獲指派名稱，這是易於使用的語彙。然後，它包含 QueryString，ScheduleConfiguration，這是 [cron 表達](https://docs.aws.amazon.com/timestream/latest/developerguide/scheduledqueries-schedule.html)式。它指定 TargetConfiguration，將查詢結果映射至 Timestream for LiveAnalytics 中的目的地資料表。最後，它會指定許多其他組態，例如 NotificationConfiguration，其中會傳送個別查詢執行的通知、ErrorReportConfiguration，其中會在查詢發生任何錯誤時撰寫報告，以及 ScheduledQueryExecutionRoleArn，這是用來執行排程查詢操作的角色。
```
{
"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": "******"
}
```
在此範例中，ScheduleExpression cron(0/5 \$1 \$1 ？ \$1) 表示查詢會在每天每小時的 5、10、15、.. 分鐘執行一次。觸發此查詢的特定執行個體時，這些時間戳記會轉譯為查詢中使用的 @scheduled\$1runtime 參數。例如，請考慮在 2021-12-01 00：00：00 執行此排程查詢的執行個體。在此執行個體中，@scheduled\$1runtime 參數會在叫用查詢時初始化為時間戳記 2021-12-01 00：00：00。因此，此特定執行個體將在時間戳記 2021-12-01 00：00：00 執行，並計算從時間範圍 2021-11-30 23：50：00 到 2021-12-01 00：01：00 的每分鐘彙總。同樣地，此查詢的下一個執行個體會在時間戳記 2021-12-01 00：05：00 觸發，在這種情況下，查詢會運算從時間範圍 2021-11-30 23：55：00 到 2021-12-01 00：06：00 的每分鐘彙總。因此，@scheduled\$1runtime 參數提供排程查詢，以使用查詢的調用時間預先計算所設定時間範圍的彙總。
請注意，查詢的兩個後續執行個體在其時間範圍中重疊。這是您可以根據需求控制的項目。在這種情況下，此重疊允許這些查詢根據其到達稍微延遲的任何資料更新彙總，在此範例中最多 5 分鐘。為了確保具體化查詢的正確性，Timestream for LiveAnalytics 可確保 2021-12-01 00：05：00 的查詢只會在 2021-12-01 00：00：00 的查詢完成後執行，而後者查詢的結果可以在產生較新的值時使用 更新任何先前具體化的彙總。例如，如果時間戳記 2021-11-30 23：59：00 的某些資料在執行 2021-12-01 00：00：00 的查詢之後，但在 2021-12-01 00：05：00 的查詢之前到達，則 2021-12-01 00：05：00 的執行將重新計算 2021-11-30 23：59：00 分鐘的彙總，這將導致先前的彙總更新為新計算的值。您可以依賴排程查詢的這些語意，在更新預先運算的速度與如何正常處理一些延遲到達的資料之間取得取捨。以下討論其他考量事項：如何權衡此重新整理節奏與資料的新鮮度，以及如何解決更新延遲程度更高的資料彙總，或如果您的排程運算來源有更新值，將需要重新計算彙總。
每個排程運算都有通知組態，其中 Timestream for LiveAnalytics 會傳送排程組態每次執行的通知。您可以設定 的 SNS 主題，以接收每次調用的通知。除了特定執行個體的成功或失敗狀態之外，它還有數個統計資料，例如執行此運算所花費的時間、掃描的運算位元組數，以及運算寫入其目的地資料表的位元組數。您可以使用這些統計資料來進一步調整查詢、排程組態，或追蹤排程查詢的支出。值得注意的一個方面是執行個體的執行時間。在此範例中，排程運算設定為每 5 分鐘執行一次 。執行時間將決定可使用預先運算的延遲，當您在儀表板中使用預先運算的資料時，也會在儀表板中定義延遲。此外，如果此延遲持續高於重新整理間隔，例如，如果設定為每 5 分鐘重新整理一次的運算的執行時間超過 5 分鐘，請務必調整運算速度，以避免儀表板進一步延遲。
## 從衍生資料表彙總
現在您已設定排程查詢，且彙總已預先計算並具體化為排程運算目標組態中指定的另一個 Timestream for LiveAnalytics 資料表，您可以使用該資料表中的資料來撰寫 SQL 查詢，以強化儀表板。以下是使用具體化預先彙總來產生 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/zh_tw/timestream/latest/developerguide/images/schedquery_aggrfromderived.png)
上圖繪製從彙總資料表計算的彙總。將此面板與從原始來源資料計算的面板進行比較，您會注意到它們完全相符，雖然這些彙總會延遲幾分鐘，但取決於您為排程運算設定的重新整理間隔，以及執行它的時間。
相較於透過原始來源資料計算的彙總，此對預先計算資料的查詢會掃描數個數量級較少的資料。視彙總的精細程度而定，這種減少可以輕鬆產生 100X的成本和查詢延遲。執行此排程運算需要付費。不過，根據這些儀表板的重新整理頻率以及並行使用者載入這些儀表板的頻率，您最終會使用這些預先運算大幅降低整體成本。儀表板載入時間快上 10-100X。
## 合併來源和衍生資料表的彙總
使用衍生資料表建立的儀表板可能會有延遲。如果您的應用程式案例需要儀表板擁有最新的資料，則可以使用 Timestream for LiveAnalytics SQL 支援的功能和彈性，將來源資料表的最新資料與衍生資料表的歷史彙總結合，以形成合併檢視。此合併檢視使用來自來源和衍生資料表的 SQL 和非重疊時間範圍的聯集語意。在下面的範例中，我們使用 "derived"."per\$1minute\$1aggs\$1pt5m" 衍生的資料表。由於衍生資料表的排程運算每 5 分鐘重新整理一次 （根據排程表達式規格）， 以下查詢使用來源資料表中最近 15 分鐘的資料， 和來自衍生資料表超過 15 分鐘的任何資料，然後將結果聯集起來，以建立具有兩個世界最佳效能的合併檢視： 從衍生的資料表讀取較舊的預先計算彙總，以及從來源資料表讀取彙總的新鮮度，為您的即時分析使用案例提供動力，藉此獲得經濟效益和低延遲。
請注意，與僅查詢衍生的資料表相比，此聯集方法的查詢延遲略高，並且掃描的資料也略高，因為它正在即時彙總原始資料以填入最新的時間間隔。不過，相較於從來源資料表即時彙總，此合併檢視仍然會明顯更快且更便宜，特別是對於轉譯數天或數週資料的儀表板。您可以調整此範例的時間範圍，以符合應用程式的重新整理需求和延遲容錯能力。
```
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
```
以下是具有此統一合併檢視的儀表板面板。如您所見，儀表板看起來幾乎與從衍生資料表運算的檢視相同，但最右邊的頂端會有up-to-date彙總。
![\[Time-series graph showing fluctuating data points over 11 hours, with peaks around 6 million.\]](http://docs.aws.amazon.com/zh_tw/timestream/latest/developerguide/images/schedquery_aggrcombsourceandderived.png)
## 從經常重新整理的排程運算彙總
根據載入儀表板的頻率，以及您希望儀表板的延遲程度，儀表板中還有另一種取得更新鮮結果的方法：讓排程運算重新整理彙總的頻率更高。例如，以下是相同排程運算的組態，除了每分鐘重新整理一次 （請注意排程 express cron(0/1 \$1 \$1 \$1 ？ \$1))。透過此設定，衍生的資料表 per\$1minute\$1aggs\$1pt1m 會有比運算每 5 分鐘指定重新整理排程一次的案例更近期的彙總。
```
{
"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
```
由於衍生的資料表具有較新的彙總，因此您現在可以直接查詢衍生的資料表 per\$1minute\$1aggs\$1pt1m，以取得較新的彙總，如先前查詢和下方的儀表板快照所示。
![\[Graph showing fluctuating data points over time, with peaks reaching 6 million and valleys near 1 million.\]](http://docs.aws.amazon.com/zh_tw/timestream/latest/developerguide/images/schedquery_aggregatefromrequently.png)
請注意，以更快的排程重新整理排程運算 （例如 1 分鐘相較於 5 分鐘） 將增加排程運算的維護成本。每個運算執行的通知訊息都會提供掃描多少資料，以及寫入衍生資料表多少資料的統計資料。同樣地，如果您使用合併檢視來聯集衍生的資料表，您會查詢合併檢視的成本，而且相較於僅查詢衍生的資料表，儀表板載入延遲會更高。因此，您選擇的方法取決於儀表板重新整理的頻率，以及排程查詢的維護成本。如果您有數十個使用者每分鐘重新整理一次儀表板，則更頻繁地重新整理衍生資料表可能會導致整體成本降低。