查询优先级 - 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 工作负载每六个小时运行一次，分析工作负载全天运行。当只有分析工作负载在集群上运行时，它会使整个系统自身产生高吞吐量和最佳系统利用率。但是，当 ETL 工作负载启动时，它会获得先行权，因为它具有更高的优先级。除了在被接纳之后的优先资源分配之外，作为 ETL 工作负载的一部分运行的查询在被接纳期间也会获得先行权。因此，无论系统上运行的是什么其他内容，ETL 工作负载都可以按预测的方式执行。因此，它提供了可预测的性能，并为管理员提供了为其业务用户提供服务级别协议 (SLA) 的能力。

在给定的集群中，高优先级工作负载的可预测性能是以其他优先级较低的工作负载为代价的。较低优先级的工作负载可能运行时间更长，因为其查询正在等待更重要的查询完成。或者，因为当它们与更高优先级的查询同时运行时，它们获得的资源比例较小，因此运行时间可能较长。较低优先级的查询不会遭受资源匮乏，而是继续以较慢的速度取得进展。

在前面的示例中，管理员可以为分析工作负载启用并发扩展。即使 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"
  }
]

另一个示例是定义一条规则，以将当前优先级为 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_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 查询监控规则。