桔妹导读:Presto在滴滴内部发展三年,已经成为滴滴内部Ad-Hoc和Hive SQL加速的首选引擎。目前服务6K+用户,每天读取2PB ~ 3PB HDFS数据,处理30万亿~35万亿条记录,为了承接业务及丰富使用场景,滴滴Presto需要解决稳定性、易用性、性能、成本等诸多问题。我们在3年多的时间里,做了大量优化和二次开发,积攒了非常丰富的经验。本文分享了滴滴对Presto引擎的改进和优化,同时也提供了大量稳定性建设经验。
在Presto交流社区,Presto的稳定性问题困扰了很多Presto使用者,包括Coordinator和Worker挂掉,集群运行一段时间后查询性能变慢等。我们在解决这些问题时积累了很多经验,这里说下解决思路和方法。
根据职责划分,Presto分为Coordinator和Worker模块,Coordinator主要负责SQL解析、生成查询计划、Split调度及查询状态管理等,所以当Coordinator遇到OOM或者Coredump时,获取元信息及生成Splits是重点怀疑的地方。而内存问题,推荐使用MAT分析具体原因。如下图是通过MAT分析,得出开启了FileSystem Cache,内存泄漏导致OOM。
通过以上工作,滴滴Presto逐渐接入公司各大数据平台,并成为了公司首选Ad-Hoc查询引擎及Hive SQL加速引擎,下图可以看到某产品接入后的性能提升:
上图可以看到大约2018年10月该平台开始接入Presto,查询耗时TP50性能提升了10+倍,由400S降低到31S。且在任务数逐渐增长的情况下,查询耗时保证稳定不变。
而高性能集群,我们做了很多稳定性和性能优化工作,保证了平均查询时间小于2S。如下图所示:
但是如果看最近一个月的CPU使用率会发现,平均CPU使用率比较低,且波峰在白天10~18点,晚上基本上没有查询,CPU使用率不到5%。如下图所示:
所以,解决晚上资源浪费问题是我们今后需要解决的难题。
同时,为了不与开源社区脱节,我们打算升级PrestoDB 0.215到PrestoSQL 340版本,届时会把我们的Presto on Druid代码开源出来,回馈社区。
关于团队
▬
滴滴大数据架构部 OLAP & 检索平台组负责以 Elasticsearch、Clickhouse、Presto 及 Druid 为代表的 OLAP 引擎的内核级极致优化,为滴滴各个产品线提供稳定可靠的 PB 级海量数据的实时数据分析、日志检索、监控及即席查询服务。
博闻强识,招贤纳士,滴滴用广阔的舞台,在这里,等待你!
扫描了解更多岗位