作者简介
张巍,携程技术中心大数据资深研发工程师。2017年加入携程,在大数据平台部门从事基础框架的研发和运维,目前主要负责 Presto,Kylin,StructedStreaming 等大数据组建的运维,优化,设计及调研工作。对资源调度,OLAP引擎,存储引擎等大数据模块有浓厚的兴趣, 对 hdfs,yarn,presto,kylin,carbondata 等大数据组建有相关优化和改造经验。
一、背景介绍
携程作为中国在线旅游的龙头,提供酒店,机票,度假等服务,这些服务的背后是基于各个部门每天对海量数据的分析。
随着业务的不断增长,用户体验的不断提升,每个部门对数据处理的响应时间要求越来越短,对各个部门报表的响应速度要求越来越快,对跨部门的数据交互和查询也越来越紧密,所以需要一个统一的快速查询引擎,且这个查询引擎需要从GB到PB以上的海量数据集中获取有价值的信息。
我们在技术选型上对比了Presto,Spark,Impala等MPP数据库。综合考量框架本身性能和社区活跃程度,最终选择了Presto。
Presto是Facebook开源的MPP数据库,先简单了解下架构图:
它是一个Master-Slave的架构,由下面三部分组成:
Coordinator负责解析SQL语句,生成执行计划,分发执行任务给Worker节点执行。
Discovery Server通常内嵌于Coordinator节点中。
Worker节点负责实际执行查询任务以及负责与HDFS交互读取数据。
Worker节点启动后向DiscoveryServer服务注册,Coordinator从DiscoveryServer获得可以正常工作的Worker节点。如果配置了HiveConnector,需要配置一个Hive MetaStore服务为Presto提供Hive元信息。
二、携程Presto使用的困境
首先来看一下我们2018年前遇到的一些问题。
携程在2014年探索使用Presto去满足用户快速即席查询和报表系统的需求。在2017年末,离线团队接手携程Presto后,发现当时的Presto本身存在一系列问题,那个时候Presto的版本是0.159,也相对较低。
稳定性差
认证不规范
性能浪费
没有监控
三、携程Presto引擎上所做的改进
为了提供稳定可靠的Presto服务,我们在性能,安全,资源管控,兼容性,监控方面都做了一些改动,以下列出一些主要的改进点。
性能方面
安全方面
资源管控方面
兼容性方面
升级之初Presto 的使用场景如图。
对于版本选择,我们关心的几个问题:1)是否很好地解决各类内存泄漏的问题;2)对于查询的性能是否有一定提升。
综上考虑,决定使用0.190版本的Presto作为目标的升级版本。
通过这个版本的升级,结合对Presto的一部分改进,解决了几个主要问题:
在第二个版本中,我们主要解决了以下问题:
这里简单介绍下Kerberos权限替换过程中的一些细节。
Presto的认证流程:
Presto 涉及到认证和权限的部分如上面红色框标注的3个部分,Coordinator, HDFS和Hive Metastore这三块。Coordinator和HDFS这两块是比较完善的,重点讲一下Hive Metastore。
在Kerberos模式下,所有SQL都是用Presto的启动账号访问Hive Metastore,比如使用Hive账号启动Presto,不论是flt账户还是htl账户提交SQL,最终到Hive Metastore层面都是Hive账号,这样权限太大,存在安全风险。我们增加了Presto Hive MetastoreImpresonating机制,这样htl在访问Hive Metastore时使用的是通过Hive账号伪装的htl账户。
新的问题又来了,在认证过程中需要获取Hive的Token, 可是Token反复的获取都需要一次Metastore的交互,这样会给Metastore带来压力。于是我们对Token 做了一个缓存,在其Token有效期内缓存在Presto内存中。
在第三个版本中,我们解决了以下问题:
程序每一分钟从Presto Coordinator采集数据, 分发到多个监听器,同时写入Mysql表。
当前入库5张监控表。
Basic query:查询基本信息(状态,内存使用,总时间消耗,错误信息等)
Query stats:查询性能信息(每一步的时间消耗,数据输入输出量信息等)
Query info:查询客户端参数信息(发起客户的基本信息,参数信息等)
Query stage info:每个查询中所有stage的信息(输入输出量信息,内存使用情况,调用核的数量等)
Query task info:每个stage中所有task的信息(输入输出信息, 内存信息,调用核数等)
基于以上采集的数据,我们会实时生成presto集群的健康报表以及历史运行趋势。这些数据可以用于:
问题追踪
除了健康报表之外,对于查询错误和性能问题,我们提供了详细的历史数据, 运维人员可以通过报表反应出的异常状况做进一步的排查。
通过报表能够发现某个用户查询时出现了外部异常
通过查看异常堆栈,发现查询是由于hive metastore出现短暂重启引起的查询失败。
在Presto升级改进的同时,我们也调研了Presto on Carbondata的使用场景。
当时Carbondata使用的是1.3.0版本。在此基础上:
当前Presto的架构为:
五、携程Presto未来升级方向
架构完善和技术改进
业务方向
下个阶段我们期望的Presto整体架构图:
随着Presto社区的蓬勃发展,最新版本为0.203,其中包含了大量的优化和Bug Fix,希望跟大家一起讨论。
本文分享自微信公众号 - 携程技术中心(ctriptech),作者:张巍
原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。
原始发表时间:2018-07-03
本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。
我来说两句