【翻译】如何在Presto中配置和利用资源组

最新推荐文章于 2024-06-28 14:43:06 发布

吉甫作诵

最新推荐文章于 2024-06-28 14:43:06 发布

阅读量3.1k

点赞数

分类专栏：大数据文章标签： presto 大数据

本文链接：https://blog.csdn.net/fly0512/article/details/105123994

版权

大数据专栏收录该内容

22 篇文章 0 订阅

订阅专栏

Presto资源组是一种准入控制和工作负载管理机制，用于管理资源分配。资源组机制可确保使用超出其分配配额的组受到惩罚，从而防止任何组超过其配额限制。它是一种反应式门控机制，用于在启动新查询之前检查资源组是否已超过其限制。
我们的许多客户都试图使用资源组来进行资源隔离，并且此博客详细解释了资源组不太复杂的情况。例如，一旦查询开始执行，资源组管理器就无法控制该查询。
Presto中的资源组可以像树一样配置，其中非叶组可以进一步细分为多个资源组。

了解CPU和内存的软限制和硬限制

Presto中的资源组定义了CPU使用率的硬限制和硬限制以及内存使用的硬限制（有意思的称为“ softMemoryLimit”）。Presto中的资源组可以基于硬并发参数控制查询调度，该参数可以隔离配置，也可以结合CPU利用率的软限制进行配置。

对于内存，软限制希望属于某个组的查询的汇总内存消耗保持在一定限制内。如果违反了软限制，则在组查询的聚合内存低于软限制之前，无法执行任何新查询。

对于CPU，Presto资源组管理器跟踪特定组执行查询的总秒数。当该值超过阈值（称为“ softCpuLimit”）时，组的最大并发性将线性降低，以便当组的使用率达到另一个阈值（称为“ hardCpuLimit”）时，该值达到零。

对于CPU，资源组还具有cpuQuotaPeriod概念，用于定义实施CPU配额的时间段。如果组的CPU的hardCpuLimit时间为一分钟，配额期限为10分钟，则该组在最近10分钟内使用了超过一分钟的时间，则在重新生成配额之前，无法运行任何查询。CPU配额的重新生成取决于组的cpuHardLimit和cpuQuotaPeriod值。例如，如果cpuQuotaPeriod为100秒（相当于10个CPU内核的执行时间为1000 CPU秒），而cpuHardLimit为500秒，则该组每秒重新生成5个CPU秒的配额。

Presto在内部使用“ usageMillis”跟踪配额。每次查询完成时，系统都会将cpuSeconds添加到该值，并且每过一秒钟便会根据相关组的配额通过减小该值来重新生成该值。

关键配置参数

总结一下，这是一些关键参数，用于配置资源限制和通过资源组的资源分配：

cpuQuotaPeriod：相对于其定义其他CPU配置的时间段。这定义了应用资源组限制的时间段。默认值为一小时。
hardConcurrencyLimit：组在任何给定时间点处于“运行”状态的最大查询数。
softMemoryLimit：一个内存限制，如果超过该限制，将阻止组调度新查询，直到内存使用率值低于 - softMemoryLimit。这可以是绝对值，也可以是集群总内存的百分比。
softCpuLimit，hardCpuLimit：资源组具有配额重新生成的“速率”，组可以在整个群集中使用配额而不会造成损失。惩罚在软限制和硬限制之间线性缩放。
schedulePolicy（可选）：指定如何选择运行队列中的查询以及子组如何有资格开始其查询。它可以是以下三个值之一：
fair (default):：排队的查询先入先出，子组必须轮流开始新查询（如果有排队的话）。
weighted_fair：根据子组的scheduleWeight和已同时运行的查询数选择子组。根据所有当前合格子组的权重，计算子组的运行查询的预期份额。相对于其共享并发性最低的子组被选择以开始下一个查询。
weighted：根据优先级（通过query_priority
会话属性指定）随机选择队列中的查询。选择子组以根据其scheduleWeight启动新查询。
query_priority：所有子组还必须配置有query_priority。排队查询将严格根据其优先级进行选择。

资源组配置示例

让我们从Presto文档中的示例开始。下面的资源组已被修改，以演示用于资源分配的CPU限制的配置。由于与CPU相关的值取决于系统中的内核数（所有工作程序节点上的内核总数），因此，我们假设有10个内核可用于在工作程序节点上执行。因此，每个实时秒总共有10个cpuSeconds的执行时间。

在此示例中，我们假设cpuQuotaPeriod为1小时（这相当于10个CPU小时的执行时间）。如下图所示，已经配置了多个资源组。我们在下面重点介绍其中一些，以演示它们如何控制资源分配。
在这里插入图片描述

Global Group：群集中最多可以同时运行100个查询，并且任何时候最多可以排队1000个查询。总体群集内存利用率不应超过90％。

{  
   “ name”：“ global”，
   “ softMemoryLimit”：“ 90％”，
   “ hardConcurrencyLimit”：100，
   “ maxQueued”：1000，
   “ schedulingPolicy”：“加权”，
   “ jmxExport”：yes，
   “ subGroups”：[..]
}

Data Definition Group：属于该组的查询最多可以有五个并发，并且这些查询将以FIFO顺序运行。该组使用的CPU和内存资源不应超过10％。

{  
   “ name”：“ data_definition”，
   “ softMemoryLimit”：“ 10％”，
   “ hardConcurrencyLimit”：5，
   “ maxQueued”：100，
   “ schedulingWeight”：1，
   “ hardCpuLimit”：“ 1hr”
}

