Presto资源管理之Resource Groups And Selector

文章目录

前言
资源组配置
选择器规则 Selector Rules
全局配置 Global Properties
选择器属性
配置案例
- 配置

prestoDb

前言

资源组对资源使用进行限制，并可以对在其中运行的查询执行队列策略，或将资源分配给子组。查询属于单个资源组，并且从该组（及其祖先）消耗资源。除了排队查询的限制外，当资源组耗尽资源时，不会导致正在运行的查询失败；而是新查询进入排队状态。资源组可以拥有子组或接受查询，但不能两者兼有。

资源组和相关的选择规则是由可插拔的管理器进行配置的。要启用内置的管理器以读取 JSON 配置文件，请添加一个包含以下内容的 etc/resource-groups.properties 文件：

resource-groups.configuration-manager=file
resource-groups.config-file=etc/resource_groups.json

将 resource-groups.config-file 的值更改为指向一个 JSON 配置文件，可以是绝对路径，也可以是相对于 Presto 数据目录的路径

资源组配置

name (必填): 组的名称。可以是一个模板（见下文）。
maxQueued (必填): 最大排队查询数量。一旦达到此限制，新查询将被拒绝。
hardConcurrencyLimit (必填): 最大并发运行查询数量。
softMemoryLimit (必填): 在新查询进入排队状态之前，该组可以使用的分布式内存的最大量。可以指定为绝对值（例如 1GB）或者作为集群内存的百分比（例如 10%）。
softCpuLimit（可选）：在一段时间内（参见cpuQuotaPeriod），该组可使用的最大CPU时间，否则将对最大运行查询数量应用惩罚。还必须指定 hardCpuLimit。
schedulingPolicy（可选）：指定如何选择排队查询来运行，以及子组如何有资格开始查询。可以是三个值之一：
○ 公平（默认）：排队查询先入先出，子组必须轮流启动新查询（如果有任何排队的查询）。
○ weighted_fair：根据子组的计划选择权重和查询，它们已经在并发运行。运行查询的预期份额基于所有当前符合条件的子组的权重来计算子组。子组选择相对于其共享的并发性最小的来启动下一个查询。
○ 加权：排队查询是按优先级随机选择的
（通过query_priority:doc:session属性</sql/set session>指定）。已选择子组
以按其schedulingWeight的比例启动新查询。
○ query_priority：还必须配置所有子组
hardCpuLimit（可选）：在一段时间内，该组可使用的最大 CPU 时间。
schedulingPolicy（可选）：指定如何选择在队列中等待运行的查询，并确定子组何时有资格启动其查询。可以是以下三个值之一：
- fair（默认）：按照先进先出的顺序处理排队的查询，并且子组必须轮流开始新的查询（如果它们有排队的查询）。
- weighted_fair：根据子组的 schedulingWeight 和其当前并发运行的查询数量选择子组。对于所有当前符合条件的子组，根据其权重计算其预期运行查询的份额。选择相对于其份额具有最少并发性的子组来启动下一个查询。
- weighted：按照查询的优先级（通过 query_priority:doc:session 属性 </sql/set-session> 指定）按比例选择排队的查询。按照其 schedulingWeight 按比例选择子组来启动新的查询。
- query_priority：所有子组还必须配置 query_priority。将根据查询的优先级严格选择排队的查询。
schedulingWeight（可选）：该子组的权重。参见上述说明。默认为1。
jmxExport（可选）：如果设置为 true，将导出组统计信息到 JMX 以进行监控。默认为 false。
perQueryLimits（可选）：指定资源组中每个查询可以使用的最大资源量，超过限制将被终止。这些限制不会从父组继承。可以设置三种类型的限制：
- executionTimeLimit（可选）：指定查询可以执行的最长时间的绝对值（例如 1h）。
- totalMemoryLimit（可选）：指定查询可以使用的最大分布式内存的绝对值（例如 1GB）。
- cpuTimeLimit（可选）：指定查询可以使用的最大 CPU 时间的绝对值（例如 1h）。
subGroups（可选）：子组的列表。

请注意，其中必填项的属性，需要在 JSON 配置文件中进行配置。

选择器规则 Selector Rules

user（可选）：用于匹配用户名的正则表达式。
source（可选）：用于匹配来源字符串的正则表达式。
queryType（可选）：用于匹配提交的查询类型的字符串：
- DATA_DEFINITION：用于修改/创建/删除模式/表/视图的元数据以及管理预编译语句、权限、会话和事务的查询。
- DELETE：DELETE 查询。
- DESCRIBE：DESCRIBE、DESCRIBE INPUT、DESCRIBE OUTPUT 和 SHOW 查询。
- EXPLAIN：EXPLAIN 查询。
- INSERT：INSERT 和 CREATE TABLE AS 查询。
- SELECT：SELECT 查询。
clientTags（可选）：标签列表。为了匹配，此列表中的每个标签都必须在与查询相关联的客户端提供的标签列表中。
group（必需）：这些查询将在其中运行的组。

全局配置 Global Properties

