码迷,mamicode.com
首页 > 其他好文 > 详细

Presto安装完成之后需要做的

时间:2019-07-23 22:38:25      阅读:145      评论:0      收藏:0      [点我收藏+]

标签:resources   exp   动态获取   时间   oca   code   下场   mys   二次   

Presto因其优秀的查询速度被我们所熟知,它本身基于MPP架构,可以快速的对Hive数据进行查询,同时支持扩展Connector,目前对Mysql、MongoDB、Cassandra、Hive等等一系列的数据库都提供了Connector进行支持。是我们常用的SQL on Hadoop的解决方案。那么我们今天就来看一下,当我们选择Presto作为我们的查询引擎之后,我们需要考虑的问题。

Presto 性能调优和稳定性

Presto 存在的问题

  1. Coordinator单点问题(常见方案:ip漂移、nginx代理动态获取等)
  2. 大查询容易OOM(0.186+版本支持dump到磁盘 未验证)
  3. 没有容错能力,无重试机制
  4. Presto部署环境复杂,MPP架构容易受到单台机器影响
  5. Presto并发能力不足

调优策略

  1. 部署多台Coordinator避免单点问题,上层封装一层查询服务 避免jdbc直连
  2. 如果有必要在查询服务进行重试操作(需要判断任务状态)
  3. 对worker相关内存参数进行合理配置,避免OOM
  4. 启用Presto本身资源队列的同时,构建符合业务场景的查询队列,控制并发量及查询优先级,确保任务高效完成
  5. 开发Presto监控系统,监测Presto集群状态,及时预警。动态调整Presto集群规模

内存调优

Presto分为三类内存池,分别为GENERAL_POOL、RESERVED_POOL、SYSTEM_POOL。

SYSTEM_POOL是系统预留内存,worker初始化和执行任务必要的内存,默认为Xmx0.4 也可由resources.reserved-system-memory指定 RESERVED_POOL是最大查询内存,Presto会将当前好用内存最大的query切到该内存区域,默认为Xmx0.1 由query.max-memory-per-node配置
GENERAL_POOL其他查询内存,即除最大查询外其他query的查询内存,大小为Xmx-SYSTEM_POOL-RESERVED_POOL

整体内存配置受以下场景的影响:

  1. 用户查询数据量、复杂性(决定该用多大的查询内存)
  2. 用户查询的并发度(决定该用多大的jvm堆)

需要注意的是:单纯的增大RESERVED_POOL的值并不能解决Presto的查询问题,因为RESERVED_POOL大部分时间是不参与计算的,只有满足以下情景才会被使用,而且只能被一个Query所使用。

  1. GENERAL_POOL有节点出现阻塞节点的情况,即内存不足
  2. RESERVED_POOL没有被使用

所以三者需要配置合理的值,如果并发比较大需要SYSTEM_POOL保持默认或者稍微再大一点,RESERVED_POOL可以稍微增大到八分之一左右。

同时对于jvm OOM的问题,需要对Presto的jvm.config进行配置:

-XX:G1ReservePercent=15
-XX:InitiatingHeapOccupancyPercent=40
-XX:ConcGCThreads=8

Presto监控

Presto自带的监控页面只能显示当前Presto集群的状态和最近的部分查询,不能满足需求。需要对查询相关信息进行数据采集:

  1. 查询基本信息(状态、内存使用、总时间、错误信息等)
  2. 查询性能信息(每一步的时间、数据输入输出数据量信息等,包括stage详情和stage下task的详情)
  3. 异常预警

Presto后续优化

  1. 控制分区表最大查询分区数量限制
  2. 控制单个查询生成的split数量上限,防止计算资源大量消耗
  3. 自动发现并杀死长时间运行的查询
  4. Presto查询限流(限制超过xx数据量的查询)
  5. 启用Presto资源队列
  6. 统一查询引擎

Presto当前版本内存限制和管理

单机维度
  1. GENERAL_POOL每次内存申请时,都会判断内存使用量是否超过了最大内存,如果超过了就报错,错误为“Query exceeded local memory limit of x”,这保护了Presto会无限申请内存,只会导致当前查询出错。同时,如果该节点的GENERAL_POOL可使用内存以及可回收内存为0,那么认为该node为Block node。
  2. RESERVED_POOL可以认为是查询最大的SQL,其能满足GENERAL_POOL的内存限制策略,那么肯定会满足RESERVED_POOL的策略(复用了GENERAL_POOL策略)。
  3. RESERVED_POOL目前版本未发现可以限制内存,所以当并发非常高,且scan的数据非常大时,有低概率会引起OOM问题。但是配合Resource Group,内存设置合理,也基本会避免OOM问题。
集群维度

同时满足以下两点时,Presto便认为集群超出要求的内存了:

  • GENERAL_POOL出现阻塞节点(Block node)
  • RESERVED_POOL已经被使用
  • 当判断出集群超出CLuster Memory时,有两种方式管理内存:
  1. 挨个遍历每个查询,判断当前查询占用的总内存是否超过了query.max-memory(config.properties里配置),如果超过了,那么该查询就被failed。
  2. 如果query.max-memory配置的不合理,值非常大,那么可能过了5秒(默认时间)依然不满足第一种情形,那么将会使用第二种方法管理查询。第二种管理方法又分为两种小的管理,根据LowMemoryKillerPolicy来决定Kill查询策略,其分为total-reservation和total-reservation-on-blocked-nodes。配置total-reservation的作用是kill掉所有查询里最费内存的查询;而total-reservation-on-blocked-nodes杀死在内存不足(阻塞)的节点上使用最多内存的查询。
Resource Groups

Resource Groups 可以认为是Presto实现了一个弱资源限制和隔离功能。其可以为每个group指定队列大小、并发大小、内存使用大小。为每个group设置合理的hardConcurrencyLimit(最大并发数)、softMemoryLimit(内存最大使用值)及maxQueued(队列大小)一方面可以使不同业务影响降低,另一方面也大概率避免OOM问题,当然善于运用user及做下二次开发,就可以让Presto支持多用户共用同一分组和权限认证功能。

参考资料:
http://armsword.com/2018/05/22/the-memory-management-and-tuning-experience-of-presto/

欢迎关注我:叁金大数据
技术图片

Presto安装完成之后需要做的

标签:resources   exp   动态获取   时间   oca   code   下场   mys   二次   

原文地址:https://www.cnblogs.com/jixin/p/11234861.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!