查詢優先順序 - Amazon Redshift

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

查詢優先順序

並非所有查詢都具有相同的重要性,通常某個工作負載或某一組使用者的效能會比較重要。如果您已啟用自動 WLM,則可透過設定優先順序值來定義查詢在工作負載中的相對重要性。為佇列指定優先順序,與佇列關聯的所有查詢就會繼承其優先順序。將使用者群組和查詢群組對應到佇列,即可將查詢關聯至佇列。您可以設定以下優先順序 (從最高優先順序到最低優先順序列出):

  1. HIGHEST

  2. HIGH

  3. NORMAL

  4. LOW

  5. LOWEST

當優先順序不同的查詢爭用相同資源時,管理員使用這些優先順序來顯示其工作負載的相對重要性。當查詢放入系統時,Amazon Redshift 會採用優先順序,以及決定分配給查詢的資源量。依預設,查詢的優先順序設定為 NORMAL

超級使用者可使用一個額外的優先順序 CRITICAL,這是比 HIGHEST 更高的優先順序。若要設定此優先順序,您可使用函數 CHANGE_QUERY_PRIORITYCHANGE_SESSION_PRIORITYCHANGE_USER_PRIORITY。若要將使用這些函數的許可授予給資料庫使用者,您可以建立預存程序並授予許可給使用者。如需範例,請參閱 CHANGE_SESSION_PRIORITY

注意

一次只能執行一個 CRITICAL 查詢。

我們使用一個範例,其中擷取、轉換、載入 (ETL) 工作負載的優先順序高於分析工作負載的優先順序。ETL 工作負載每六個小時執行一次,而分析工作負載全天執行。當只有分析工作負載在叢集上執行時,它可取得整個系統,產生高輸送量和最佳的系統使用率。不過,當 ETL 工作負載啟動時,它會取得正確的權限,因為它具有更高的優先順序。做為 ETL 工作負載執行的查詢可優先獲得許可,在被核准之後也能獲得優先資源分配。因此,無論系統上有哪些其他項目正在執行,ETL 工作負載都能如預期地執行。因此,它能提供可預測的效能,以及讓管理員為其商業使用者提供服務水準協議 (SLA)。

在指定叢集中,高優先順序工作負載能獲得可預測的效能,代價是其他較低優先順序的工作負載。較低優先順序的工作負載可能會執行得更久,因為它們的查詢要等候較重要的查詢先完成。或者,當它們與較高優先順序的查詢同時執行時,所獲得的資源較少,所以要執行得更久。較低優先順序的查詢不會面臨資源耗盡,只是以較慢的速度取得進展。

在前面的範例中,管理員可以為分析工作負載啟用並行擴展。這麼做可以在即使 ETL 工作負載以高優先順序執行時,也能讓分析工作負載保持輸送量。

設定佇列優先順序

如果您已啟用自動 WLM,則每個佇列都具有優先順序值。查詢會根據使用者群組和查詢群組而路由到佇列。從隊列優先級設置為NORMAL。請根據與佇列之使用者群組和查詢群組關聯的工作負載,設定更高或更低的優先順序。

您可以在 Amazon Redshift 主控台上變更佇列的優先順序。在 Amazon Redshift 控制台上,工作負載管理頁面會顯示佇列,並啟用佇列屬性的編輯,例如優先順序。若要使用 CLI 或 API 操作來設定優先順序,請使用 wlm_json_configuration 參數。如需詳細資訊,請參閱「」設定工作負載管理中的Amazon Redshift 叢集管理指南

下列 wlm_json_configuration 範例定義三個使用者群組 (ingestreportinganalytics)。來自這些群組的使用者所提交的查詢分別以 highestnormallow 的優先順序執行。

[ { "user_group": [ "ingest" ], "priority": "highest", "queue_type": "auto" }, { "user_group": [ "reporting" ], "priority": "normal", "queue_type": "auto" }, { "user_group": [ "analytics" ], "priority": "low", "queue_type": "auto", "auto_wlm": true } ]

