从补丁 198 开始，Amazon Redshift 将不再支持创建新的 Python UDF。现有的 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/)。
# 工作负载管理
您可以配置 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 模式
您可以使用 Amazon Redshift 控制台来启用自动或手动 WLM：
1. 选择 **Switch WLM mode**（切换 WLM 模式）。
1. 要将其设置为自动 WLM，请选择**自动 WLM**。使用此选项，最多八个队列用于管理查询，并且**内存**和**主要并发**字段均设置为**自动**。此外，默认的查询优先级设置为**正常**。
1. 要使用 Amazon Redshift 控制台启用手动配置，请切换到**手动 WLM**。使用此选项，您可以指定用于管理查询的队列，以及**内存**和**主要并发**字段值。使用手动配置，您可以配置多达八个查询队列，并设置可在每个队列中同时运行的查询数。
## 修改 WLM 配置
修改 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
为了最大限度地提高系统吞吐量和高效地使用资源，我们建议您为队列设置自动 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 与查询优先级一起使用，以指示工作负载的相对优先级，从而避免前面的问题。对于此示例，请执行以下步骤：
+ 创建一个新参数组并切换到**自动 WLM**模式。
+ 为三个工作负载中的每一个添加队列：ETL 工作负载、分析工作负载和数据科学工作负载。为与**手动 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 时创建新参数组。
# 实施自动 WLM
使用自动工作负载管理 (WLM)，Amazon Redshift 管理查询并发性和内存分配。您可以使用服务类标识符 100-107 创建最多八个队列。每个队列都有一个优先级。有关更多信息，请参阅 [查询优先级](query-priority.md)。
自动 WLM 确定查询所需的资源量，并根据工作负载调整并发性。当系统中有查询需要大量资源（例如，较大表之间的哈希联接）时，并发性较低。当提交了较轻量的查询（例如，插入、删除、扫描或简单聚合）时，并发性较高。
自动 WLM 与短查询加速 (SQA) 分开，它以不同方式评估查询。自动 WLM 和 SQA 协同工作，即使长时间运行、资源密集型的查询处于活动状态，也可以完成短期运行和轻量级查询。有关 SQA 的更多信息，请参阅[短查询加速](wlm-short-query-acceleration.md)。
Amazon Redshift 通过参数组启用自动 WLM：
+ 如果您的集群使用默认参数组，则 Amazon Redshift 为它们启用自动 WLM。
+ 如果您的集群使用自定义参数组，可以配置您的集群以启用自动 WLM。我们建议您为自动 WLM 配置创建单独的参数组。
要配置 WLM，请编辑参数组中可与一个或多个集群关联的 `wlm_json_configuration` 参数。有关更多信息，请参阅 [修改 WLM 配置](cm-c-implementing-workload-management.md#cm-c-modifying-wlm-configuration)。
您可以在 WLM 配置中定义查询队列。您可以向默认 WLM 配置添加其他查询队列，最多可添加八个用户队列。您可以为每个查询队列配置以下内容：
+ 优先级
+ 并发扩展模式
+ 用户组
+ 查询组
+ 查询监控规则
## 优先级
您可以通过设置优先级值来定义查询在工作负载中的相对重要性。为队列指定优先级，并由与队列关联的所有查询继承。有关更多信息，请参阅 [查询优先级](query-priority.md)。
## 并发扩展模式
启用并发扩展后，Amazon Redshift 会在需要时自动增加额外的集群容量来处理增多的并发读取查询。不管查询在主集群上运行还是在并发扩展集群上运行，用户都将看到最新的数据。
您可以通过配置 WLM 队列来管理将哪些查询发送到并发扩展集群。为队列启用并发扩展后，符合条件的查询将发送到并发扩展集群，而不是排队等待。有关更多信息，请参阅 [并发扩展](concurrency-scaling.md)。
## 用户组
您可以通过指定每个用户组的名称或使用通配符将一组用户组分配给某个队列。当所列用户组的成员运行某个查询时，该查询将在相应的队列中运行。您可以向队列分配任意数量的用户组。有关更多信息，请参阅 [根据用户组为队列分配查询](cm-c-executing-queries.md#cm-c-executing-queries-assigning-queries-to-queues-based-on-user-groups)。
## 用户角色
您可以通过指定每个用户角色的名称或使用通配符将一组用户角色分配给某个队列。当所列用户角色的成员运行某个查询时，该查询将在相应的队列中运行。您可以向队列分配任意数量的用户角色。有关更多信息，请参阅[根据用户角色为队列分配查询](cm-c-executing-queries.md#cm-c-executing-queries-assigning-queries-to-queues-based-on-user-roles)。
## 查询组
您可以通过指定每个队列组的名称或使用通配符将一组查询组分配给某个队列。*查询组* 只是一种标签。在运行时，您可以将查询组标签分配给一系列查询。分配给所列查询组的任意查询都将在相应的队列中运行。您可以向队列分配任意数量的查询组。有关更多信息，请参阅 [为查询组分配查询](cm-c-executing-queries.md#cm-c-executing-queries-assigning-a-query-to-a-query-group)。
## 通配符
如果在 WLM 队列配置中启用了通配符，则可以单独地或使用 Unix shell 样式的通配符向队列分配用户组和查询组。模式匹配不区分大小写。
例如，“\$1”通配符字符匹配任意数量的字符。因此，如果您将 `dba_*` 添加到某个队列的用户组列表中，则属于名称以开头的 `dba_` 组的所有用户查询都将分配到该队列。示例包括 `dba_admin` 或 `DBA_primary`。“?”通配符匹配任意单个字符。因此，如果队列包括用户组 `dba?1`，则名为 `dba11` 和 `dba21` 的用户组匹配，但 `dba12` 不匹配。
默认情况下，未启用通配符。
## 查询监控规则
查询监控规则为 WLM 查询定义基于指标的性能界限，并指定在查询超出这些界限时需要采取的操作。例如，对于短时间运行查询专用的队列，您可创建取消运行超过 60 秒的查询的规则。要跟踪设计不佳的查询，您可创建记录包含嵌套循环的查询的其他规则。有关更多信息，请参阅 [WLM 查询监控规则](cm-c-wlm-query-monitoring-rules.md)。
## 检查自动 WLM
要检查是否启用了自动 WLM，请运行以下查询。如果查询返回至少一行内容，则说明自动 WLM 已启用。
```
select * from stv_wlm_service_class_config
where service_class >= 100;
```
以下查询显示遍历每个查询队列（服务类）的查询数量。它还显示平均执行时间、等待时间排在第九十百分位数的查询数量以及平均等待时间。自动 WLM 查询使用服务类 100 到 107。
```
select final_state, service_class, count(*), avg(total_exec_time),
percentile_cont(0.9) within group (order by total_queue_time), avg(total_queue_time)
from stl_wlm_query where userid >= 100 group by 1,2 order by 2,1;
```
要查明自动 WLM 运行并成功完成哪些查询，请运行以下查询。
```
select a.queue_start_time, a.total_exec_time, label, trim(querytxt)
from stl_wlm_query a, stl_query b
where a.query = b.query and a.service_class >= 100 and a.final_state = 'Completed'
order by b.query desc limit 5;
```
# 查询优先级
借助 Amazon Redshift，您可以使用工作负载管理（WM）管理并发查询和工作负载之间的查询优先级和资源分配。以下各节将详细介绍如何配置 WM 查询队列、定义内存分配和并发扩展等队列属性，以及如何根据工作负载要求实施优先级规则。
并非所有查询都具有同等重要性，并且通常一个工作负载或一组用户的性能可能更重要。如果您启用了[自动 WLM](automatic-wlm.md)，可以通过设置优先级值来定义查询在工作负载中的相对重要性。为队列指定优先级，并由与队列关联的所有查询继承。通过将用户组和查询组映射到队列，可以将查询与队列相关联。您可以设置以下优先级（从最高优先级到最低优先级列出）：
1. `HIGHEST`
1. `HIGH`
1. `NORMAL`
1. `LOW`
1. `LOWEST`
当具有不同优先级的查询争用相同的资源时，管理员使用这些优先级来显示其工作负载的相对重要性。Amazon Redshift 在将查询放入系统时使用优先级，并确定分配给查询的资源量。默认情况下，查询运行时的优先级设置为 `NORMAL`。
额外的优先级 `CRITICAL`（优先级高于 `HIGHEST`）适用于超级用户。要设置此优先级，您可以使用函数 [CHANGE\$1QUERY\$1PRIORITY](r_CHANGE_QUERY_PRIORITY.md)、[CHANGE\$1SESSION\$1PRIORITY](r_CHANGE_SESSION_PRIORITY.md) 和 [CHANGE\$1USER\$1PRIORITY](r_CHANGE_USER_PRIORITY.md)。要授予数据库用户使用这些函数的权限，您可以创建存储过程并向用户授予权限。有关示例，请参阅 [CHANGE\$1SESSION\$1PRIORITY](r_CHANGE_SESSION_PRIORITY.md)。
**注意**
一次只能运行一个 `CRITICAL` 查询。
回滚始终作为 CRITICAL 优先级运行。
我们来看个例子，其中，提取、转换、加载 (ETL) 工作负载的优先级高于分析工作负载的优先级。ETL 工作负载每六个小时运行一次，分析工作负载全天运行。当只有分析工作负载在集群上运行时，它会使整个系统自身产生高吞吐量和最佳系统利用率。但是，当 ETL 工作负载启动时，它会获得先行权，因为它具有更高的优先级。除了在被接纳之后的优先资源分配之外，作为 ETL 工作负载的一部分运行的查询在被接纳期间也会获得先行权。因此，无论系统上运行的是什么其他内容，ETL 工作负载都可以按预测的方式执行。因此，它提供了可预测的性能，并为管理员提供了为其业务用户提供服务级别协议 (SLA) 的能力。
在给定的集群中，高优先级工作负载的可预测性能是以其他优先级较低的工作负载为代价的。较低优先级的工作负载可能运行时间更长，因为其查询正在等待更重要的查询完成。或者，因为当它们与更高优先级的查询同时运行时，它们获得的资源比例较小，因此运行时间可能较长。较低优先级的查询不会遭受资源匮乏，而是继续以较慢的速度取得进展。
在前面的示例中，管理员可以为分析工作负载启用[并发扩展](concurrency-scaling.md)。即使 ETL 工作负载以高优先级运行，执行此操作也可以使分析工作负载保持其吞吐量。
## 配置队列优先级
如果已启用自动 WLM，则每个队列都具有优先级值。查询基于用户组和查询组路由至队列 先将队列优先级设置为 `NORMAL`。根据与队列的用户组和查询组关联的工作负载，将优先级设置为更高或更低。
您可以在 Amazon Redshift 控制台上更改队列的优先级。在 Amazon Redshift 控制台上，**工作负载管理**页面显示队列并支持编辑队列属性（如**优先级**）。要使用 CLI 或 API 操作设置优先级，请使用 `wlm_json_configuration` 参数。有关更多信息，请参阅《Amazon Redshift 管理指南》**中的[配置工作负载管理](https://docs.aws.amazon.com/redshift/latest/mgmt/workload-mgmt-config.html)。
以下 `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 查询监控规则](cm-c-wlm-query-monitoring-rules.md)。
例如，您可以定义一条规则以取消任何分类为 `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"
}
]
```
另一个示例是定义一条规则，以将当前优先级为 `lowest` 且磁盘溢出超过 1 TB 的任何查询的查询优先级更改为 `normal`。
```
"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\$1wlm\$1query\$1state 系统表中的 `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\$1wlm\$1query 系统表中的 `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 查询监控规则](cm-c-wlm-query-monitoring-rules.md)。
# 实施手动 WLM
通过手动 WLM，您可以通过修改 WLM 配置，为耗时查询和短时查询分别创建队列，来管理系统性能和用户体验。
当用户在 Amazon Redshift 中运行查询时，查询会路由到查询队列。每个查询队列都包含很多查询槽。每个队列都分配有一部分集群可用内存。队列的内存在队列的查询槽间分配。您可以允许 Amazon Redshift 通过自动 WLM 管理查询并发性。有关更多信息，请参阅 [实施自动 WLM](automatic-wlm.md)。
或者，您可以为每个查询队列配置 WLM 属性。这样可以指定如何在槽间分配内存，以及如何在运行时将查询路由到特定的队列。您还可以配置 WLM 属性以取消长时间运行的查询。
预设情况下，Amazon Redshift 配置以下查询队列：
+ **一个超级用户队列**
超级用户队列是专为超级用户预留的队列，无法进行配置。仅在需要运行影响系统的查询或用于故障排除目的时，才应使用该队列。例如，如果需要取消用户的耗时查询或向数据库添加用户，则可使用该队列。请不要使用它来执行常规查询。该队列不显示在控制台中，但在数据库的系统表中显示为第五队列。要在超级用户队列中运行查询，用户必须以超级用户身份登录并使用预定义的 `superuser` 查询组运行查询。
+ **一个默认用户队列**
默认队列初始配置为并发运行五个查询。在使用手动 WLM 时，您可以更改默认队列的并发、超时和内存分配属性，但不能指定用户组或查询组。默认队列必须是 WLM 配置中最后一个队列。未路由到其他队列的查询在默认队列中运行。
查询队列在 WLM 配置中定义。WLM 配置是参数组中的可编辑参数 (`wlm_json_configuration`)，可与一个或多个集群关联。有关更多信息，请参阅《Amazon Redshift 管理指南》**中的[配置工作负载管理](https://docs.aws.amazon.com/redshift/latest/mgmt/workload-mgmt-config.html)。
您可以向默认 WLM 配置添加其他查询队列，最多可添加八个用户队列。您可以为每个查询队列配置以下内容：
+ 并发扩展模式
+ 并发级别
+ 用户组
+ 查询组
+ 要使用的 WLM 内存百分比
+ WLM 超时
+ WLM 查询队列跳过
+ 查询监控规则
## 并发扩展模式
启用并发扩展后，Amazon Redshift 会在需要时自动增加额外的集群容量来处理增多的并发读取查询。不管查询在主集群上运行还是在并发扩展集群上运行，用户都将看到最新的数据。
您可以通过配置 WLM 队列来管理将哪些查询发送到并发扩展集群。为队列启用并发扩展后，符合条件的查询将发送到并发扩展集群，而不是排队等待。有关更多信息，请参阅 [并发扩展](concurrency-scaling.md)。
## 并发级别
队列中的查询以并发方式运行，直到它们达到为该队列定义的 WLM 队列插槽计数或*并发* 级别。达到并发级别后，后续查询将在队列中等待。
**注意**
WLM 并发级别不同于一个集群可以拥有的并行用户连接数。有关更多信息，请参阅《Amazon Redshift 管理指南》**中的[连接到集群](https://docs.aws.amazon.com/redshift/latest/mgmt/connecting-to-cluster.html)。
在自动 WLM 配置（推荐）中，并发级别设置为**自动**。Amazon Redshift 为查询动态分配内存，这会随之确定同时运行多少个查询。此数量基于运行查询和排队查询所需的资源。自动 WLM 不可配置。有关更多信息，请参阅 [实施自动 WLM](automatic-wlm.md)。
在手动 WLM 配置中，Amazon Redshift 向每个队列静态分配固定数量的内存。队列的内存在查询槽之间均匀分配。举例来说，如果向队列分配了 20% 的集群内存并且有 10 个插槽，则每个查询将分配 2% 的集群内存。内存分配保持固定，不论并行运行的查询数量是多少。由于此固定内存分配，对于插槽计数为 5 时可完全在内存中运行的查询，如果将其插槽计数提高到 20，则可能需要将中间结果写入磁盘。在这个例子中，每个查询的队列内存份额从 1/5 减少到 1/20。额外的磁盘 I/O 会降低性能。
所有用户定义的队列的最大插槽计数为 50。这限制了所有队列的总插槽数，包括默认队列。唯一不受此限制的队列是预留的超级用户队列。
默认情况下，手动 WLM 队列的并发级别为 5。在某些情况下，更高的并发级别可能对您的工作负载有用，如下所示：
+ 如果有许多小型查询被迫等待耗时的查询，则可创建一个具有更高插槽计数的独立队列，并将小型查询分配给该队列。并发级别较高的队列，分配给每个查询槽的内存较少，不过较小的查询需要的内存较少。
**注意**
如果您启用短查询加速 (SQA)，WLM 会自动让短时查询优先于长时查询，因此对于大多数工作流程，不需要单独的队列来进行短查询。有关更多信息，请参阅 [短查询加速](wlm-short-query-acceleration.md)。
+ 如果您有多个查询，每个查询访问单个切片上的数据，则可设置独立的 WLM 队列，以并发执行这些查询。Amazon Redshift 将并发查询分配给多个独立的切片，使多个查询能够在多个切片上并行执行。例如，如果某个查询是简单的聚合操作，且使用基于分配键的谓词，则该查询的数据将位于单个切片上。
### 手动 WLM 示例
此示例是一个简单的手动 WLM 场景，显示了如何分配插槽和内存。您对以下三个队列实施手动 WLM：
+ *data-ingestion 队列* – 此队列设置用于提取数据。为该队列分配了 20% 的集群内存，并且该队列有 5 个插槽。因此，队列中可以同时运行 5 个查询，每个查询分配了 4% 的集群内存。
+ *data-scientist 队列* – 专为内存密集型查询设计。为该队列分配了 40% 的集群内存，并且该队列有 5 个插槽。因此可以同时运行 5 个查询，每个查询分配了 8% 的集群内存。
+ *default 队列* – 这是为组织中大多数用户设计的队列。包括销售和会计团队，他们会运行短时间或中等时间长度且并不复杂的查询。为该队列分配了 40% 的集群内存，并且该队列有 40 个插槽。此队列中可以同时运行 40 个查询，每个查询分配了 1% 的集群内存。这是可以为此队列分配的最大插槽数，因为所有队列的总数限制为 50。
如果您正在运行 WLM，并且工作负载需要并行运行 15 个以上的查询，我们建议您启用并发扩展。这是因为将查询槽数增加到 15 以上可能会导致系统资源争用，限制了单个集群的总吞吐量。利用并发扩展，您可以并行运行数百个查询，最多可达到配置的并发扩展集群数。并发扩展集群的数量由 [max\$1concurrency\$1scaling\$1clusters](r_max_concurrency_scaling_clusters.md) 控制。有关并发扩展的更多信息，请参阅[并发扩展](concurrency-scaling.md)。
有关更多信息，请参阅 [查询性能改进](query-performance-improvement-opportunities.md)。
## 用户组
您可以通过指定每个用户组的名称或使用通配符将一组用户组分配给某个队列。当所列用户组的成员运行某个查询时，该查询将在相应的队列中运行。您可以向队列分配任意数量的用户组。有关更多信息，请参阅 [根据用户组为队列分配查询](cm-c-executing-queries.md#cm-c-executing-queries-assigning-queries-to-queues-based-on-user-groups)。
## 用户角色
您可以通过指定每个用户角色的名称或使用通配符将一组用户角色分配给某个队列。当所列用户角色的成员运行某个查询时，该查询将在相应的队列中运行。您可以向队列分配任意数量的用户角色。有关更多信息，请参阅 [根据用户角色为队列分配查询](cm-c-executing-queries.md#cm-c-executing-queries-assigning-queries-to-queues-based-on-user-roles)。
## 查询组
您可以通过指定每个队列组的名称或使用通配符将一组查询组分配给某个队列。查询组只是一种标签。在运行时，您可以将查询组标签分配给一系列查询。分配给所列查询组的任意查询都将在相应的队列中运行。您可以向队列分配任意数量的查询组。有关更多信息，请参阅 [为查询组分配查询](cm-c-executing-queries.md#cm-c-executing-queries-assigning-a-query-to-a-query-group)。
## 通配符
如果在 WLM 队列配置中启用了通配符，则可以单独地或使用 Unix shell 样式的通配符向队列分配用户组和查询组。模式匹配不区分大小写。
例如，“\$1”通配符字符匹配任意数量的字符。因此，如果您将 `dba_*` 添加到某个队列的用户组列表中，则属于名称以开头的 `dba_` 组的所有用户查询都将分配到该队列。示例包括 `dba_admin` 或 `DBA_primary`。“?”通配符匹配任意单个字符。因此，如果队列包括用户组 `dba?1`，则名为 `dba11` 和 `dba21` 的用户组匹配，但 `dba12` 不匹配。
默认情况下，通配符处于关闭状态。
## 要使用的 WLM 内存百分比
在自动 WLM 配置中，内存百分比设置为 **auto**。有关更多信息，请参阅 [实施自动 WLM](automatic-wlm.md)。
在手动 WLM 配置中，要指定分配给查询的可用内存量，您可以设置 `WLM Memory Percent to Use` 参数。默认情况下，会向每个用户定义队列分配相等的用户定义查询可用内存。例如，如果有四个用户定义队列，则会向每个队列分配 25% 的可用内存。超级用户队列有自己的分配内存，无法进行修改。要更改分配，您可以向每个队列分配整数比例的内存，总计最高为 100%。任意未分配的内存将由 Amazon Redshift 进行管理，如果有队列请求更多内存以进行处理，可以临时分配给该队列。
例如，如果配置了四个队列，则可以按以下方式分配内存：20%、30%、15%、15%。其余的 20% 未分配，由该服务管理。
## WLM 超时
WLM 超时 (`max_execution_time`) 已弃用。相反，使用 `query_execution_time` 创建查询监控规则 (QMR) 来限制经过的查询执行时间。有关更多信息，请参阅 [WLM 查询监控规则](cm-c-wlm-query-monitoring-rules.md)。
要限制允许查询在给定 WLM 队列中停留的时间，您可以为每个队列设置 WLM 超时。超时参数指定 Amazon Redshift 在取消或跳过查询前等待查询执行的时间量（单位为毫秒）。超时基于查询执行时间，不包括在队列中等待的时间。
WLM 尝试跳过 [CREATE TABLE AS](r_CREATE_TABLE_AS.md) (CTAS) 语句和只读查询，例如 SELECT 语句。无法跳过的查询将被取消。有关更多信息，请参阅 [WLM 查询队列跳过](wlm-queue-hopping.md)。
查询已进入“returning”状态时，WLM 超时不适用。要查看查询的状态，请参阅 [STV\$1WLM\$1QUERY\$1STATE](r_STV_WLM_QUERY_STATE.md) 系统表。COPY 语句和维护操作（例如 ALTER、ANALYZE 和 VACUUM）不受 WLM 超时约束。
WLM 超时功能类似于 [statement\$1timeout](r_statement_timeout.md) 配置参数。区别在于，`statement_timeout` 配置参数应用于整个集群，WLM 超时特定于 WLM 配置中的单个队列。
如果还指定了 [statement\$1timeout](r_statement_timeout.md)，则会使用 statement\$1timeout 和 WLM timeout (max\$1execution\$1time) 中的较小者。
## 查询监控规则
查询监控规则为 WLM 查询定义基于指标的性能界限，并指定在查询超出这些界限时需要采取的操作。例如，对于短时间运行查询专用的队列，您可创建取消运行超过 60 秒的查询的规则。要跟踪设计不佳的查询，您可创建记录包含嵌套循环的查询的其他规则。有关更多信息，请参阅 [WLM 查询监控规则](cm-c-wlm-query-monitoring-rules.md)。
# WLM 查询队列跳过
使用 Amazon Redshift，您可以通过启用 WLM（工作负载管理）查询队列跳转来管理工作负载并发性和资源分配。该功能允许查询在资源可用时从指定队列临时“跳转”到更高优先级的队列，从而提高整体查询性能和系统利用率。以下各节将提供在 Amazon Redshift 中配置和使用 WLM 查询队列跳转的详细指导。
由于 [WLM 超时](cm-c-defining-query-queues.md#wlm-timeout)或[查询监控规则 (QMR) 跃点操作](cm-c-wlm-query-monitoring-rules.md#cm-c-wlm-defining-query-monitoring-rules)，可能会跳过查询。您只能在手动 WLM 配置中跳转查询。
当跳过查询时，WLM 会尝试根据 [WLM 队列分配规则](cm-c-wlm-queue-assignment-rules.md)将该查询路由到下一个匹配的队列。如果查询不与任何其他队列定义匹配，则查询会被取消。它不会分配给默认队列。
## WLM 超时操作
下表总结了具有 WLM 超时的不同类型查询的行为。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/redshift/latest/dg/wlm-queue-hopping.html)
## WLM 超时队列跳过
如果下列类型的查询超时，WLM 会跳过它们：
+ 只读查询，例如 WLM 状态为 `running` 的 SELECT 语句。要了解查询的 WLM 状态，请查看 [STV\$1WLM\$1QUERY\$1STATE](r_STV_WLM_QUERY_STATE.md) 系统表中的 STATE 列。
+ CREATE TABLE AS (CTAS) 语句。WLM 队列跳跃支持用户定义的和系统生成的 CTAS 语句。
+ SELECT INTO 语句。
不受 WLM 超时约束的查询将继续在原始队列中运行，直到完成为止。以下类型的查询不受 WLM 超时约束：
+ COPY 语句
+ 维护操作，例如 ALTER、ANALYZE 和 VACUUM
+ 只读查询，例如 WLM 状态达到 `returning` 的 SELECT 语句。要了解查询的 WLM 状态，请查看 [STV\$1WLM\$1QUERY\$1STATE](r_STV_WLM_QUERY_STATE.md) 系统表中的 STATE 列。
没有资格因 WLM 超时跳过的查询将在超时时被取消。下列类型的查询没有资格因 WLM 超时跳过：
+ INSERT、UPDATE 和 DELETE 语句
+ UNLOAD 语句
+ 用户定义的函数 (UDF)
## WLM 超时重新分配和重新启动的查询
当跳过查询并且找不到匹配的队列时，该查询将被取消。
当跳过查询并且找到匹配的队列时，WLM 会尝试将该查询重新分配给新队列。如果无法重新分配查询，则它会在新队列中重新启动，如下所述。
只有在满足以下所有条件时，才会重新分配查询：
+ 找到匹配的队列。
+ 新队列有足够多的空闲插槽来运行查询。如果 [wlm\$1query\$1slot\$1count](r_wlm_query_slot_count.md) 参数设置为大于 1 的值，则查询可能需要多个插槽。
+ 新队列具有至少与查询当前使用的一样多的可用内存。
如果重新分配查询，则查询将继续在新队列中执行。将会保留中间结果，这样对总体执行时间造成的影响可降至最低。
如果无法重新分配查询，则该查询会被取消并在新队列中重新启动。中间结果会被删除。查询会在队列中等待，然后在有足够多的插槽可用时开始运行。
## QMR 跳过操作
下表总结了具有 QMR 跃点操作的不同类型查询的行为。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/redshift/latest/dg/wlm-queue-hopping.html)
要查明由 QMR 跳过的查询是否已重新分配、重新启动或取消，请查询 [STL\$1WLM\$1RULE\$1ACTION](r_STL_WLM_RULE_ACTION.md) 系统日志表。
## QMR 跳过操作重新分配和重新启动的查询
当跳过查询并且找不到匹配的队列时，该查询将被取消。
当跳过查询并且找到匹配的队列时，WLM 会尝试将该查询重新分配给新队列。如果无法重新分配查询，则它会在新队列中重新启动或在原始队列中继续执行，如下所述。
只有在满足以下所有条件时，才会重新分配查询：
+ 找到匹配的队列。
+ 新队列有足够多的空闲插槽来运行查询。如果 [wlm\$1query\$1slot\$1count](r_wlm_query_slot_count.md) 参数设置为大于 1 的值，则查询可能需要多个插槽。
+ 新队列具有至少与查询当前使用的一样多的可用内存。
如果重新分配查询，则查询将继续在新队列中执行。将会保留中间结果，这样对总体执行时间造成的影响可降至最低。
如果无法重新分配查询，则该查询会重新启动或在原始队列中继续执行。如果无法重新启动查询，则该查询会被取消并在新队列中重新启动。中间结果会被删除。查询会在队列中等待，然后在有足够多的插槽可用时开始执行。
# 教程：配置手动工作负载管理 (WLM) 队列
使用 Amazon Redshift，您可以配置手动工作负载管理（WLM）队列，为不同类型的查询和用户确定资源优先级并分配资源。手动 WLM 队列允许您控制特定队列的内存和并发设置，确保关键工作负载获得必要的资源，同时防止低优先级查询垄断系统。以下各节将指导您完成在 Amazon Redshift 中创建和配置手动 WLM 队列的过程，以满足您的工作负载管理要求。
## 概述
我们建议您在 Amazon Redshift 中配置自动工作负载管理 (WLM)。有关自动 WLM 的更多信息，请参阅[工作负载管理](cm-c-implementing-workload-management.md)。但是，如果您需要多个 WLM 队列，则本教程将逐步指导您完成在 Amazon Redshift 中配置手动工作负载管理 (WLM) 的过程。通过配置手动 WLM，您可以改进集群中的查询性能和资源分配。
Amazon Redshift 将用户查询路由至队列以进行处理。WLM 将定义这些查询路由至队列的方式。预设情况下，Amazon Redshift 具有两个可用于查询的队列：一个面向超级用户，一个面向用户。超级用户队列无法进行配置且一次只能处理一个查询。您应保留此队列以仅作故障排除之用。用户队列可一次处理多达 5 个查询，但您可以在需要时通过更改队列的并发级别来配置此能力。
若您有多个用户正在对数据库运行查询，您可能会发现另一种配置将更高效。例如，如果一些用户运行资源密集型操作（如 VACUUM），则这些操作可能会对资源不太密集型查询（如报告）产生负面影响。您可考虑添加其他队列并针对不同的工作负载配置它们。
**估计时间：**75 分钟
**估算费用：**50 美分
### 先决条件
您将需要一个 Amazon Redshift 集群、示例 TICKIT 数据库和 Amazon Redshift RSQL 客户端工具。如果您还没有设置上述这些项，请访问 [Amazon Redshift 入门指南](https://docs.aws.amazon.com/redshift/latest/gsg/new-user.html)和 [Amazon Redshift RSQL](https://docs.aws.amazon.com/redshift/latest/mgmt/rsql-query-tool.html)。
### 各个部分
+ [第 1 节：了解默认队列处理行为](#tutorial-wlm-understanding-default-processing)
+ [第 2 节：修改 WLM 查询队列配置](#tutorial-wlm-modifying-wlm-configuration)
+ [第 3 节：根据用户组和查询组将查询路由到队列](#tutorial-wlm-routing-queries-to-queues)
+ [第 4 节：使用 wlm\$1query\$1slot\$1count 临时覆盖队列中的并发级别](#tutorial-wlm-query-slot-count)
+ [第 5 节：清理资源](#tutorial-wlm-cleaning-up-resources)
## 第 1 节：了解默认队列处理行为
在您开始配置手动 WLM 前，了解 Amazon Redshift 中队列处理的默认行为是很有用的。在此节中，您将创建两个从多个系统表中返回信息的数据库视图。然后，您将运行一些测试查询以了解预设情况下路由查询的方式。有关系统表的更多信息，请参阅[系统表和视图参考](cm_chap_system-tables.md)。
### 步骤 1：创建 WLM\$1QUEUE\$1STATE\$1VW 视图
在此步骤中，您将创建一个名为 WLM\$1QUEUE\$1STATE\$1VW 的视图。此视图返回以下系统表中的信息。
+ [STV\$1WLM\$1CLASSIFICATION\$1CONFIG](r_STV_WLM_CLASSIFICATION_CONFIG.md)
+ [STV\$1WLM\$1SERVICE\$1CLASS\$1CONFIG](r_STV_WLM_SERVICE_CLASS_CONFIG.md)
+ [STV\$1WLM\$1SERVICE\$1CLASS\$1STATE](r_STV_WLM_SERVICE_CLASS_STATE.md)
您将在整个教程中使用此视图来监控在更改 WLM 配置后队列将发生的情况。下表描述了 WLM\$1QUEUE\$1STATE\$1VW 视图返回的数据。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/redshift/latest/dg/tutorial-configuring-workload-management.html)
#### 创建 WLM\$1QUEUE\$1STATE\$1VW 视图
1. 打开 [Amazon Redshift RSQL](https://docs.aws.amazon.com/redshift/latest/mgmt/rsql-query-tool.html) 并连接到您的 TICKIT 示例数据库。如果您没有此数据库，请参阅[先决条件](#tutorial-wlm-prereq)。
1. 运行以下查询以创建 WLM\$1QUEUE\$1STATE\$1VW 视图。
```
create view WLM_QUEUE_STATE_VW as
select (config.service_class-5) as queue
, trim (class.condition) as description
, config.num_query_tasks as slots
, config.query_working_mem as mem
, config.max_execution_time as max_time
, config.user_group_wild_card as "user_*"
, config.query_group_wild_card as "query_*"
, state.num_queued_queries queued
, state.num_executing_queries executing
, state.num_executed_queries executed
from
STV_WLM_CLASSIFICATION_CONFIG class,
STV_WLM_SERVICE_CLASS_CONFIG config,
STV_WLM_SERVICE_CLASS_STATE state
where
class.action_service_class = config.service_class
and class.action_service_class = state.service_class
and config.service_class > 4
order by config.service_class;
```
1. 运行以下查询以查看该视图包含的信息。
```
select * from wlm_queue_state_vw;
```
下面是示例结果。
```
query | description | slots | mem | max_time | user_* | query_* | queued | executing | executed
------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+----------
0 | (super user) and (query group: superuser) | 1 | 357 | 0 | false | false | 0 | 0 | 0
1 | (querytype:any) | 5 | 836 | 0 | false | false | 0 | 1 | 160
```
### 步骤 2：创建 WLM\$1QUERY\$1STATE\$1VW 视图
在此步骤中，您将创建一个名为 WLM\$1QUERY\$1STATE\$1VW 的视图。此视图返回 [STV\$1WLM\$1QUERY\$1STATE](r_STV_WLM_QUERY_STATE.md) 系统表中的信息。
您将在整个教程中使用此视图来监控正在运行的查询。下表描述了 WLM\$1QUERY\$1STATE\$1VW 视图返回的数据。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/redshift/latest/dg/tutorial-configuring-workload-management.html)
#### 创建 WLM\$1QUERY\$1STATE\$1VW 视图
1. 在 RSQL 中，运行以下查询以创建 WLM\$1QUERY\$1STATE\$1VW 视图。
```
create view WLM_QUERY_STATE_VW as
select query, (service_class-5) as queue, slot_count, trim(wlm_start_time) as start_time, trim(state) as state, trim(queue_time) as queue_time, trim(exec_time) as exec_time
from stv_wlm_query_state;
```
1. 运行以下查询以查看该视图包含的信息。
```
select * from wlm_query_state_vw;
```
下面是示例结果。
```
query | queue | slot_count | start_time | state | queue_time | exec_time
------+-------+------------+---------------------+-----------+------------+-----------
1249 | 1 | 1 | 2014-09-24 22:19:16 | Executing | 0 | 516
```
### 步骤 3：运行测试查询
在此步骤中，您将在 RSQL 中通过多个连接运行查询，并查看系统表以确定路由查询以进行处理的方式。
在此步骤中，您将需要打开两个 RSQL 窗口：
+ 在 RSQL 窗口 1 中，您将运行用于监控队列状态的查询和使用已在本教程中创建的视图的查询。
+ 在 RSQL 窗口 2 中，您将运行长时间运行的查询以更改在 RSQL 窗口 1 中找到的结果。
#### 运行测试查询
1. 打开两个 RSQL 窗口。如果您已打开一个窗口，则只需打开另一个窗口。您可针对这两个连接使用同一用户账户。
1. 在 RSQL 窗口 1 中，运行以下查询。
```
select * from wlm_query_state_vw;
```
下面是示例结果。
```
query | queue | slot_count | start_time | state | queue_time | exec_time
------+-------+------------+---------------------+-----------+------------+-----------
1258 | 1 | 1 | 2014-09-24 22:21:03 | Executing | 0 | 549
```
此查询返回一个自引用结果。当前正在运行的查询是来自此视图的 SELECT 语句。对此视图的查询将始终至少返回一个结果。将此结果与在下一步中启动长时间运行的查询后产生的结果进行比较。
1. 在 RSQL 窗口 2 中，从 TICKIT 示例数据库运行以下查询。此查询应会运行约一分钟时间，因此您有时间来探究之前创建的 WLM\$1QUEUE\$1STATE\$1VW 视图和 WLM\$1QUERY\$1STATE\$1VW 视图的结果。在某些情况下，您可能会发现查询运行的时长不足以查询这两个视图。在这些情况下，您可以增加 `l.listid ` 上的筛选条件值使其运行时间更长。
**注意**
为了缩短查询执行时间并改进系统性能，Amazon Redshift 在领导节点的内存中缓存特定查询类型的结果。当启用结果缓存时，后续查询的运行速度会快得多。要阻止查询快速运行，请对当前会话禁用结果缓存。
要为当前会话禁用结果缓存，请将 [enable\$1result\$1cache\$1for\$1session](r_enable_result_cache_for_session.md) 参数设置为 `off`，如下所示。
```
set enable_result_cache_for_session to off;
```
在 RSQL 窗口 2 中，运行以下查询。
```
select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid < 100000;
```
1. 在 RSQL 窗口 1 中，查询 WLM\$1QUEUE\$1STATE\$1VW 和 WLM\$1QUERY\$1STATE\$1VW 并将结果与之前的结果进行比较。
```
select * from wlm_queue_state_vw;
select * from wlm_query_state_vw;
```
以下是示例结果。
```
query | description | slots | mem | max_time | user_* | query_* | queued | executing | executed
------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+----------
0 | (super user) and (query group: superuser) | 1 | 357 | 0 | false | false | 0 | 0 | 0
1 | (querytype:any) | 5 | 836 | 0 | false | false | 0 | 2 | 163
query | queue | slot_count | start_time | state | queue_time | exec_time
------+-------+------------+---------------------+-----------+------------+-----------
1267 | 1 | 1 | 2014-09-24 22:22:30 | Executing | 0 | 684
1265 | 1 | 1 | 2014-09-24 22:22:36 | Executing | 0 | 4080859
```
请注意，之前的查询结果与本步骤中的结果之间存在以下区别：
+ WLM\$1QUERY\$1STATE\$1VW 中现在有两行。一个结果是用于对此视图运行 SELECT 操作的自引用查询。第二个结果是上一步中的长时间运行的查询。
+ WLM\$1QUEUE\$1STATE\$1VW 中的 executing 列已从 1 增加到 2。此列条目表示队列中有两个正在运行的查询。
+ executed 列在您每次在队列中运行一个查询时将会递增。
WLM\$1QUEUE\$1STATE\$1VW 视图可用于全面了解队列以及每个队列中正在处理的查询的数量。WLM\$1QUERY\$1STATE\$1VW 视图可用于更详细地了解当前正在运行的单个查询。
## 第 2 节：修改 WLM 查询队列配置
现在您了解了队列的默认工作方式，您将了解如何使用手动 WLM 配置查询队列。在此节中，您将为集群创建并配置新的参数组。您将创建另外两个用户查询并配置它们以基于查询的用户组或查询组标签接受查询。未路由至这两个队列之一的任何查询在运行时将会路由至默认队列。
**要在参数组中创建手动 WLM 配置**
1. 登录到 AWS 管理控制台并打开 Amazon Redshift 控制台，网址：[https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/)。
1. 在导航菜单上，选择 **Configurations（配置）**，然后选择 **Workload management（工作负载管理）**，以显示 **Workload management（工作负载管理）**页面。
1. 选择 **Create (创建)** 显示 **Create parameter group (创建参数组)** 窗口。
1. 为**参数组名称**和**描述**输入 **WLMTutorial**，然后选择**创建**以创建参数组。
**注意**
**参数组名称**会在创建时转换为全部小写格式。
1. 在 **Workload management**（工作负载管理）页面上，选择参数组 **wlmtutorial** 以显示详细信息页面，其中包含 **Parameters**（参数）和 **Workload management**（工作负载管理）选项卡。
1. 确认您正在 **Workload management**（工作负载管理）选项卡，然后选择 **Switch WLM mode**（切换 WLM 模式）以显示 **Concurrency settings**（并发设置）窗口。
1. 选择 **Manual WLM**（手动 WLM），然后选择 **Save**（保存）以切换到手动 WLM。
1. 选择 **Edit workload queues**（编辑工作负载队列）。
1. 选择 **Add queue**（添加队列）两次以添加两个队列。现在有三个队列：**队列 1**、**队列 2** 和**默认队列**。
1. 按如下方式输入每个队列的信息：
+ 对于**队列 1**，为**内存 (%)** 输入 **30**，为**主集群上的并发**输入 **2**，并为**查询组**输入 **test**。将其他设置保留为默认值。
+ 对于**队列 2**，为**内存 (%)** 输入 **40**，为**主集群上的并发**输入 **3**，并为**用户组**输入 **admin**。将其他设置保留为默认值。
+ 将默认队列的**主要并发**值设置为大于或等于 1 的值。不要对**默认队列**做出任何其它更改。WLM 将未分配的内存分配给默认队列。
1. 选择 **Save (保存)** 以保存您的设置。
接下来，将具有手动 WLM 配置的参数组与集群相关联。
**要将具有手动 WLM 配置的参数组与集群关联**
1. 登录到 AWS 管理控制台并打开 Amazon Redshift 控制台，网址：[https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/)。
1. 在导航菜单上，选择 **Clusters（集群）**，然后选择 **Clusters（集群）**以显示集群的列表。
1. 选择您的集群，例如 `examplecluster`，以显示集群详细信息。然后选择 **Properties**（属性）选项卡，以显示该集群的属性。
1. 在 **Database configurations**（数据库配置）部分中，选择 **Edit**（编辑）、**Edit parameter group**（编辑参数组）以显示参数组窗口。
1. 对于**参数组**，选择您之前创建的 **wlmtutorial** 参数组。
1. 选择 **Save changes**（保存更改）以关联参数组。
使用更改的参数组修改集群。但是，您需要重启集群才能将更改应用于数据库。
1. 选择您的集群，然后为 **Actions**（操作）选择 **Reboot**（重启）。
在重启集群后，状态将返回为 **Available**（可用）。
## 第 3 节：根据用户组和查询组将查询路由到队列
现在，您的集群已与一个新的参数组相关联，并且您已配置 WLM。接下来，运行一些查询，以了解 Amazon Redshift 如何将查询路由到队列进行处理。
### 步骤 1：在数据库中查看查询队列配置
首先，验证数据库具有您希望的 WLM 配置。
#### 查看查询队列配置
1. 打开 RSQL 并运行以下查询。此查询使用您在[步骤 1：创建 WLM\$1QUEUE\$1STATE\$1VW 视图](#tutorial-wlm-create-queue-state-view)中创建的 WLM\$1QUEUE\$1STATE\$1VW 视图。如果您在集群重启之前已将会话连接到数据库，则将需要进行重新连接。
```
select * from wlm_queue_state_vw;
```
下面是示例结果。
```
query | description | slots | mem | max_time | user_* | query_* | queued | executing | executed
------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+----------
0 | (super user) and (query group: superuser) | 1 | 357 | 0 | false | false | 0 | 0 | 0
1 | (query group: test) | 2 | 627 | 0 | false | false | 0 | 0 | 0
2 | (suser group: admin) | 3 | 557 | 0 | false | false | 0 | 0 | 0
3 | (querytype:any) | 5 | 250 | 0 | false | false | 0 | 1 | 0
```
将这些结果您与[步骤 1：创建 WLM\$1QUEUE\$1STATE\$1VW 视图](#tutorial-wlm-create-queue-state-view)中获得的结果进行比较。请注意，现在有另外两个队列。队列 1 现在是面向 test 查询组的队列，而队列 2 则是面向 admin 用户组的队列。
队列 3 现在是默认队列。列表中的最后一个队列始终是默认队列。这是在查询中未指定任何用户组或查询组的情况下默认将查询路由至的队列。
1. 运行以下查询以确认您的查询现在在队列 3 中运行。
```
select * from wlm_query_state_vw;
```
下面是示例结果。
```
query | queue | slot_count | start_time | state | queue_time | exec_time
------+-------+------------+---------------------+-----------+------------+-----------
2144 | 3 | 1 | 2014-09-24 23:49:59 | Executing | 0 | 550430
```
### 步骤 2：使用查询组队列运行查询
#### 使用查询组队列运行查询
1. 运行以下查询以将其路由至 `test` 查询组。
```
set query_group to test;
select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000;
```
1. 在另一个 RSQL 窗口中，运行以下查询。
```
select * from wlm_query_state_vw;
```
下面是示例结果。
```
query | queue | slot_count | start_time | state | queue_time | exec_time
------+-------+------------+---------------------+-----------+------------+-----------
2168 | 1 | 1 | 2014-09-24 23:54:18 | Executing | 0 | 6343309
2170 | 3 | 1 | 2014-09-24 23:54:24 | Executing | 0 | 847
```
查询已路由至 test 查询组，现在是队列 1。
1. 从队列状态视图中选择全部。
```
select * from wlm_queue_state_vw;
```
您将看到类似以下内容的结果。
```
query | description | slots | mem | max_time | user_* | query_* | queued | executing | executed
------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+----------
0 | (super user) and (query group: superuser) | 1 | 357 | 0 | false | false | 0 | 0 | 0
1 | (query group: test) | 2 | 627 | 0 | false | false | 0 | 1 | 0
2 | (suser group: admin) | 3 | 557 | 0 | false | false | 0 | 0 | 0
3 | (querytype:any) | 5 | 250 | 0 | false | false | 0 | 1 | 0
```
1. 现有，重置查询组并再次运行长时间运行的查询：
```
reset query_group;
select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000;
```
1. 针对视图运行查询以查看结果。
```
select * from wlm_queue_state_vw;
select * from wlm_query_state_vw;
```
以下是示例结果。
```
query | description | slots | mem | max_time | user_* | query_* | queued | executing | executed
------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+----------
0 | (super user) and (query group: superuser) | 1 | 357 | 0 | false | false | 0 | 0 | 0
1 | (query group: test) | 2 | 627 | 0 | false | false | 0 | 0 | 1
2 | (suser group: admin) | 3 | 557 | 0 | false | false | 0 | 0 | 0
3 | (querytype:any) | 5 | 250 | 0 | false | false | 0 | 2 | 5
query | queue | slot_count | start_time | state | queue_time | exec_time
------+-------+------------+---------------------+-----------+------------+-----------
2186 | 3 | 1 | 2014-09-24 23:57:52 | Executing | 0 | 649
2184 | 3 | 1 | 2014-09-24 23:57:48 | Executing | 0 | 4137349
```
结果应是查询现在正在队列 3 中再次运行。
### 步骤 3：创建数据库用户和组
在您可以在此队列中运行任何查询之前，需要在数据库中创建用户组并向该组添加用户。然后，您将使用新用户的凭证通过 RSQL 进行登录，然后运行查询。您需要作为超级用户（如管理员用户）运行查询来创建数据库用户。
#### 创建新的数据库用户和用户组
1. 在数据库中，通过在 RSQL 窗口中运行以下命令来创建名为 `adminwlm` 的新数据库用户。
```
create user adminwlm createuser password '123Admin';
```
1. 然后，运行以下命令来创建新用户组并将您的新 `adminwlm` 用户添加到该组。
```
create group admin;
alter group admin add user adminwlm;
```
### 步骤 4：使用用户组队列运行查询
接下来，您将运行一个查询并将该查询路由至用户组队列。当您想要将查询路由至配置为处理您要运行的查询类型的队列时，可执行此操作。
#### 使用用户组队列运行查询
1. 在 RSQL 窗口 2 中，运行以下查询以切换至 `adminwlm` 账户并以该用户的身份运行查询。
```
set session authorization 'adminwlm';
select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000;
```
1. 在 RSQL 窗口 1 中，运行以下查询以查看查询路由至的查询队列。
```
select * from wlm_query_state_vw;
select * from wlm_queue_state_vw;
```
以下是示例结果。
```
query | description | slots | mem | max_time | user_* | query_* | queued | executing | executed
------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+----------
0 | (super user) and (query group: superuser) | 1 | 357 | 0 | false | false | 0 | 0 | 0
1 | (query group: test) | 2 | 627 | 0 | false | false | 0 | 0 | 1
2 | (suser group: admin) | 3 | 557 | 0 | false | false | 0 | 1 | 0
3 | (querytype:any) | 5 | 250 | 0 | false | false | 0 | 1 | 8
query | queue | slot_count | start_time | state | queue_time | exec_time
------+-------+------------+---------------------+-----------+------------+-----------
2202 | 2 | 1 | 2014-09-25 00:01:38 | Executing | 0 | 4885796
2204 | 3 | 1 | 2014-09-25 00:01:43 | Executing | 0 | 650
```
此查询是在队列 2（`admin` 用户队列）中运行的。无论何时您以此用户的身份登录来运行查询，这些查询均将在队列 2 中运行，除非您指定要使用另一个查询组。所选队列取决于队列分配规则。有关更多信息，请参阅 [WLM 队列分配规则](cm-c-wlm-queue-assignment-rules.md)。
1. 现在，从 RSQL 窗口 2 中运行以下查询。
```
set query_group to test;
select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000;
```
1. 在 RSQL 窗口 1 中，运行以下查询以查看查询路由至的查询队列。
```
select * from wlm_queue_state_vw;
select * from wlm_query_state_vw;
```
以下是示例结果。
```
query | description | slots | mem | max_time | user_* | query_* | queued | executing | executed
------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+----------
0 | (super user) and (query group: superuser) | 1 | 357 | 0 | false | false | 0 | 0 | 0
1 | (query group: test) | 2 | 627 | 0 | false | false | 0 | 1 | 1
2 | (suser group: admin) | 3 | 557 | 0 | false | false | 0 | 0 | 1
3 | (querytype:any) | 5 | 250 | 0 | false | false | 0 | 1 | 10
query | queue | slot_count | start_time | state | queue_time | exec_time
------+-------+------------+---------------------+-----------+------------+-----------
2218 | 1 | 1 | 2014-09-25 00:04:30 | Executing | 0 | 4819666
2220 | 3 | 1 | 2014-09-25 00:04:35 | Executing | 0 | 685
```
1. 当您完成后，请重置查询组。
```
reset query_group;
```
## 第 4 节：使用 wlm\$1query\$1slot\$1count 临时覆盖队列中的并发级别
有时，用户可能会为某个特定查询临时需要更多资源。如果是这样的话，他们可以使用 wlm\$1query\$1slot\$1count 配置设置来临时覆盖查询队列中分配槽位的方式。*槽位* 是用于处理查询的内存和 CPU 的单位。您可在偶尔使用消耗集群中大量资源的查询时（例如，在数据库中执行 VACUUM 操作时）覆盖槽位计数。
您可能会发现用户经常需要针对特定类型的查询设置 wlm\$1query\$1slot\$1count。如果是，请考虑调整 WLM 配置并为用户提供更适合其查询需求的队列。有关通过使用槽位计数临时覆盖并发级别的更多信息，请参阅[wlm\$1query\$1slot\$1count](r_wlm_query_slot_count.md)。
### 步骤 1：使用 wlm\$1query\$1slot\$1count 覆盖并发级别
在本教程中，我们将运行同一个长时间运行的 SELECT 查询。我们将以 `adminwlm` 用户的身份运行查询，并使用 wlm\$1query\$1slot\$1count 增加查询的可用槽位数。
#### 使用 wlm\$1query\$1slot\$1count 覆盖并发级别
1. 提高对查询的限制以确保您有足够的时间来查询 WLM\$1QUERY\$1STATE\$1VW 视图并查看结果。
```
set wlm_query_slot_count to 3;
select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000;
```
1. 现在，可使用管理员用户查询 WLM\$1QUERY\$1STATE\$1VW，以查看查询的运行情况。
```
select * from wlm_query_state_vw;
```
下面是示例结果。
```
query | queue | slot_count | start_time | state | queue_time | exec_time
------+-------+------------+---------------------+-----------+------------+-----------
2240 | 2 | 1 | 2014-09-25 00:08:45 | Executing | 0 | 3731414
2242 | 3 | 1 | 2014-09-25 00:08:49 | Executing | 0 | 596
```
请注意，查询的槽位计数是 3。此计数表示查询正在使用所有三个槽位来处理查询，并将队列中的所有资源分配给查询。
1. 现在，运行以下查询。
```
select * from WLM_QUEUE_STATE_VW;
```
下面是示例结果。
```
query | description | slots | mem | max_time | user_* | query_* | queued | executing | executed
------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+----------
0 | (super user) and (query group: superuser) | 1 | 357 | 0 | false | false | 0 | 0 | 0
1 | (query group: test) | 2 | 627 | 0 | false | false | 0 | 0 | 4
2 | (suser group: admin) | 3 | 557 | 0 | false | false | 0 | 1 | 3
3 | (querytype:any) | 5 | 250 | 0 | false | false | 0 | 1 | 25
```
wlm\$1query\$1slot\$1count 配置设置仅对当前会话有效。如果会话过期或者另一用户运行查询，则使用 WLM 配置。
1. 重置槽位计数并重新运行测试。
```
reset wlm_query_slot_count;
select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000;
```
以下是示例结果。
```
query | description | slots | mem | max_time | user_* | query_* | queued | executing | executed
------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+----------
0 | (super user) and (query group: superuser) | 1 | 357 | 0 | false | false | 0 | 0 | 0
1 | (query group: test) | 2 | 627 | 0 | false | false | 0 | 0 | 2
2 | (suser group: admin) | 3 | 557 | 0 | false | false | 0 | 1 | 2
3 | (querytype:any) | 5 | 250 | 0 | false | false | 0 | 1 | 14
query | queue | slot_count | start_time | state | queue_time | exec_time
------+-------+------------+---------------------+-----------+------------+-----------
2260 | 2 | 1 | 2014-09-25 00:12:11 | Executing | 0 | 4042618
2262 | 3 | 1 | 2014-09-25 00:12:15 | Executing | 0 | 680
```
### 步骤 2：从不同的会话中运行查询
接下来，从不同会话中运行查询。
#### 从不同的会话中运行查询
1. 在 RSQL 窗口 1 和 2 中，运行以下查询以使用测试查询组。
```
set query_group to test;
```
1. 在 RSQL 窗口 1 中，运行以下长时间运行的查询。
```
select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000;
```
1. 由于长时间运行的查询仍在 RSQL 窗口 1 中运行，请运行以下查询。这些命令将增加槽位计数，以使用队列的所有槽位，然后开始运行长时间运行的查询。
```
set wlm_query_slot_count to 2;
select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000;
```
1. 打开第三个 RSQL 窗口并查询视图以查看结果。
```
select * from wlm_queue_state_vw;
select * from wlm_query_state_vw;
```
以下是示例结果。
```
query | description | slots | mem | max_time | user_* | query_* | queued | executing | executed
------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+----------
0 | (super user) and (query group: superuser) | 1 | 357 | 0 | false | false | 0 | 0 | 0
1 | (query group: test) | 2 | 627 | 0 | false | false | 1 | 1 | 2
2 | (suser group: admin) | 3 | 557 | 0 | false | false | 0 | 0 | 3
3 | (querytype:any) | 5 | 250 | 0 | false | false | 0 | 1 | 18
query | queue | slot_count | start_time | state | queue_time | exec_time
------+-------+------------+---------------------+---------------+------------+-----------
2286 | 1 | 2 | 2014-09-25 00:16:48 | QueuedWaiting | 3758950 | 0
2282 | 1 | 1 | 2014-09-25 00:16:33 | Executing | 0 | 19335850
2288 | 3 | 1 | 2014-09-25 00:16:52 | Executing | 0 | 666
```
请注意，第一个查询正在使用分配给队列 1 的槽位之一来运行查询。此外，请注意，队列中有一个查询正在等待（其中 `queued` 为 `1`，`state` 为 `QueuedWaiting`）。在第一个查询完成之后，第二个查询即会开始运行。此执行发生的原因在于：两个查询均已路由至 `test` 查询组，而且第二个查询必须等待有足够多的槽位才能开始进行处理。
## 第 5 节：清理资源
只要您的集群正在运行，就将继续产生费用。完成本教程后，请按照《Amazon Redshift 入门指南》**中的[查找其它资源并重置环境](https://docs.aws.amazon.com/redshift/latest/gsg/rs-gsg-clean-up-tasks.html)中的步骤操作，使您的环境返回上一个状态。
有关 WLM 的更多信息，请参阅 [工作负载管理](cm-c-implementing-workload-management.md)。
# 并发扩展
使用并发扩展功能，您可以支持成千上万的并发用户和并发查询，同时提供始终如一的快速查询性能。开启并发扩展后，Amazon Redshift 会自动增加额外的集群容量来处理增多的读取查询和写入查询。不管查询在主集群上运行还是在并发扩展集群上运行，用户都将看到最新的数据。
您可以通过配置 WLM 队列来管理将哪些查询发送到并发扩展集群。开启并发扩展后，符合条件的查询将发送到并发扩展集群，而不是排队等待。
仅当并发扩展集群正在主动运行查询时，您才需要为其付费。有关定价的更多信息，包括费用如何累积和最低费用，请参阅[并发扩展定价](https://aws.amazon.com/redshift/pricing/#Concurrency_Scaling_pricing)。
**Topics**
+ [并发扩展功能](#concurrency-scaling-capabilities)
+ [并发扩展的限制](#concurrency-scaling-limitations)
+ [AWS 区域并发扩展的](#concurrency-scaling-regions)
+ [并发扩展候选项](#concurrency-scaling-candidates)
+ [配置并发扩展队列](#concurrency-scaling-queues)
+ [监控并发扩展](#concurrency-scaling-monitoring)
+ [并发扩展系统视图](#concurrency-scaling-monitoring-system-views)
## 并发扩展功能
为 WLM 队列开启并发扩展时，它将适用于读取操作，如控制面板查询。它还适用于常用的写操作，例如用于数据摄入和处理的语句。
### 写操作的并发扩展功能
并发扩展支持经常使用的写操作，例如提取、转换和加载 (ETL) 语句。当您希望在集群收到大量请求时保持一致的响应时间时，写操作的并发扩展特别有用。它提高了在主集群上争夺资源的写操作的吞吐量。
并发扩展支持 COPY、INSERT、DELETE、UPDATE、CREATE TABLE AS (CTAS) 和 VACUUM 语句。此外，并发扩展支持手动刷新实体化视图（MV）和自动 vacuum 操作。不支持其他数据处理语言 (DML) 语句和数据定义语言 (DDL) 语句。如果不支持的写入语句（如 CREATE without TABLE AS）包含在支持的写入语句之前的显式事务中，则所有写入语句都不会在并发扩展集群上运行。
当您为并发扩展累计积分时，此积分应计适用于读取和写操作。
## 并发扩展的限制
以下是使用 Amazon Redshift 并发扩展的限制：
+ 它不支持查询使用交错排序键的表。
+ 它不支持查询临时表。
+ 它不支持访问受限制性网络或 Virtual Private Cloud (VPC) 配置保护的外部资源的查询。
+ 它不支持包含 Python 用户定义函数（UDF）和 Lambda UDF 的查询。
+ 它不支持访问系统表、PostgreSQL 目录表或非备份表的查询。
+ 在实施限制性 IAM 策略权限时，它不支持访问外部资源的 COPY 或 UNLOAD 查询。这包括应用于资源（例如 Amazon S3 存储桶或 DynamoDB 表）或源的权限。IAM 源可以包括：
+ `aws:sourceVpc` – 一个 VPC 源。
+ `aws:sourceVpce` – 源 VPC 端点。
+ `aws:sourceIp` – 源 IP 地址。
在某些情况下，您可能需要删除限制资源或源的权限，以便将访问资源的 COPY 和 UNLOAD 查询发送到并发扩展集群。
有关资源策略的更多信息，请参阅《AWS Identity and Access Management 用户指南》中的[策略类型](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policy-types)，以及[使用存储桶策略控制从 VPC 端点的访问](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-bucket-policies-vpc-endpoint.html)。
+ 大多数 DDL 操作（例如 CREATE TABLE）不支持 Amazon Redshift 并发扩展用于写操作。
+ 它不支持 COPY 命令的 ANALYZE。
+ 它不支持对 DISTSTYLE 设置为 ALL 的目标表进行写操作。
+ 它不支持以下文件格式的 COPY：
+ Parquet
+ ORC
+ 它不支持对具有身份列的表进行写操作。
+ Amazon Redshift 仅支持 Amazon Redshift RA3 节点上写操作的并发扩展。其他节点类型不支持写操作的并发扩展。
## AWS 区域并发扩展的
通过 Amazon Redshift，您可以使用并发扩展来管理 Redshift 集群上的并发工作负载需求。本主题详细介绍在哪些区域可以通过 Amazon Redshift 使用并发扩展。
并发扩展在以下 AWS 区域可用：
+ 美国东部（弗吉尼亚北部）区域 (us-east-1)
+ 美国东部（俄亥俄）区域 (us-east-2)
+ 美国西部（加利福尼亚北部）区域 (us-west-1)
+ 美国西部（俄勒冈州）区域 (us-west-2)
+ 非洲（开普敦）区域 (af-south-1)
+ 亚太地区（孟买）区域（ap-south-1）
+ 亚太（海得拉巴）区域（ap-south-2）
+ 亚太地区（首尔）区域 (ap-northeast-2)
+ 亚太地区（大阪）区域 (ap-northeast-3)
+ 亚太地区（新加坡）区域 (ap-southeast-1)
+ 亚太地区（悉尼）区域 (ap-southeast-2)
+ 亚太地区（雅加达）区域 (ap-southeast-3)
+ 亚太地区（马来西亚）区域（ap-southeast-5）
+ 亚太地区（新西兰）区域（ap-southeast-6）
+ 亚太地区（泰国）区域（ap-southeast-7）
+ 亚太地区（香港）区域 (ap-east-1)
+ 亚太地区（台北）区域（ap-east-2）
+ 亚太地区（东京）区域（ap-northeast-1）
+ 加拿大（中部）区域（ca-central-1）
+ 加拿大西部（卡尔加里）区域 (ca-west-1)
+ 中国（北京）区域 (cn-north-1)
+ 中国（宁夏）区域 (cn-northwest-1)
+ 欧洲（法兰克福）区域 (eu-central-1)
+ 欧洲（爱尔兰）区域 (eu-west-1)
+ 欧洲（伦敦）区域 (eu-west-2)
+ 欧洲（巴黎）区域 (eu-west-3)
+ 欧洲（斯德哥尔摩）区域 (eu-north-1)
+ 欧洲（苏黎世）区域（eu-central-2）
+ 欧洲（米兰）区域 (eu-south-1)
+ 欧洲（西班牙）区域（eu-south-2）
+ 以色列（特拉维夫）区域（il-central-1）
+ 中东（巴林）区域 (me-south-1)
+ 墨西哥（中部）区域（mx-central-1）
+ 南美洲（圣保罗）区域 (sa-east-1)
+ AWS GovCloud（美国东部）
+ AWS GovCloud（美国西部）
## 并发扩展候选项
使用 Amazon Redshift，您可以横向扩展查询处理，以加速并发查询的执行。以下主题介绍 Amazon Redshift 用于确定将哪些查询路由到并发扩展的标准。
仅当主集群满足以下要求时，才将查询路由到并发扩展集群：
+ EC2-VPC 平台。
+ 节点类型必须是 dc2.8xlarge、dc2.large、ra3.large、ra3.xlplus、ra3.4xlarge 或 ra3.16xlarge。仅 Amazon Redshift RA3 节点支持写操作的并发扩展。
+ 对于具有 ra3.xlplus、ra3.4xlarge 或 ra3.16xlarge 节点类型的集群，最多 32 个计算节点。此外，在最初创建集群时，主集群的节点数不能大于 32 个节点。例如，即使集群当前有 20 个节点，但最初创建时具有 40 个节点，它也不符合并发扩展的要求。相反，如果 DC2 集群当前有 40 个节点，但最初创建时具有 20 个节点，则它确实满足并发扩展的要求。
+ 非单节点集群。
## 配置并发扩展队列
使用 Amazon Redshift，您可以通过配置并发扩展来管理并发性和系统资源。并发扩展队列允许您对可并发执行的查询或用户会话数量设置限制。下一节将说明如何在 Amazon Redshift 中启用并发扩展队列，以便有效处理并发查询和用户会话。
您可以在工作负载管理器（WLM）队列中启用并发扩展，来将查询路由到并发扩展集群。要在队列上开启并发扩展，请将**并发扩展模式**值设置为**自动**。
在启用了并发扩展的队列中，当路由过来的查询数超过了队列的并发容量（不论该容量为手动配置还是自动确定）时，符合条件的查询将发送到并发扩展集群。当主集群上有队列槽可用时，查询将路由到主集群并在主集群上运行。与任何 WLM 队列一样，在将查询路由到并发扩展队列时，您可以基于用户组、使用查询组标签来标记查询，也可以根据在[为队列分配查询](https://docs.aws.amazon.com/redshift/latest/dg/cm-c-executing-queries.html)中定义的匹配条件。您还可以通过定义 [WLM 查询监控规则](cm-c-wlm-query-monitoring-rules.md)来路由查询。例如，您可以将所有耗时超过 5 秒的查询路由到并发扩展队列。请记住，根据您使用的是自动 WLM 还是手动 WLM，排队行为可能会有所不同。有关更多信息，请参阅[实施自动 WLM](https://docs.aws.amazon.com/redshift/latest/dg/automatic-wlm.html) 或[实施手动 WLM](https://docs.aws.amazon.com/redshift/latest/dg/cm-c-defining-query-queues.html)。
并发扩展集群的默认数量为 1。可以使用的并发扩展集群的数量由 [max\$1concurrency\$1scaling\$1clusters](r_max_concurrency_scaling_clusters.md) 控制。
## 监控并发扩展
借助 Amazon Redshift，您可以监控和管理并发扩展，从而优化数据仓库工作负载的性能和成本效益。并发扩展允许 Amazon Redshift 在工作负载需求增加时自动增加集群容量，并在需求减少时移除该容量。下一节将提供有关监控 Amazon Redshift 集群并发扩展的指导。
您可以通过以下方式查看查询运行在主集群还是并发扩展集群上：在 Amazon Redshift 控制台中，导航到**集群**，选择一个集群。然后选择**查询监控**选项卡和**工作负载并发**以查看有关正在运行的查询和排队查询的信息。
要查找执行时间，请查询 STL\$1QUERY 表并筛选 `concurrency_scaling_status` 列。以下查询比较在并发扩展集群上运行的查询与在主集群上运行的查询的队列时间和执行时间。
```
SELECT w.service_class AS queue
, CASE WHEN q.concurrency_scaling_status = 1 THEN 'concurrency scaling cluster' ELSE 'main cluster' END as concurrency_scaling_status
, COUNT( * ) AS queries
, SUM( q.aborted ) AS aborted
, SUM( ROUND( total_queue_time::NUMERIC / 1000000,2) ) AS queue_secs
, SUM( ROUND( total_exec_time::NUMERIC / 1000000,2) ) AS exec_secs
FROM stl_query q
JOIN stl_wlm_query w
USING (userid,query)
WHERE q.userid > 1
AND q.starttime > '2019-01-04 16:38:00'
AND q.endtime < '2019-01-04 17:40:00'
GROUP BY 1,2
ORDER BY 1,2;
```
根据您的要求调整 `starttime` 和 `endtime` 值。
## 并发扩展系统视图
通过 Amazon Redshift，您可以使用并发扩展系统视图来监控和管理集群中的并发扩展活动。下一节将介绍如何查询这些系统视图并解释结果，以便在 Amazon Redshift 环境中有效利用并发扩展。
一组带有前缀 SVCS 的系统视图提供了系统日志表中有关主集群和并发扩展集群上的查询的详细信息。
以下视图具有与相应的 STL 视图或 SVL 视图类似的信息：
+ [SVCS\$1ALERT\$1EVENT\$1LOG](r_SVCS_ALERT_EVENT_LOG.md)
+ [SVCS\$1COMPILE](r_SVCS_COMPILE.md)
+ [SVCS\$1EXPLAIN](r_SVCS_EXPLAIN.md)
+ [SVCS\$1PLAN\$1INFO](r_SVCS_PLAN_INFO.md)
+ [SVCS\$1QUERY\$1SUMMARY](r_SVCS_QUERY_SUMMARY.md)
+ [SVCS\$1STREAM\$1SEGS](r_SVCS_STREAM_SEGS.md)
以下视图专门用于并发扩展。
+ [SVCS\$1CONCURRENCY\$1SCALING\$1USAGE](r_SVCS_CONCURRENCY_SCALING_USAGE.md)
有关并发扩展的更多信息，请参阅《Amazon Redshift 管理指南》**中的以下主题。
+ [查看并发扩展数据](https://docs.aws.amazon.com/redshift/latest/mgmt/performance-metrics-concurrency-scaling.html)
+ [查看查询执行期间的集群性能](https://docs.aws.amazon.com/redshift/latest/mgmt/performance-metrics-query-cluster.html)
+ [查看查询详细信息](https://docs.aws.amazon.com/redshift/latest/mgmt/performance-metrics-query-execution-details.html)
# 短查询加速
短查询加速 (SQA) 让选定的短时查询优先于长时查询。SQA 在专用空间中运行短时查询，因此 SQA 查询不会被迫排在队列中的长时查询后面等待。SQA 仅优先处理用户定义的队列中的短时查询。使用 SQA，短时查询会更快地开始运行，用户会更快地看到结果。
如果您启用 SQA，则可以减少专用于运行短查询的工作负载管理 (WLM) 队列。此外，长时查询无需与短查询竞争队列中的插槽，因此您可以将 WLM 队列配置为使用较少的查询插槽。当您使用较低的并发度时，查询吞吐量会增加，而且大多数工作负载的总体系统性能会得到提高。
[CREATE TABLE AS](r_CREATE_TABLE_AS.md) (CTAS) 语句和只读查询 (例如 [SELECT](r_SELECT_synopsis.md) 语句) 符合 SQA 资格。
Amazon Redshift 使用机器学习算法分析每个有资格的查询，并预测查询的执行时间。默认情况下，WLM 根据集群的工作负载分析为 SQA 最大运行时动态分配值。或者，您也可以指定一个介于 1-20 秒之间的固定值。如果预测的查询运行时间小于定义或动态分配的 SQA 最大运行时间，并且查询在 WLM 队列中等待，则 SQA 会将查询与 WLM 队列分开并安排优先执行。如果查询运行的时间长于 SQA 最大运行时间，WLM 会根据 [WLM 队列分配规则](cm-c-wlm-queue-assignment-rules.md)将查询移动到第一个匹配 WLM 队列。随着时间的推移，预测会随着 SQA 从您的查询模式中学习而提高。
默认情况下，为默认参数组和所有新参数组启用 SQA。要在 Amazon Redshift 控制台中禁用 SQA，请编辑参数组的 WLM 配置并取消选择**启用短查询加速**。作为最佳实践，我们建议您使用 WLM 查询插槽计数 15 或更少，以保持最佳整体系统性能。有关修改 WLM 配置的信息，请参阅《Amazon Redshift 管理指南》**中的[配置工作负载管理](https://docs.aws.amazon.com/redshift/latest/mgmt/workload-mgmt-config.html)。
## 短查询的最大运行时间
当您启用 SQA 时，默认情况下 WLM 会将短查询的最大运行时间设置为动态的。我们建议保留 SQA 最大运行时间的动态设置。您可以通过指定一个介于 1-20 秒之间的固定值来覆盖默认设置。
在某些情况下，您可能会考虑对 SQA 最大运行时间值使用不同的值，以提高系统性能。在这些情况下，可分析您的工作负载以查找您的大部分短时查询的最大执行时间。以下查询返回位于大约第七十个百分位数的查询的最大运行时间。
```
select least(greatest(percentile_cont(0.7)
within group (order by total_exec_time / 1000000) + 2, 2), 20)
from stl_wlm_query
where userid >= 100
and final_state = 'Completed';
```
在确定适合您的工作负载的最大运行时间值后，不需要更改它，除非工作负载发生重大变化。
## 监控 SQA
要检查是否启用了 SQA，请运行以下查询。如果查询返回一行内容，则说明 SQA 已启用。
```
select * from stv_wlm_service_class_config
where service_class = 14;
```
以下查询显示遍历每个查询队列（服务类）的查询数量。它还显示平均执行时间、等待时间排在第九十百分位数的查询数量以及平均等待时间。SQA 查询使用服务类 14。
```
select final_state, service_class, count(*), avg(total_exec_time),
percentile_cont(0.9) within group (order by total_queue_time), avg(total_queue_time)
from stl_wlm_query where userid >= 100 group by 1,2 order by 2,1;
```
要查明哪些查询由 SQA 选取并成功完成，请运行以下查询。
```
select a.queue_start_time, a.total_exec_time, label, trim(querytxt)
from stl_wlm_query a, stl_query b
where a.query = b.query and a.service_class = 14 and a.final_state = 'Completed'
order by b.query desc limit 5;
```
要查找由 SQA 选取但超时的查询，请运行以下查询。
```
select a.queue_start_time, a.total_exec_time, label, trim(querytxt)
from stl_wlm_query a, stl_query b
where a.query = b.query and a.service_class = 14 and a.final_state = 'Evicted'
order by b.query desc limit 5;
```
有关已移出的查询的更多信息，更笼统地说，有关可以对查询采取的基于规则的操作的更多信息，请参阅[WLM 查询监控规则](cm-c-wlm-query-monitoring-rules.md)。
# WLM 队列分配规则
使用 Amazon Redshift，您可以通过在工作负载管理（WLM）配置中定义队列分配规则来控制分配给用户查询的内存和 CPU 资源。下一节将介绍如何创建和管理 WLM 队列分配规则，以实现高效的资源分配并满足 Amazon Redshift 中各种工作负载的服务级别协议。
当用户运行查询时，WLM 基于 WLM 队列分配规则将查询分配给第一个匹配的队列。
1. 如果用户以超级用户身份登录并在带有超级用户标签的查询组中运行某个查询，则该查询会分配到超级用户队列。
1. 如果用户属于某个角色、属于所列的用户组或在所列查询组中运行某个查询，则该查询会分配给第一个匹配队列。
1. 如果某个查询不满足任何条件，则该查询会分配给默认队列，即 WLM 配置中定义的最后一个队列。
下图说明这些规则的工作方式。
![\[WLM 用于将查询分配到队列的规则流程图。\]](http://docs.aws.amazon.com/zh_cn/redshift/latest/dg/images/queue-assignment-rules-with-rbac.png)
## 队列分配示例
下表列出了具有超级用户队列和四个用户定义队列的 WLM 配置。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/redshift/latest/dg/cm-c-wlm-queue-assignment-rules.html)
下面的插图介绍系统如何根据用户组和查询组将查询分配给前一个表中的队列。有关如何在运行时将查询分配给用户组和查询组的信息，请参阅本节后面的[为队列分配查询](cm-c-executing-queries.md)。
![\[根据用户组和查询组分配给队列的查询示例列表。\]](http://docs.aws.amazon.com/zh_cn/redshift/latest/dg/images/queues-assignment-2.png)
在本示例中，WLM 进行以下分配：
1. 第一组语句介绍将用户分配给用户组的三种方式。这些语句由用户 `adminuser` 运行，该用户不是任何 WLM 队列中所列用户组的成员。未设置任何查询组，因此，系统将这些语句路由到默认队列。
1. 用户 `adminuser` 是超级用户，查询组设置为 `'superuser'`，因此，该查询分配给超级用户队列。
1. 为用户 `test_user` 分配了队列 1 中所列的角色 `test_db_rw`，因此，该查询分配给队列 1。
1. 用户 `admin1` 是队列 1 中所列用户组的成员，因此，该查询分配给队列 1。
1. 用户 `vp1` 不是任何所列用户组的成员。查询组设置为 `'QG_B'`，因此，该查询分配给队列 2。
1. 用户 `analyst1` 是队列 3 中所列用户组的成员，但 `'QG_B'` 匹配队列 2，因此，该查询分配给队列 2。
1. 用户 `ralph` 不是任何所列用户组的成员，且查询组被重置，因此，不存在任何匹配队列。该查询分配给默认队列。
# 为队列分配查询
使用 Amazon Redshift，您可以管理工作负载并发性，并通过将查询分配到队列来确定查询的优先级。队列允许您为不同类型的查询或用户分配内存和 CPU 等资源，确保关键查询优先于不太重要的查询。以下各节将介绍如何创建队列、配置队列属性以及根据定义的标准分配传入查询。
以下示例根据用户角色、用户组和查询组向队列分配查询。
## 根据用户角色为队列分配查询
如果为用户分配某个角色，并且该角色附加到队列，则该用户运行的查询将分配给该队列。以下示例创建了一个名为 `sales_rw` 的用户角色并将用户 `test_user` 分配给该角色。
```
create role sales_rw;
grant role sales_rw to test_user;
```
您还可以通过显式将一个角色授予另一个角色来合并两个角色的权限。为用户分配嵌套角色会向该用户授予这两个角色的权限。
```
create role sales_rw;
create role sales_ro;
grant role sales_ro to role sales_rw;
grant role sales_rw to test_user;
```
要查看集群中已授予角色的用户列表，请查询 SVV\$1USER\$1GRANTS 表。要查看集群中已授予角色的角色列表，请查询 SVV\$1ROLE\$1GRANTS 表。
```
select * from svv_user_grants;
select * from svv_role_grants;
```
## 根据用户组为队列分配查询
如果用户组名称列在队列定义中，则由该用户组的成员运行的查询会分配到相应的队列。下面的示例使用 SQL 命令 [CREATE USER](r_CREATE_USER.md)、[CREATE GROUP](r_CREATE_GROUP.md) 和 [ALTER GROUP](r_ALTER_GROUP.md) 创建用户组并将用户添加到组。
```
create group admin_group with user admin246, admin135, sec555;
create user vp1234 in group ad_hoc_group password 'vpPass1234';
alter group admin_group add user analyst44, analyst45, analyst46;
```
## 为查询组分配查询
您可以通过将查询分配到相应的查询组在运行时向队列分配查询。使用 SET 命令开始使用查询组。
```
SET query_group TO group_label
```
其中，*`group_label`* 是 WLM 配置中列出的查询组标签。
在 `SET query_group` 命令之后运行的所有查询都以指定查询组的成员身份运行，直到您重置查询组或结束当前登录会话为止。有关设置和重置 Amazon Redshift 对象的信息，请参阅“SQL 命令参考”中的 [SET](r_SET.md) 和 [RESET](r_RESET.md)。
您指定的查询组标签必须包含在当前 WLM 配置中；否则，*SET query\$1group* 命令对查询队列不起作用。
查询日志会捕获在 TO 子句中定义的标签，因此，您可以利用标签进行故障排除。有关 query\$1group 配置参数的信息，请参阅“配置参考”中的 [query\$1group](r_query_group.md)。
下面的示例将两个查询作为查询组“priority”的一部分运行，然后重置查询组。
```
set query_group to 'priority';
select count(*)from stv_blocklist;
select query, elapsed, substring from svl_qlog order by query desc limit 5;
reset query_group;
```
## 为超级用户队列分配查询
要向超级用户队列分配查询，请以超级用户身份登录 Amazon Redshift，然后在超级用户组中运行查询。完成后，重置查询组，使后续查询不会在超级用户队列中运行。
下面的示例分配两个命令以在超级用户队列中运行。
```
set query_group to 'superuser';
analyze;
vacuum;
reset query_group;
```
要查看超级用户的列表，请查询 PG\$1USER 系统目录表。
```
select * from pg_user where usesuper = 'true';
```
# WLM 动态和静态配置属性
WLM 配置属性可以是动态的，也可以是静态的。您可以将动态属性应用于数据库而无需重新启动集群，但静态属性需要重新启动集群才能够使更改生效。不过，如果您同时更改动态属性和静态属性，则必须重新启动集群才能使所有属性更改生效。无论更改的属性是动态还是静态的，都是如此。
在应用动态属性时，您的集群状态是 `modifying`。在自动 WLM 与手动 WLM 之间切换是一项静态更改，需要重启集群才能生效。
下表显示使用自动 WLM 或手动 WLM 时哪些 WLM 属性是动态的或静态的。
****
| WLM 属性 | 自动 WLM | 手动 WLM |
| --- | --- | --- |
| 查询组 | 动态 | 静态 |
| 查询组通配符 | 动态 | 静态 |
| 用户组 | 动态 | 静态 |
| 用户组通配符 | 动态 | 静态 |
| 用户角色 | 动态 | 静态 |
| 用户角色通配符 | 动态 | 静态 |
| 主要并发 | 不适用 | 动态 |
| 并发扩展模式 | 动态 | 动态 |
| 启用短查询加速 | 不适用 | 动态 |
| 短查询的最大运行时间 | 动态 | 动态 |
| 要使用的内存的百分比 | 不适用 | 动态 |
| 超时 | 不适用 | 动态 |
| 优先级 | 动态 | 不适用 |
| 添加或移除队列 | 动态 | 静态 |
如果您添加查询监控规则（QMR），或者修改或删除现有 QMR，则无需重新启动集群即可自动发生更改。
**注意**
使用手动 WLM 时，如果更改了超时值，则新值将应用于更改值之后开始执行的所有查询。如果更改了要使用的并发性或内存百分比，则 Amazon Redshift 将动态更改为新的配置。这样，当前运行的查询不会受到更改的影响。有关更多信息，请参阅 [WLM 动态内存分配](https://docs.aws.amazon.com/redshift/latest/dg/cm-c-wlm-dynamic-memory-allocation.html)。
**Topics**
+ [WLM 动态内存分配](cm-c-wlm-dynamic-memory-allocation.md)
+ [动态 WLM 示例](cm-c-wlm-dynamic-example.md)
# WLM 动态内存分配
在每个队列中，WLM 创建与队列的并发级别相等的查询槽数目。分配到查询槽的内存量等于分配到队列的内存百分比除以槽数。如果您更改内存分配或并发性，Amazon Redshift 会动态管理转变到新 WLM 配置的过程。因此，活动的查询可以使用当前分配的内存量运行直至完成。与此同时，Amazon Redshift 确保总内存使用率不超过可用内存的 100%。
工作负载管理器使用下面的流程管理过渡：
1. WLM 重新计算针对每个新查询槽的内存分配。
1. 如果正在运行的查询未主动使用某个查询槽，则 WLM 删除该槽，使这些内存可供新的槽使用。
1. 如果主动使用某个查询槽，则 WLM 等待查询完成。
1. 活动查询完成后，会删除空槽，释放关联的内存。
1. 因为有充足的内存可供添加一个或多个槽，所以会添加新的槽。
1. 发生更改时正在运行的所有查询完成之后，槽数等于新的并发级别，完成到新的 WLM 配置的过渡。
实际上，发生更改时正在运行的查询将继续使用原始内存分配。对于发生更改时排队中的查询，当有新的槽可用时将路由到这些槽。
如果 WLM 动态属性在过渡期间发生更改，则 WLM 立即开始过渡到新的配置（从当前状态开始）。要查看过渡的状态，请查询 [STV\$1WLM\$1SERVICE\$1CLASS\$1CONFIG](r_STV_WLM_SERVICE_CLASS_CONFIG.md) 系统表。
# 动态 WLM 示例
借助 Amazon Redshift，您可以使用动态 WLM（工作负载管理）自动管理 Amazon Redshift 集群的工作负载分配和资源分配。动态 WLM 是工作负载管理（WLM）配置的一个示例，可根据工作负载需求动态调整内存分配，从而实现最佳并发性和性能。下一节将详细介绍如何为 Amazon Redshift 集群实施和配置动态 WLM。
假定您的集群 WLM 使用了以下动态属性配置了两个队列。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/redshift/latest/dg/cm-c-wlm-dynamic-example.html)
现在，假定集群有 200 GB 内存可用于查询处理。（此数字是随机的，只是为了演示目的。） 如下面的等式所示，每个槽分配 25 GB 内存。
```
(200 GB * 50% ) / 4 slots = 25 GB
```
接下来，将 WLM 更改为使用以下动态属性。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/redshift/latest/dg/cm-c-wlm-dynamic-example.html)
如下面的等式所示，队列 1 中每个槽的新内存分配为 50 GB。
```
(200 GB * 75% ) / 3 slots = 50 GB
```
假定在应用新配置时，查询 A1、A2、A3、A4 正在运行，查询 B1、B2、B3、B4 正在排队。WLM 动态重新配置查询槽，如下所示。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/redshift/latest/dg/cm-c-wlm-dynamic-example.html)
1. WLM 重新计算每个查询槽的内存分配。最初，队列 1 分配 100 GB 内存。新的队列总共分配 150 GB 内存，因此，新队列立即有 50 GB 内存可用。队列 1 现在使用四个槽，新的并发级别为三个槽，因此，不添加任何新槽。
1. 当某个查询完成时，该槽被删除并释放 25 GB 内存。队列 1 现有三个槽和 75 GB 可用内存。新配置需要为每个槽分配 50 GB 内存，但新的并发级别为三个槽，因此不添加任何新的槽。
1. 当第二个查询完成时，其槽被删除并释放 25 GB 内存。队列 1 现有两个槽和 100 GB 可用内存。
1. 使用 50 GB 可用内存添加新槽。队列 1 现有三个槽和 50 GB 可用内存。排队的查询现在可路由到新的槽。
1. 在第三个查询完成时，其槽被删除并释放 25 GB 内存。队列 1 现有两个槽和 75 GB 可用内存。
1. 使用 50 GB 可用内存添加新槽。队列 1 现有三个槽和 25 GB 内存。排队的查询现在可路由到新的槽。
1. 当第四个查询完成时，其槽被删除并释放 25 GB 内存。队列 1 现有两个槽和 50 GB 可用内存。
1. 使用 50 GB 可用内存添加新槽。队列 1 现有三个槽，每个槽有 50 GB 内存，所有可用内存均已分配。
过渡完成，所有查询槽都可用于排队的查询。
# WLM 查询监控规则
在 Amazon Redshift 工作负载管理 (WLM) 中，查询监控规则为 WLM 查询定义基于指标的性能界限，并指定在查询超出这些界限时需要采取的操作。例如，对于短时间运行查询专用的队列，您可创建取消运行超过 60 秒的查询的规则。要跟踪设计不佳的查询，您可创建记录包含嵌套循环的查询的其他规则。
您将在工作负载管理 (WLM) 配置中定义查询监控规则。您最多可以为每个队列定义 25 个规则，而且所有队列的限制为 25 个规则。每个规则最多包括三个条件 (即，谓词) 和一个操作。*谓词* 包含指标、比较条件（=、< 或 >）和值。如果满足任何规则的所有谓词，则会触发该规则的操作。可能的规则操作有 log、hop 和 abort，如以下所讨论的。
某个给定队列中的规则只能应用于在该队列中运行的查询。各个规则彼此独立。
WLM 每 10 秒评估一次指标。当查询被自动重写时，Amazon Redshift 会在子查询级别应用查询监控规则。如果在同一时段内触发了多条规则，WLM 会选择具有最严重操作的规则。如果两条规则的操作具有相同的严重性，WLM 会根据规则名称按字母顺序运行规则。如果操作为 hop 或 abort，则将记录操作且从队列中移出查询。如果操作为 log，则查询将继续在队列中运行。WLM 针对每个规则的每个查询仅启用一个 log 操作。如果队列中包含其他规则，这些规则将保持有效。如果操作为 hop 且将查询路由到其他队列，则将应用新队列的规则。有关对特定查询执行的查询监控和跟踪操作的更多信息，请参阅[短查询加速](wlm-short-query-acceleration.md)中的示例集。
当满足规则的所有谓词时，WLM 会在 [STL\$1WLM\$1RULE\$1ACTION](r_STL_WLM_RULE_ACTION.md) 系统表中写入一行。此外，Amazon Redshift 会将当前运行的查询的查询指标记录到 [STV\$1QUERY\$1METRICS](r_STV_QUERY_METRICS.md)。已完成的查询的指标存储在 [STL\$1QUERY\$1METRICS](r_STL_QUERY_METRICS.md) 中。
**注意**
对于 Amazon Redshift Serverless，您可以使用 `wlm_json_configuration` 参数来配置查询队列和监控规则。这样，您就可以创建具有不同用户角色、查询组和监控规则的多个队列。有关配置无服务器查询队列的更多信息，请参阅《Amazon Redshift 管理指南》**中的[设置查询队列](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-workgroup-query-queues.html)。
## 定义查询监控规则
您创建作为您的 WLM 配置的一部分的查询监控规则，您可将该规则定义为您集群的参数组定义的一部分。
您可使用 AWS 管理控制台或以编程方式使用 JSON 来创建规则。
**注意**
如果您选择以编程方式创建规则，强烈建议您使用控制台生成包含在参数组定义中的 JSON。有关更多信息，请参阅《Amazon Redshift 管理指南》**中的[创建查询监控规则](https://docs.aws.amazon.com/redshift/latest/mgmt/parameter-group-modify-qmr-console.html)和[使用 AWS CLI 配置参数值](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-parameter-groups.html#configure-parameters-using-the-cli)。
要定义查询监控规则，您要指定以下元素：
+ 一个规则名称 – 规则名称必须在 WLM 配置内是唯一的。规则名称最多可包含 32 个字母数字字符或下划线，且不能包含空格或引号。您可以让每个队列有最多 25 个规则，并且所有队列的总限制为 25 个规则。
+ 一个或多个谓词 – 您最多可以为每个规则设置三个谓词。如果满足任何规则的所有谓词，则会触发关联操作。谓词由指标名称、运算符（=、< 或 >）和值定义。示例是 `query_cpu_time > 100000`。有关指标列表以及不同指标值的示例，请参阅本部分中后面的[预置的 Amazon Redshift 的查询监控指标](#cm-c-wlm-query-monitoring-metrics)。
+ 操作 – 如果触发了多个操作，则 WLM 会选择具有最严重操作的规则。可能的操作 (按严重性的升序顺序) 包括：
+ Log – 记录有关 STL\$1WLM\$1RULE\$1ACTION 系统表中查询的信息。在您想要仅写入日志记录时使用 Log 操作。WLM 针对每个规则的每个查询最多创建一个日志。log 操作后，其他规则将保持有效且 WLM 将继续监控查询。
+ Hop（仅适用于手动 WLM）– 记录操作，并让查询跳到下一个匹配的队列中。如果没有其他匹配的队列，则会取消查询。QMR 仅跳过 [CREATE TABLE AS](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_TABLE_AS.html) (CTAS )语句和只读查询，例如 SELECT 语句。有关更多信息，请参阅 [WLM 查询队列跳过](wlm-queue-hopping.md)。
+ 中止 – 记录操作并取消查询。QMR 不会停止 COPY 语句和维护操作，例如 ALTER、ANALYZE 和 VACUUM。
+ 更改优先级（仅适用于自动 WLM）– 更改查询的优先级。
要限制查询的运行时，我们建议您创建查询监控规则，而不是使用 WLM 超时。例如，您可以将 `max_execution_time` 设置为 50,000 毫秒，如以下 JSON 代码段所示。
```
"max_execution_time": 50000
```
但我们建议您定义一个等效的查询监控规则。下面的示例演示了将 `query_execution_time` 设置为 50 秒的查询监控规则：
```
"rules":
[
{
"rule_name": "rule_query_execution",
"predicate": [
{
"metric_name": "query_execution_time",
"operator": ">",
"value": 50
}
],
"action": "abort"
}
]
```
有关创建或修改查询监控规则的步骤，请参阅《Amazon Redshift 管理指南》**中的[创建查询监控规则](https://docs.aws.amazon.com/redshift/latest/mgmt/parameter-group-modify-qmr-console.html)和 [wlm\$1json\$1configuration 参数中的属性](https://docs.aws.amazon.com/redshift/latest/mgmt/workload-mgmt-config.html#wlm-json-config-properties)。
您可以在以下主题中找到有关查询监控规则的更多信息：
+ [预置的 Amazon Redshift 的查询监控指标](#cm-c-wlm-query-monitoring-metrics)
+ [查询监控规则模板](#cm-c-wlm-query-monitoring-templates)
+ [创建查询监控规则](https://docs.aws.amazon.com/redshift/latest/mgmt/parameter-group-modify-qmr-console.html)
+ [配置工作负载管理](https://docs.aws.amazon.com/redshift/latest/mgmt/workload-mgmt-config.html)
+ [查询监控规则的系统表和视图](#cm-c-wlm-qmr-tables-and-views)
## 预置的 Amazon Redshift 的查询监控指标
下表描述了查询监控规则中使用的指标。(这些指标与存储在 [STV\$1QUERY\$1METRICS](r_STV_QUERY_METRICS.md) 和 [STL\$1QUERY\$1METRICS](r_STL_QUERY_METRICS.md) 系统表中的指标不同。)
对于某个给定指标，将在查询级别或段级别跟踪性能阈值。有关段和步骤的更多信息，请参阅[查询计划和执行工作流程](c-query-planning.md)。
**注意**
[WLM 超时](cm-c-defining-query-queues.md#wlm-timeout) 参数与查询监控规则不同。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/redshift/latest/dg/cm-c-wlm-query-monitoring-rules.html)
**注意**
`query_queue_time` 谓词不支持跳转操作。也就是说，在满足 `query_queue_time` 谓词时，将忽略定义了跳转的规则。
较短的段执行时间可能会导致某些指标（例如 `io_skew` 和 `query_cpu_usage_percent`）出现采样错误。为避免或减少采样错误，请在规则中包括段执行时间。`segment_execution_time > 10` 是一个好起点。
[SVL\$1QUERY\$1METRICS](r_SVL_QUERY_METRICS.md) 视图显示已完成查询的指标。[SVL\$1QUERY\$1METRICS\$1SUMMARY](r_SVL_QUERY_METRICS_SUMMARY.md) 视图显示已完成查询的指标的最大值。使用这些视图中的值帮助确定用于定义查询监控规则的阈值。
## 查询 Amazon Redshift Serverless 的监控指标
下表描述了为 Amazon Redshift Serverless 查询监控规则中使用的指标。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/redshift/latest/dg/cm-c-wlm-query-monitoring-rules.html)
**注意**
`max_query_queue_time` 谓词不支持跳转操作。也就是说，在满足 `max_query_queue_time` 谓词时，将忽略定义了跳转的规则。
较短的段执行时间可能会导致某些指标（例如 `max_io_skew` 和 `max_query_cpu_usage_percent`）出现采样错误。
对于 Amazon Redshift Serverless，您可以使用 `wlm_json_configuration` 参数来配置查询队列和监控规则。这样，您就可以使用上面所列的指标，创建具有不同用户角色、查询组和监控规则的多个队列。有关配置无服务器查询队列的更多信息，请参阅《Amazon Redshift 管理指南》**中的 [WLM JSON 配置结构](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-workgroup-query-queues.html#serverless-wlm-json-configuration)。
## 查询监控规则模板
当您使用 Amazon Redshift 控制台添加规则时，可以选择从预定义的模板中创建规则。Amazon Redshift 将创建具有一组谓词的新规则，并使用默认值填充这些谓词。默认操作是 log。您可以修改这些谓词和操作以满足您的使用案例。
下表列出了可用的模板。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/redshift/latest/dg/cm-c-wlm-query-monitoring-rules.html)
## 查询监控规则的系统表和视图
当满足规则的所有谓词时，WLM 会在 [STL\$1WLM\$1RULE\$1ACTION](r_STL_WLM_RULE_ACTION.md) 系统表中写入一行。此行包含规则所触发查询的详细信息以及所导致的操作。
此外，Amazon Redshift 还将查询指标记录到以下系统表和视图中。
+ [STV\$1QUERY\$1METRICS](r_STV_QUERY_METRICS.md) 表显示当前正在运行的查询的指标。
+ [STL\$1QUERY\$1METRICS](r_STL_QUERY_METRICS.md) 表记录已完成的查询的指标。
+ [SVL\$1QUERY\$1METRICS](r_SVL_QUERY_METRICS.md) 视图显示已完成查询的指标。
+ [SVL\$1QUERY\$1METRICS\$1SUMMARY](r_SVL_QUERY_METRICS_SUMMARY.md) 视图显示已完成查询的指标的最大值。
# WLM 系统表和视图
WLM 根据内部定义的 WLM 服务类配置查询队列。Amazon Redshift 根据这些服务类以及在 WLM 配置中定义的队列创建多个内部队列。在系统表中，术语*队列* 和*服务类* 通常可互换使用。超级用户队列使用服务类 5。用户定义的队列使用服务类 6 及更高的服务类。
您可以使用特定于 WLM 的系统表查看查询、队列和服务类的状态。查询以下系统表并注意以下事项：
+ 查看正在跟踪哪些查询，工作负载管理器分配哪些资源。
+ 查看查询被分配到哪个队列。
+ 查看工作负载管理器当前跟踪的查询的状态。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/redshift/latest/dg/cm-c-wlm-system-tables-and-views.html)
您使用任务 ID 来跟踪系统表中的查询。下面的示例介绍如何获取最近提交的用户查询的任务 ID：
```
select task from stl_wlm_query where exec_start_time =(select max(exec_start_time) from stl_wlm_query);
task
------
137
(1 row)
```
下面的示例介绍当前正在各个服务类（队列）中执行或等待的查询。该查询在跟踪 Amazon Redshift 的整体并发工作负载时很有用：
```
select * from stv_wlm_query_state order by query;
xid |task|query|service_| wlm_start_ | state |queue_ | exec_
| | |class | time | |time | time
----+----+-----+--------+-------------+---------+-------+--------
2645| 84 | 98 | 3 | 2010-10-... |Returning| 0 | 3438369
2650| 85 | 100 | 3 | 2010-10-... |Waiting | 0 | 1645879
2660| 87 | 101 | 2 | 2010-10-... |Executing| 0 | 916046
2661| 88 | 102 | 1 | 2010-10-... |Executing| 0 | 13291
(4 rows)
```
## WLM 服务类 ID
下表列出了分配到服务类的 ID 的列表。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/redshift/latest/dg/cm-c-wlm-system-tables-and-views.html)