cpuQuotaPeriod（可选）：强制执行 CPU 配额的周期。

选择器按顺序处理，并使用第一个匹配的选择器。

选择器属性

可以按以下方式设置来源名称：

CLI：使用 --source 选项。
JDBC：在 Connection 实例上设置 ApplicationName 客户端信息属性。

可以按以下方式设置客户端标签：

CLI：使用 --client-tags 选项。
JDBC：在 Connection 实例上设置 ClientTags 客户端信息属性。

配置案例

在下面的示例配置中，有几个资源组，其中一些是模板。
模板允许管理员动态构建资源组树。例如，在 pipeline_ ${USER} 组中，$ {USER} 将扩展为提交查询的用户名称。还支持 ${SOURCE}，它将扩展为提交查询的来源。您还可以在来源和用户正则表达式中使用自定义命名变量。

这里有四个选择器，定义了哪些查询在哪些资源组中运行：

第一个选择器匹配来自 bob 的查询，并将其放入 admin 组中。
第二个选择器匹配所有来自包含“pipeline”的来源名称的数据定义（DDL）查询，并将其放入 global.data_definition 组中。这有助于减少这类查询的排队时间，因为预期它们会很快。
第三个选择器匹配来自包含“pipeline”的来源名称的查询，并将其放入全局.pipeline 组下动态创建的每个用户 pipeline 组中。
第四个选择器匹配来自 BI 工具的查询（其来源匹配正则表达式“jdbc#(?<tool_name>.*)”），并且具有客户端提供的标签，这些标签是“hi-pri”的超集。这些查询将被放置在全局.pipeline.tools 组下动态创建的子组中。动态子组将基于从来源的正则表达式中提取的名为 tool_name 的命名变量创建。考虑一个具有来源“jdbc#powerfulbi”、用户“kayla”和客户端标签“hipri”和“fast”的查询。此查询将被路由到 global.pipeline.bi-powerfulbi.kayla 资源组。
最后一个选择器是一个全捕获器，将所有尚未匹配的查询放入每个用户 adhoc 组中。

这些选择器一起实施以下策略：

用户“bob”是管理员，可以同时运行最多 50 个查询。查询将根据用户提供的优先级运行。

对于其余用户：

最多可同时运行 100 个查询。
只能运行最多 5 个带有来源“pipeline”的并发 DDL 查询。查询按照先进先出的顺序运行。
非 DDL 查询将在全局.pipeline 组下运行，总并发数为 45，每用户并发数为 5。查询按照先进先出的顺序运行。
对于 BI 工具，每个工具可以同时运行最多 10 个查询，每个用户可以运行最多 3 个查询。如果总需求超过 10 的限制，具有最少运行查询的用户将获得下一个并发插槽。在竞争情况下，此策略实现公平性。
所有剩余查询将被放入类似的全局.adhoc.other 下的每个用户组中。

配置

{"rootGroups": [{"name": "global","softMemoryLimit": "80%","hardConcurrencyLimit": 100,"maxQueued": 1000,"schedulingPolicy": "weighted","jmxExport": true,"subGroups": [{"name": "data_definition","softMemoryLimit": "10%","hardConcurrencyLimit": 5,"maxQueued": 100,"schedulingWeight": 1},{"name": "adhoc","softMemoryLimit": "10%","hardConcurrencyLimit": 50,"maxQueued": 1,"schedulingWeight": 10,"subGroups": [{"name": "other","softMemoryLimit": "10%","hardConcurrencyLimit": 2,"maxQueued": 1,"schedulingWeight": 10,"schedulingPolicy": "weighted_fair","subGroups": [{"name": "${USER}","softMemoryLimit": "10%","hardConcurrencyLimit": 1,"maxQueued": 100}]},{"name": "bi-${tool_name}","softMemoryLimit": "10%","hardConcurrencyLimit": 10,"maxQueued": 100,"schedulingWeight": 10,"schedulingPolicy": "weighted_fair","subGroups": [{"name": "${USER}","softMemoryLimit": "10%","hardConcurrencyLimit": 3,"maxQueued": 10}]}]},{"name": "pipeline","softMemoryLimit": "80%","hardConcurrencyLimit": 45,"maxQueued": 100,"schedulingWeight": 1,"jmxExport": true,"subGroups": [{"name": "pipeline_${USER}","softMemoryLimit": "50%","hardConcurrencyLimit": 5,"maxQueued": 100}]}]},{"name": "admin","softMemoryLimit": "100%","hardConcurrencyLimit": 50,"maxQueued": 100,"schedulingPolicy": "query_priority","jmxExport": true}],"selectors": [{"user": "bob","group": "admin"},{"source": ".*pipeline.*","queryType": "DATA_DEFINITION","group": "global.data_definition"},{"source": ".*pipeline.*","group": "global.pipeline.pipeline_${USER}"},{"source": "jdbc#(?<tool_name>.*)","clientTags": ["hipri"],"group": "global.adhoc.bi-${tool_name}.${USER}"},{"group": "global.adhoc.other.${USER}"}],"cpuQuotaPeriod": "1h"
}