使用查詢監控規則變更查詢優先順序

查詢監視規則 (QMR) 可讓您根據查詢執行時的行為,來變更查詢的優先順序。您可以在 QMR 述詞中指定優先順序屬性以及動作,來執行此作業。如需詳細資訊,請參閱 WLM 查詢監控規則

例如,您可以定義規則來取消任何歸類為high優先級,運行時間超過 10 分鐘。

"rules" :[ { "rule_name":"rule_abort", "predicate":[ { "metric_name":"query_cpu_time", "operator":">", "value":600 }, { "metric_name":"query_priority", "operator":"=", "value":"high" } ], "action":"abort" } ]

另一個範例是定義規則以將目前優先順序為 normal 且溢出超過 1 TB 到磁碟之任何查詢的優先順序變更為 lowest

"rules":[ { "rule_name":"rule_change_priority", "predicate":[ { "metric_name":"query_temp_blocks_to_disk", "operator":">", "value":1000000 }, { "metric_name":"query_priority", "operator":"=", "value":"normal" } ], "action":"change_query_priority", "value":"lowest" } ]

監控查詢優先順序

若要顯示等待中和執行中查詢的優先順序,請檢視 stv_wlm_query_state 系統資料表中的 query_priority 欄。

query | service_cl | wlm_start_time | state | queue_time | query_priority ---------+------------+----------------------------+------------------+------------+---------------- 2673299 | 102 | 2019-06-24 17:35:38.866356 | QueuedWaiting | 265116 | Highest 2673236 | 101 | 2019-06-24 17:35:33.313854 | Running | 0 | Highest 2673265 | 102 | 2019-06-24 17:35:33.523332 | Running | 0 | High 2673284 | 102 | 2019-06-24 17:35:38.477366 | Running | 0 | Highest 2673288 | 102 | 2019-06-24 17:35:38.621819 | Running | 0 | Highest 2673310 | 103 | 2019-06-24 17:35:39.068513 | QueuedWaiting | 62970 | High 2673303 | 102 | 2019-06-24 17:35:38.968921 | QueuedWaiting | 162560 | Normal 2673306 | 104 | 2019-06-24 17:35:39.002733 | QueuedWaiting | 128691 | Lowest

若要列出已完成查詢的優先順序,請檢視 stl_wlm_query 系統資料表中的 query_priority 欄。

select query, service_class as svclass, service_class_start_time as starttime, query_priority from stl_wlm_query order by 3 desc limit 10;
query | svclass | starttime | query_priority ---------+---------+----------------------------+---------------------- 2723254 | 100 | 2019-06-24 18:14:50.780094 | Normal 2723251 | 102 | 2019-06-24 18:14:50.749961 | Highest 2723246 | 102 | 2019-06-24 18:14:50.725275 | Highest 2723244 | 103 | 2019-06-24 18:14:50.719241 | High 2723243 | 101 | 2019-06-24 18:14:50.699325 | Low 2723242 | 102 | 2019-06-24 18:14:50.692573 | Highest 2723239 | 101 | 2019-06-24 18:14:50.668535 | Low 2723237 | 102 | 2019-06-24 18:14:50.661918 | Highest 2723236 | 102 | 2019-06-24 18:14:50.643636 | Highest

為了優化工作負載的吞吐量,Amazon Redshift 可能會修改用户提交的查詢的優先級。Amazon Redshift 使用高級機器學習算法來確定此優化何時有益於您的工作負載,並在滿足以下所有條件時自動應用該算法。

  • 自動 WLM 已啟用。

  • 只定義了一個 WLM 隊列。

  • 您尚未定義設置查詢優先級的查詢監視規則 (QMR)。此類規則包括 QMR 指標query_priority或 QMR 操作change_query_priority。如需詳細資訊,請參閱 WLM 查詢監控規則