Presto在软件的探索与实践是怎样的

发布时间:2021-12-27 15:35:55 作者:柒染
来源:亿速云 阅读:201

今天就跟大家聊聊有关Presto在软件的探索与实践是怎样的,可能很多人都不太了解,为了让大家更加了解,小编给大家总结了以下内容,希望大家根据这篇文章可以有所收获。


1. 
Presto简介
1.1 简介

Presto是Facebook开源的MPP(Massive Parallel Processing)SQL引擎,其理念来源于一个叫Volcano的并行数据库,该数据库提出了一个并行执行SQL的模型,它被设计为用来专门进行高速、实时的数据分析。Presto是一个SQL计算引擎,分离计算层和存储层,其不存储数据,通过Connector SPI实现对各种数据源(Storage)的访问。


 1.2 架构

Presto在软件的探索与实践是怎样的

Presto沿用了通用的Master-Slave架构,一个Coordinator,多个Worker。Coordinator负责解析SQL语句,生成执行计划,分发执行任务给Worker节点执行;Worker节点负责实际执行查询任务。Presto提供了一套Connector接口,用于读取元信息和原始数据,Presto 内置有多种数据源,如 Hive、MySQL、Kudu、Kafka 等。同时,Presto 的扩展机制允许自定义 Connector,从而实现对定制数据源的查询。假如配置了Hive Connector,需要配置一个Hive MetaStore服务为Presto提供Hive元信息,Worker节点通过Hive Connector与HDFS交互,读取原始数据。  

 

 
▍1.3 实现低延时原理  

Presto是一个交互式查询引擎,我们最关心的是Presto实现低延时查询的原理,以下几点是其性能脱颖而出的主要原因:




2. 
Presto在滴滴的应用
Presto在软件的探索与实践是怎样的
2.1 业务场景


Presto在软件的探索与实践是怎样的


2.2 业务规模

Presto在软件的探索与实践是怎样的


2.3 业务增长

Presto在软件的探索与实践是怎样的

 

 
2.4 集群部署  
 

 
Presto在软件的探索与实践是怎样的  

     
目前Presto分为混合集群和高性能集群,如上图所示,混合集群共用HDFS集群,与离线Hadoop大集群混合部署,为了防止集群内大查询影响小查询, 而单独搭建集群会导致集群太多,维护成本太高,我们通过指定Label来做到物理集群隔离(详细后文会讲到)。而高性能集群,HDFS是单独部署的,且可以访问Druid, 使Presto 具备查询实时数据和离线数据能力。


2.5 接入方式

二次开发了JDBC、Go、Python、Cli、R、NodeJs 、HTTP等多种接入方式,打通了公司内部权限体系,让业务方方便快捷的接入 Presto 的,满足了业务方多种技术栈的接入需求。

Presto 接入了查询路由 Gateway,Gateway会智能选择合适的引擎,用户查询优先请求Presto,如果查询失败,会使用Spark查询,如果依然失败,最后会请求Hive。在Gateway层,我们做了一些优化来区分大查询、中查询及小查询,对于查询时间小于3分钟的,我们即认为适合Presto查询,比如通过HBO(基于历史的统计信息)及JOIN数量来区分查询大小,架构图见:

Presto在软件的探索与实践是怎样的



3. 
引擎迭代
Presto在软件的探索与实践是怎样的
Presto在软件的探索与实践是怎样的  

我们从2017年09月份开始调研Presto,经历过0.192、0.215,共发布56次版本。而在19年初(0.215版本是社区分家版本),Presto社区分家,分为两个项目,叫PrestoDB和PrestoSQL,两者都成立了自己的基金会。我们决定升级到PrestoSQL 最新版本(340版本)原因是:




4. 
引擎改进
Presto在软件的探索与实践是怎样的
在滴滴内部,Presto主要用于Ad-Hoc查询及Hive SQL查询加速,为了方便用户能尽快将SQL迁移到Presto引擎上,且提高Presto引擎查询性能,我们对Presto做了大量二次开发。同时,因为使用Gateway,即使SQL查询出错,SQL也会转发到Spark及Hive上,所以我们没有使用Presto的Spill to Disk功能。这样一个纯内存SQL引擎在使用过程中会遇到很多稳定问题,我们在解决这些问题时,也积累了很多经验,下面将一一介绍:


4.1 Hive SQL兼容

18年上半年,Presto刚起步,滴滴内部很多用户不愿意迁移业务,主要是因为Presto是ANSI SQL,与HiveQL差距较大,且查询结果也会出现结果不一致问题,迁移成本比较高,为了方便Hive用户能顺利迁移业务,我们对Presto做了Hive SQL兼容。而在技术选型时,我们没有在Presto上层,即没有在Gateway这层做SQL兼容,主要是因为开发量较大,且UDF相关的开发和转换成本太高,另外就是需要多做一次SQL解析,查询性能会受到影响,同时增加了Hive Metastore的请求次数,当时Hive Metastore的压力比较大,考虑到成本和稳定性,我们最后选择在Presto引擎层上兼容。

主要工作:


Hive SQL兼容,我们迭代了三个大版本,目前线上SQL通过率97~99%。而业务从Spark/Hive迁移到Presto后,查询性能平均提升30%~50%,甚至一些场景提升10倍,Ad-Hoc场景共节省80%机器资源。下图是线上Presto集群的SQL查询通过率及失败原因占比,'null' 表示查询成功的SQL,其他表示错误原因:

Presto在软件的探索与实践是怎样的


4.2 物理资源隔离

上文说到,对性能要求高的业务与大查询业务方混合跑,查询性能容易受到影响,只有单独搭建集群。而单独搭建集群导致Presto集群太多,维护成本太高。因为目前我们Presto Coordinator还没有遇到瓶颈,大查询主要影响Worker性能,比如一条大SQL导致Worker CPU打满,导致其他业务方SQL查询变慢。所以我们修改调度模块,让Presto支持可以动态打Label,动态调度指定的 Label 机器。如下图所示:

Presto在软件的探索与实践是怎样的

根据不同的业务划分不同的label,通过配置文件配置业务方指定的label和其对应的机器列表,Coordinator会加载配置,在内存里维护集群label信息,同时如果配置文件里label信息变动,Coordinator会定时更新label信息,这样调度时根据SQL指定的label信息来获取对应的Worker机器,如指定label A时,那调度机器里只选择Worker A 和 Worker B 即可。这样就可以做到让机器物理隔离了,对性能要求高的业务查询既有保障了。  

 

 
▍4.3 Druid Connector  

 
使用 Presto + HDFS 有一些痛点:  

 

 
所以我们在0.215版本实现了Presto on Druid Connector,此插件有如下优点:  

 

 
在PrestoSQL 340版本,社区也实现了Presto on Druid Connector,但是此Connector是通过JDBC实现的,缺点比较明显:  

 

 
详细架构图见:  

 
Presto在软件的探索与实践是怎样的  

 
使用了Presto on Druid后,一些场景,性能提升4~5倍。  

 

 
▍4.4 易用性建设  

 
为了支持公司的几个核心数据平台,包括:数梦、提取工具、数易及特征加速及各种散户,我们对Presto做了很多二次开发,包括权限管理、语法支持等,保证了业务的快速接入。主要工作:  

 

 

 

 

 
  4.5 稳定性建设  

 
Presto在使用过程中会遇到很多稳定性问题,比如Coordinator OOM,Worker Full GC等,为了解决和方便定位这些问题,首先我们做了监控体系建设,主要包括:  

 

 
通过以上功能,在每次出现稳定性问题时,方便我们及时定位问题,包括指标查看及SQL回放等,如下图所示,可以查看某集群的成功及失败SQL数,我们可以通过定义查询失败率来触发报警:  

 
Presto在软件的探索与实践是怎样的  

 

在Presto交流社区,Presto的稳定性问题困扰了很多Presto使用者,包括Coordinator和Worker挂掉,集群运行一段时间后查询性能变慢等。我们在解决这些问题时积累了很多经验,这里说下解决思路和方法。


根据职责划分,Presto分为Coordinator和Worker模块,Coordinator主要负责SQL解析、生成查询计划、Split调度及查询状态管理等,所以当Coordinator遇到OOM或者Coredump时,获取元信息及生成Splits是重点怀疑的地方。而内存问题,推荐使用MAT分析具体原因。如下图是通过MAT分析,得出开启了FileSystem Cache,内存泄漏导致OOM。

 
 
 
Presto在软件的探索与实践是怎样的  

 
这里我们总结了Coordinator常见的问题和解决方法:  

 

 
而Presto Worker主要用于计算,性能瓶颈点主要是内存和CPU。内存方面通过三种方法来保障和查找问题:  

 

 
而Presto Worker常会遇到查询变慢问题,两方面原因,一是确定是否开启了Swap内存,当Free内存不足时,使用Swap会严重影响查询性能。第二是CPU问题,解决此类问题,要善用Perf工具,多做Perf来分析CPU为什么不在干活,看CPU主要在做什么,是GC问题还是JVM Bug。如下图所示,为线上Presto集群触发了JVM Bug,导致运行一段时间后查询变慢,重启后恢复,Perf后找到原因,分析JVM代码,可通过JVM调优或升级JVM版本解决:  

 
Presto在软件的探索与实践是怎样的
这里我们也总结了Worker常见的问题和解决方法:  

 

▍4.6 引擎优化及调研  

 
作为一个Ad-Hoc引擎,Presto查询性能越快,用户体验越好,为了提高Presto的查询性能,在Presto on Hive场景,我们做了很多引擎优化工作,主要工作:  

 

 
18年我们为了提高Presto查询性能,也调研了一些技术方案,包括Presto on Alluxio和Presto on Carbondata,但是这2种方案最后都被舍弃了,原因是:  

 

 

 

 
5.   
总结  
Presto在软件的探索与实践是怎样的  

通过以上工作,滴滴Presto逐渐接入公司各大数据平台,并成为了公司首选Ad-Hoc查询引擎及Hive SQL加速引擎,下图可以看到某产品接入后的性能提升:


Presto在软件的探索与实践是怎样的


上图可以看到大约2018年10月该平台开始接入Presto,查询耗时TP50性能提升了10+倍,由400S降低到31S。且在任务数逐渐增长的情况下,查询耗时保证稳定不变。


而高性能集群,我们做了很多稳定性和性能优化工作,保证了平均查询时间小于2S。如下图所示:


Presto在软件的探索与实践是怎样的




6. 
展望
Presto在软件的探索与实践是怎样的
Presto主要应用场景是Ad-Hoc查询,所以其高峰期主要在白天,如下图所示,是网约车业务下午12-16点的查询,可以看到平均CPU使用率在40%以上。

Presto在软件的探索与实践是怎样的

但是如果看最近一个月的CPU使用率会发现,平均CPU使用率比较低,且波峰在白天10~18点,晚上基本上没有查询,CPU使用率不到5%。如下图所示:


Presto在软件的探索与实践是怎样的

所以,解决晚上资源浪费问题是我们今后需要解决的难题。

看完上述内容,你们对Presto在软件的探索与实践是怎样的有进一步的了解吗?如果还想了解更多知识或者相关内容,请关注亿速云行业资讯频道,感谢大家的支持。

推荐阅读:
  1. ZB 级的大数据探索与应用实践「附 PPT」
  2. DataPipeline丨新型企业数据融合平台的探索与实践

免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。

presto

上一篇:Netty的FastThreadLocal的原理及用法是什么

下一篇:如何利用Github探测发现特斯拉API请求漏洞

相关阅读

您好,登录后才能下订单哦!

密码登录
登录注册
其他方式登录
点击 登录注册 即表示同意《亿速云用户服务条款》