34

技术资讯 | Presto资源组之快速指南

 4 years ago
source link: https://www.tuicool.com/articles/3IJjUfM
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

2Ubayq7.jpg!web

Presto作为一个大数据场景下的交互式查询引擎，在公司线上已经正常提供一年的查询服务了。
 
从刚开始，仅有国内6台服务器，到现在服务已经覆盖了国内、新加坡和印度三个地区的大部分交互式查询，其中仅国内服务器已经达到了150台。
 
随着用户使用规模的扩大，大家在Presto资源分配方面有一些疑惑，比较有代表性的问题如下：
1.随着Presto使用的业务团队的增多，当有团队A的任务比较重要，不希望执行的时候没有了查询的资源，应该如何重点保证？
 
2.集群资源负载比较高时，我和另外一个同事同时提交了一个查询，一开始我俩都在排队，当有空闲资源时，谁的查询会先获得资源？
 
3.对于Adhoc类型的查询，我不想得喝完咖啡才能拿到结果；而批处理的查询，我明天再拿结果就好，如何根据不同的sql类型，做更合理的资源分配？
今天我们将介绍Presto的资源组机制，一一解答以上的问题。

7jQBnmI.gif

一. 何为Presto资源组 

Presto的资源组机制，是从 资源分配 的角度来控制集群的整体查询负载。

Presto会在集群整体资源下开辟多个资源组，每一个提交的查询都会分配到一个特定的资源组执行。

在特定资源组A开启一个新的查询B之前，会检查当前A的资源负载是否超过了集群给A分配的资源量；如果已经超过了，资源组机制会阻塞新到的查询B，使其处于排队状态甚至直接拒绝。

细说概念：

资源可以分成CPU，内存，带宽，磁盘等维度，Presto资源组中定义了哪些资源？

目前的资源组所控制的主要是 内存 和 CPU 两个维度。

小小疑惑：

资源组是在查询开始之前的控制机制，一旦一个查询已经开始执行了，就不会受资源组的管控了，那岂不是太过于奔放了吗？

其实，这个问题不用担心。Presto除了资源组机制外，还有一些其他的机制 （如最大查询可用内存，最大查询时间等） ；定期检查查询的执行情况，以保证整体集群运行的稳定性。

二. 具体怎么玩？

要想在Presto集群 中使用资源组功能， 我们只需要在Presto Coordinator节点安装目录etc下新建一个文件 resource-groups.json，然后将resource-groups.config-file 指向资源组配置文件的路径，比如：

1.resource-groups.configuration-manager=file 

2.resource-groups.config-file=etc/resource-groups.json

然后在这个json文件中作以下两部分配置即可：

1. 资源组主要配置项 

name （必须） ：

特定资源组名称；

maxQueued （必须） ：

排队任务的最大数量，当达到此阈值后，新的任务将被拒绝；

hardConcurrencyLimit （必须） ：

任何时刻处于"RUNNING"状态的查询的最大数量；

softMemoryLimit （必须） ：

这个资源组最大内存使用量，当达到此阈值后，新任务进入排队。 可以指定为一个绝对值 （如100GB） ，也可以指定对集群内存总量的百分比 （如60%） ；

softCpuLimit （可选） ：

一个周期里可以使用cpu的时间，hardCpuLimit也必须指定， 在达到该阈值后，该资源组内占据最大CPU资源的查询的CPU资源会被减少；

hardCpuLimit （可选） ：

一个周期里可以使用的cpu时间，在达到该阈值后，新的查询会进行排队而非直接执行；

schedulingPolicy （可选）  ：

指定查询从排队到运行状态的调度策略。 

【这里解决用户问题2，参照不同的调度策略，可能会有不同的资源分配顺序】

主要有以下 类型 ：

fair （default） ：

当一个资源组下，有几个子资源组都同时有排队的查询，这些子资源组间按照定义的顺序，轮流获得资源，同一个子资源组的查询按照先来先执行的规则获取资源；

weighted_fair：

采取这种策略的每一个资源组会配置一个属性schedulingWeight，每个子资源组会计算一个比值：

当前子资源组查询数量/schedulingWeight，比值越小的子资源组越先得到资源；

weighted： 

默认值为1，子资源组的schedulingWeight越大，越先得到资源；

query_priority：

所有的子资源组都要配置为 query_priority ，排队的查询严格按照指定的query_priority大小顺序来进行获取资源。

2. 资源组选择器 

user （可选） ：

匹配用户名；

source （可选） ：

匹配连接源，如cli、jdbc、pyhive等；

queryType （可选） ：

匹配任务类型；  

clientTags （可选） ：

tag列表，每个tag必须在用户提交任务的tag列表里； 

group （必须） ：

这些任务运行的组。

【这里解决用户问题3，可以对不同的查询类型queryType，比如EXPLAIN、INSERT、SELECT和DATA_DEFINITION等类型，匹配到不同的资源组，分配不同的资源，来执行查询】

三. 举一个栗子

为了加深大家的理解，参照Presto官网的资源组栗子可做以下简单图描述:

https://prestosql.io/docs/current/admin/resource-groups.html

eAJn2yQ.png!web

1.对于global资源组而言，最多可同时运行100个查询，有1000查询处于排队状态，在它下面有三个子资源组：data_definition、adhoc 和 pipeline；

2.pipeline资源组下每一个用户最多可同时运行5个查询，占用pipeline资源组50%的内存资源，其组内默认采用fair的调度策略，所以是按照先来先执行的顺序执行；

3.为了充分利用集群资源，各个子资源组的内存配额的总和可大于父资源组，比如global资源组 (80%) +admin (100%) =180%>100% 。

【这里解决用户问题1，当我们保证子资源组的占比和小于等于100%时，可保证某一个队列的资源总是有的，不被其他资源组抢占，类似静态化分资源】

再来看看 资源组选择器

7FviQzY.png!web

1.如上每一个大括号代表一个匹配资源组的选择器selector，这里一共配置了5个选择器以匹配上面的 5个资源组 ：

admin

global.data_definition

global.pipeline.pipeline_${USER}、global.adhoc.bi-${toolname}.${USER

global.adhoc.other.${USER}

2.要全部满足当前selector全部条件，才可放进当前队列执行。

比如amy用户使用jdbc方式提交的查询，如果没有配置clientTags，是不能够分配到资源组global.adhoc.bi-${toolname}.${USER}对应的资源；

3.当一个查询能同时满足两个seletor时，会匹配第一个满足要求的seletor。

比如bob用户提交一个source为pipeline的DATA_DEFINITION类型的job，只会匹配到资源组admin对应的资源，而非global.data_definition对应的资源；

4.当前4个seletor都没有匹配上，

会使用最后一个seletor指定的资源组global.adhoc.other.${USER}的资源。

该资源组相当于起到一个默认资源组的作用，如果没有设置默认资源组，而又不符合其他资源组选择器条件则会被拒绝执行。

四. 小结 

Presto资源组可认为是实现了一个 弱资源限制 和 隔离 功能。

我们可以为每个资源组指定队列大小、并发大小、内存使用大小以及CPU资源量。加深对资源组的理解，为每个资源组设置合理的资源参数，一方面可以降低不同业务之间的影响，另一方面也有助于系统减少OOM问题。

参考文献：

https://prestosql.io/docs/current/admin/resource-groups.html

https://www.qubole.com/blog/configure-leverage-resource-groups-in-presto/

投稿 | 数据中台

编辑 | sea

排版 | sea

eIjYBzV.gif

J3IZbi7.jpg!web

r6zY3yR.gif

在看点一下 大家都知道


report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK