

 Amazon Redshift 將不再支援從修補程式 198 開始建立新的 Python UDFs。現有 Python UDF 將繼續正常運作至 2026 年 6 月 30 日。如需詳細資訊，請參閱[部落格文章](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/)。

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

# 工作負載管理
<a name="cm-c-implementing-workload-management"></a>

您可以將 Amazon Redshift WLM 設定成以自動 WLM 或手動 WLM 來執行。

您可以使用 Amazon Redshift 管理和排定並行查詢和使用者工作負載的優先順序，以最佳化效能和資源使用率。工作負載管理 (WLM) 可讓您定義佇列、使用者群組和其他建構模組，以控制分配給不同類型查詢或使用者的資源。

下列各節概述 Amazon Redshift 中的特定工作負載管理功能，並引導您完成其組態和監控程序。

**自動 WLM**

若要最大化系統輸送量並有效使用資源，您可讓 Amazon Redshift 以自動 WLM 管理如何分配資源來執行並行查詢。*自動 WLM* 會管理執行查詢所需的資源。Amazon Redshift 會決定多少個查詢並行執行和分配多少記憶體給每個分派的查詢。當您希望 Amazon Redshift 管理資源分割方式以執行並行查詢時，請使用自動 WLM。如需詳細資訊，請參閱[實作自動 WLM](automatic-wlm.md)。

 

使用並行擴展和自動 WLM，您可以藉由持續的快速查詢效能，支援幾乎無限的並行使用者和並行查詢。如需詳細資訊，請參閱[並行擴展](concurrency-scaling.md)。