Pipeline Group:以源为“管道”的非DDL查询将在global.pipeline组下运行，总并发度为45，每用户并发度为5个查询。查询以FIFO顺序运行。这些应最多使用总可用CPU资源的50％。这是因为将cpuQuotaPeriod配置为一小时（相当于10个CPU小时的执行时间，而5个小时的hardCpuLimit意味着最多占总可用CPU资源的50％）。

{  
   “ name”：“pipeline”，
   “ softMemoryLimit”：“ 80％”，
   “ hardConcurrencyLimit”：45，
   “ maxQueued”：100，
   “ schedulingWeight”：1，
   “ jmxExport”：yes，
   “ hardCpuLimit”：“ 5hr”，
   “subGroup”：[  
      {  
         “ name”：“ pipeline _ $ {USER}”，
         “ softMemoryLimit”：“ 50％”，
         “ hardConcurrencyLimit”：5，
         “ maxQueued”：100
      }
   ]
}

BI-$toolname Group：每个BI工具有一个资源组。每个工具最多可以运行10个并发查询，每个用户最多可以运行3个查询。如果总需求超过限制10，则运行查询最少的用户将获得下一个并发槽。当订单发生争用时，此策略将导致公平。该组应使用大约40％的可用CPU（10小时的CPU时间中的四个小时），最多使用50％的可用内存。
其余所有查询均放在行为类似的global.adhoc.other下的每个用户组中。

要将查询分配给资源组，Presto具有选择器的概念。每个选择器都指定一组查询属性，例如用户或源。选择器以有序的方式定义，并且其查询符合条件的第一个选择器将分配给该查询。有关选择器规则的更多详细信息，请参见资源组文档。

资源组功能示例

让我们借助该图了解资源组如何限制资源使用。

在这里，我们假设配额再生速率为每秒5个单位。这意味着每过一秒钟，就会从当前消耗的配额值（显示为Total CPUSecs –下图中的绿色曲线）减少5个单位，这相当于重新生成5个配额单位。
为简单起见，在此示例中，假设硬限制和软限制totalAvailableQuota都相同（37个单位）（显示为RG Quota –下图中的红色虚线）。
每秒都会调用一个更新方法，该方法以递归方式遍历资源组结构并更新每个组的资格以启动更多查询。
查询完成后，将从查询的totalAvailableQuota中扣除查询占用的cpuSeconds数量（在下图中显示为Query Cost）。

总结一下，这是上图中使用的关键术语：
Total CPUSECS：资源组的运行CPU利用率。每次查询完成时，我们都会将查询花费的总CPU秒数（查询成本）添加到该查询中。否则，它将以每个时间周期（每秒）的再生速率（在这种情况下为5个单位）降低。
Query Cost：刚刚完成的查询占用的总cpuSeconds。
Quota：水平虚线显示分配给资源组的总配额。一旦某个组的CPU使用率（总CPUSecs）超过配额，该组中任何查询的执行都会被阻止，直到总cpusecs低于配额为止。
BLOCKED：资源组被阻塞，无法开始执行新的查询。

图中的红色块表示资源组由于超出配额而不允许运行更多查询的时间（直到总CPUSeconds低于配额）。

方案1：一个查询

在时间t = 5，针对所考虑的资源组的第一个查询已完成。由于每秒会重新生成五秒钟的配额，因此我们将总的CPU秒数更新为（10 – 5 =）5秒。

在下一个周期中，我们从总的CPU秒数中再次减少5，该秒数变为0并保持为0，直到下一个查询完成。

方案2：大查询完成

时间t = 26时，CPUSeconds总数达到49，并且在CPUSeconds总数不超过配额限制37之前，资源组不允许启动查询。总共需要三个周期（15个单位）将CPUSeconds的总数量限制为quotaLimit。

方案3：连续达到资源组限制

让我们假设从时间t = 30开始每秒完成一次查询，并且队列中有五个查询。红色条表示由于超过总CPU秒数而阻止查询提交时的时间单位。如果我们关注t = 30到t = 38之间的部分，则可以看到存在交替的红色块，因为资源组由于高负载而在运行状态和阻塞状态之间波动。
在t = 31时，totalCPUSecs为34，查询完成，总执行时间为10秒。
在t = 32时，totalCpuSecs变为39，这是因为将10秒添加到查询完成中，并且由于配额重新生成而减去了5秒（34 + 10 – 5）。

结束语

资源组是Presto中控制资源使用和查询调度的重要结构。许多Qubole客户表示有兴趣尝试为其生产工作负载试用资源组，但由于涉及复杂的配置而无法这样做。在此博客文章中，我们讨论了资源组配置和功能的详细信息，以鼓励在生产场景中采用和使用它们。

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

吉甫作诵

关注

0
点赞
踩
4

收藏

觉得还不错? 一键收藏
0
评论
【翻译】如何在Presto中配置和利用资源组

Presto资源组是一种准入控制和工作负载管理机制，用于管理资源分配。资源组机制可确保使用超出其分配配额的组受到惩罚，从而防止任何组超过其配额限制。它是一种反应式门控机制，用于在启动新查询之前检查资源组是否已超过其限制。我们的许多客户都试图使用资源组来进行资源隔离，并且此博客详细解释了资源组不太复杂的情况。例如，一旦查询开始执行，资源组管理器就无法控制该查询。 Presto中的资源组可以像树一样配置，其中非叶组可以进一步细分为多个资源组。
复制链接

扫一扫