查詢優先順序 - Amazon Redshift
設定佇列優先順序使用 變更查詢優先順序 QMR監控查詢優先順序

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

查詢優先順序

使用 Amazon Redshift，您可以使用工作負載管理 （WM） 管理並行查詢和工作負載之間的查詢優先順序和資源配置。下列各節詳細說明如何設定 WM 查詢佇列、定義記憶體配置和並行擴展等佇列屬性，以及實作根據您的工作負載需求量身打造的優先順序規則。

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

  1. HIGHEST

  2. HIGH

  3. NORMAL

  4. LOW

  5. LOWEST

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

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

注意

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

讓我們舉一個範例，其中擷取、轉換、載入 （ETL） 工作負載的優先順序高於分析工作負載的優先順序。ETL 工作負載每 6 小時執行一次，分析工作負載則全天執行一次。當只有分析工作負載在叢集上執行時，它可取得整個系統，產生高輸送量和最佳的系統使用率。但是，當ETL工作負載開始時，它就有辦法，因為它具有更高的優先順序。作為ETL工作負載一部分執行的查詢，在入院期間取得路徑，在入院後也取得優先資源配置。因此，無論系統上執行的其他項目為何，ETL工作負載都會有可預測的執行。因此，它提供可預測的效能，以及管理員為其商業使用者提供服務層級協議 （SLAs） 的能力。

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

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

設定佇列優先順序

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

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

下列 wlm_json_configuration 範例定義三個使用者群組 (ingest、reporting 和 analytics)。來自這些群組的使用者所提交的查詢分別以 highest、normal 和 low 的優先順序執行。

[
    {
        "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佇列。

  • 您尚未定義可設定查詢優先順序的查詢監控規則 （QMRs）。這些規則包括QMR指標query_priority或QMR動作 change_query_priority。如需詳細資訊，請參閱WLM 查詢監控規則。