**注意**  
在大多數情況下，我們建議您使用自動 WLM。如果您使用手動 WLM，而且想要移轉至自動 WLM，請參閱 [從手動 WLM 遷移至自動 WLM](#wlm-manual-to-automatic)。

使用自動 WLM 即可為佇列中的工作負載定義查詢優先順序。如需查詢優先順序的相關資訊，請參閱 [查詢優先順序](query-priority.md)。

**手動 WLM**

您可能有多個工作階段或使用者在同時執行查詢。有些查詢可能長時間佔用叢集資源，而影響其他查詢的效能。手動 WLM 有助於管理特殊使用案例的這種情況。當您想要對並行操作進行更多控制時，請使用手動 WLM。

您可以藉由修改 WLM 組態來為長期執行的查詢和短期執行的查詢建立個別的佇列，以管理系統效能。在執行時間，您可以根據使用者群組或查詢群組，將查詢路由至這些佇列。

您可以設定規則，以根據執行查詢的使用者，或您指定的標籤，將查詢路由至特定的佇列。您也可以設定要配置給每個佇列的記憶體數量，讓大型查詢在記憶體較多的佇列中執行。您也可以設定一個查詢監控規則 (QMR) 來限制長時間執行查詢。如需詳細資訊，請參閱[實作手動 WLM](cm-c-defining-query-queues.md)。

**注意**  
建議為您的手動 WLM 查詢佇列設定總共 15 個或更少的查詢槽。如需詳細資訊，請參閱[並行層級](cm-c-defining-query-queues.md#cm-c-defining-query-queues-concurrency-level)。

請注意，關於手動 WLM 組態，您可以分配給佇列的插槽上限為 50 個。不過，這並不表示在自動 WLM 組態中，Amazon Redshift 叢集一律會同時執行 50 個查詢。這可能會根據叢集上的記憶體需求或其他類型的資源配置而變更。

**Topics**
+ [切換 WLM 模式](#cm-c-switching-mode)
+ [修改 WLM 組態](#cm-c-modifying-wlm-configuration)
+ [實作自動 WLM](automatic-wlm.md)
+ [實作手動 WLM](cm-c-defining-query-queues.md)
+ [並行擴展](concurrency-scaling.md)
+ [短期查詢加速](wlm-short-query-acceleration.md)
+ [WLM 佇列指派規則](cm-c-wlm-queue-assignment-rules.md)
+ [將查詢指派給佇列](cm-c-executing-queries.md)
+ [WLM 動態和靜態組態屬性](cm-c-wlm-dynamic-properties.md)
+ [WLM 查詢監控規則](cm-c-wlm-query-monitoring-rules.md)
+ [WLM 系統資料表和檢視](cm-c-wlm-system-tables-and-views.md)

## 切換 WLM 模式
<a name="cm-c-switching-mode"></a>

您可以使用 Amazon Redshift 主控台啟用自動或手動 WLM：

1. 選擇 **Switch WLM mode (切換 WLM 模式)**。

1. 若要將其設定為自動 WLM，請選擇**自動 WLM**。使用此選擇時，最多使用八個佇列來管理查詢，而且 **Memory (記憶體)** 和 **Concurrency on main (主要叢集的並行)** 欄位都設為 **Auto (自動)**。此外，查詢的預設優先順序設定為**一般**。

1. 若要使用 Amazon Redshift 主控台啟用手動組態，請切換至**手動 WLM**。使用此選擇時，請指定用來管理查詢的佇列，以及 **Memory (記憶體)** 和 **Concurrency on main (主要叢集的並行)** 欄位值。使用手動組態時，您最多可以設定八個查詢佇列，並設定每個佇列中可同時執行的查詢數。

## 修改 WLM 組態
<a name="cm-c-modifying-wlm-configuration"></a>

修改 WLM 組態最簡單的方式是使用 Amazon Redshift 主控台。您也可以使用 AWS CLI 或 Amazon Redshift API。

在自動和手動 WLM 之間切換叢集時，您旳叢集會進入 `pending reboot` 狀態。變更要在下次叢集重新啟動後才會生效。

如需修改 WLM 組態的詳細資訊，請參閱《Amazon Redshift 管理指南》**中的[設定工作負載管理](https://docs.aws.amazon.com/redshift/latest/mgmt/workload-mgmt-config.html)。

### 從手動 WLM 遷移至自動 WLM
<a name="wlm-manual-to-automatic"></a>

若要最大化系統輸送量並最有效地使用資源，我們建議您為佇列設定自動 WLM。請考慮採用以下方法來設定從手動 WLM 順暢過渡到自動 WLM。

若要從手動 WLM 遷移到自動 WLM 並使用查詢優先順序，我們建議您建立新的參數群組，然後將該參數群組附加到叢集。如需詳細資訊，請參閱《Amazon Redshift 管理指南》**中的 [Amazon Redshift 參數群組](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-parameter-groups.html)。

**重要**  
若要變更參數群組或從手動切換到自動 WLM，需要重新啟動叢集。如需詳細資訊，請參閱[WLM 動態和靜態組態屬性](cm-c-wlm-dynamic-properties.md)。

我們使用一個範例，其中有三個手動 WLM 佇列。一個用於 ETL 工作負載、一個用於分析工作負載，一個用於資料科學工作負載。ETL 工作負載每 6 小時執行一次，分析工作負載全天執行，資料科學工作負載可能隨時激增。使用手動 WLM，您可以根據對於每個工作負載對業務重要性的理解，來指定每個工作負載佇列可取得的記憶體和並行。指定記憶體和並行不僅很難釐清，也會導致叢集資源被靜態分割，因而在僅執行一部分工作負載時造成浪費。

您可以將自動 WLM 搭配查詢優先順序一起使用，來指示工作負載的相對優先順序，以避免上述問題。對於這個範例，請依照下列步驟進行：
+ 建立一個新參數群組並切換到 **Auto WLM (自動 WLM)** 模式。
+ 為三個工作負載各別新增佇列：ETL 工作負載、分析工作負載和資料科學工作負載。針對與 **Manual WLM (手動 WLM)** 模式搭配使用的每一個工作負載使用相同的使用者群組。
+ 將 ETL 工作負載的優先順序指定為 `High`、分析工作負載的優先順序指定為 `Normal`、資料科學的優先順序指定為 `Low`。這些優先順序反映了不同工作負載或使用者群組的業務優先順序。
+ 或者，您也可以為分析或資料科學佇列啟用並行擴展，以便在即使 ETL 工作負載每 6 小時執行一次時，這些佇列中的查詢仍能獲得一致的效能。

運用查詢優先順序，當只有分析工作負載在叢集上執行時，它可取得整個系統。這可以產生高輸送量和最佳的系統使用率 不過，當 ETL 工作負載啟動時，它會獲得正確的權限，因為它具有更高的優先順序。做為 ETL 工作負載執行的查詢，除了在被核准之後可獲得優先資源分配，也能優先獲得許可。因此，無論系統上有哪些其他項目正在執行，ETL 工作負載都能如預期地執行。高優先順序工作負載能獲得可預測的效能，代價是其他較低優先順序工作負載的執行時間更久，因為它們的查詢要等候較重要的查詢先完成；或者，當它們與較高優先順序的查詢同時執行時，所獲得的資源較少。Amazon Redshift 所用的排程演算法可使較低優先順序的查詢不會面臨資源耗盡，而是持續取得進展，只是速度較慢而已。

**注意**  
逾時欄位不適用於自動 WLM。請改用 QMR 規則 `query_execution_time`。如需詳細資訊，請參閱[WLM 查詢監控規則](cm-c-wlm-query-monitoring-rules.md)。
QMR 動作 HOP 不適用於自動 WLM。請改用 `change priority` 動作。如需詳細資訊，請參閱[WLM 查詢監控規則](cm-c-wlm-query-monitoring-rules.md)。
叢集使用自動 WLM 和手動 WLM 佇列的方式不同，這可能會使您的組態混淆。例如，您可以在自動 WLM 佇列中設定優先順序屬性，但不能在手動 WLM 佇列中設定優先順序屬性。因此，請避免在參數群組中混合使用自動 WLM 佇列和手動 WLM 佇列。而是在遷移到自動 WLM 時建立新的參數群組。