presto-多租户资源管理-阿里云开发者社区

开发者社区> 开发与运维> 正文

presto-多租户资源管理

简介: presto资源管理介绍 oomKiller presto会监控sql整个生命周期资源的使用(mem,cpu),worker也会周期性汇报自身mem使用状况,当worker的free memory降为0及以下时,触发集群oom逻辑。

presto资源管理介绍

oomKiller

presto会监控sql整个生命周期资源的使用(mem,cpu),worker也会周期性汇报自身mem使用状况,当worker的free memory降为0及以下时,触发集群oom逻辑。

  • 正常场景下,ClusterMemoryManger也会周期性检查query 内存使用量,如果超过2TB,直接杀死。
  • oom场景下,lowMemoryKiller 会选择内存使用量最大的query,然后将其杀死。

资源组(resource-group)

可按用户划分资源组,可简化模型,一个组管理一个用户所有查询。 每个 Group 可以自定义了三项数据

  • CpuQuota:使用cpu时间片配额,分软硬限
  • MemoryQuota:使用内存配额,仅有硬限。
  • query并发数:一个组可以并发执行查询个数。

从三个维度限制一个 Group 的最大资源使用量, 同时可以配置一系列的选择器, 每个选择器可以根据请求上下文比如用户名, 来源,客户端tag等信息唯一确定归属于某个 Group, 因此该框架其实是具备提供多租户隔离的能力的.

示例配置


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

presto


执行主要流程:

  • 先判断query属于哪个资源组
  • 看看当前组有没有quota执行该query,有直接运行,没有则塞入队列,等待资源。
  • 执行的query周期性汇报资源使用情况,资源组更新quota,减去已使用部分。当quota减为0了,新进入的查询只能进入等待队列,等待有quota了,被manager调度执行。该资源组处于封禁状态,等待query执行完解禁。
  • mananger轮询有quota的组,调度组里面处于队列中的query。

公平调度

sql调度层面

默认情况下manager采用round-robin公平调度group,当然你也可以配置权重,让一些group得到更多的调度机会。group内部采用fifo方式调度query。group资源如果超阈了,短时间会封禁,不再继续发起query执行,直到先前query执行完。

task执行层面

Presto在每个Worker节点上调度许多并发任务,以实现多租户,并且使用了一个协作的多任务处理模型。任意给定的split只能在一个线程上最多运行1秒钟,之后必须放弃该线程并返回队列中。当输出缓存已满(下游阶段无法足够快地消耗数据),输入缓存为空(上游阶段可能无法足够快地生成数据),或系统内存不足时,本地调度器会在当前任务CPU运行时间(指运行1秒中)到达之前切换到另一个任务。这样释放了那些正在处理split的线程,帮助Presto最大限度的利用CPU,从而适应不同的查询。
当一个split放弃当前的线程时,查询引擎会确定一下个要被执行的task(与一个或多个split相关联)。Presto并没有提前预测完成一个新的查询所需的资源,而只是使用任务的总CPU时间,将一个多级优先队列划分成五个层级。随着task累积的CPU时间越来越多,它将被划分到更高的级别。每个级别都指定了一个可配置的CPU时间。在实际应用中,要在任意负载下公平的协调多任务的处理是相当有挑战性的。不同的split使用的IO和CPU的差异性相当的大,即便在相同的任务中也是如此,而复杂的函数(如正则表达式)相对于其他的split可能会消耗更多的线程时间。而某些Connector不提供异步的API,因此有的工作线程会被保留数分钟。
在处理这些约束条件时,调度程序必须是自适应的。系统提供了低成本的信号量,因此在一个operator中可以暂停长时间的运算。如果operator中的停止时间超过特定的值,调度器会将实际的线程时间计入当前task,并且会暂时调低这个任务将来的执行频率。这种自适应的特性允许我们在Interactive Analytics 以及Batch ETL的案例中处理不同类型的查询,其中presto可以为消耗最低资源的查询提供更高的优先级。我们也可以这样来理解,用户只希望低成本的查询可以被快速执行,而不必担心高成本的查询的运转时间。同时运行更多的查询,即使以牺牲更多上下文切换为代价,也可以减少总的排队时间,因为低成本的查询会被快速的执行并退出。

资源隔离

无资源隔离,worker上的TaskExecutor线程被每个task共享使用。从task视角,底层线程都是共用的,做不到物理意义上的隔离。

结论及潜在问题

资源管理三个核心问题

  • 避免过度分配:

    • presto没有cbo,无法预估一个查询资源使用情况,没法避免过度分配    
  • 资源隔离:一个worker上的任务可能会争夺资源并而相互干扰。如何相互间互不干扰至关重要。

    • presto共享任务线程模式,无法真正意义上做到资源隔离
  • 调度不同的负载:不同用户对DLA使用情况不尽相同,query有大有小,如何让不同负载用户查询得到公平调度。

    • 使用一个用户一个资源组模式,query能得到公平调度,基本不存在大查询饿死小查询问题
    • 当大家共用一个全局资源组,查询是fifo方式调度,查询多的用户是会饿死小用户。

潜在问题

  • presto的资源组管理是一个前置quota检查,执行前无法判断其资源使用情况。放行后,可能是大query,资源不够,这属于过度分配问题。

    • 只在请求提交阶段做了隔离, 且没有预估请求的资源使用量. 即只考虑请求所属 Group 当前的资源占用量是否超限, 未超限则放行, 不考虑放行后未来执行过程中资源使用是否会超限
  • cpu使用是延时反馈, 是在请求结束后再反馈 CPU 使用, 但增加 CPU 资源是实时的
  • 集群资源使用率问题

    • 一个用户对应资源组quota是硬配,不可动态调整,容易导致集群资源使用率低。
    • 如果每个资源组quota配额都很高,超出集群负载,超频调度SQL执行,导致oomkiller频繁杀大sql。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

其他文章