专栏首页携程技术干货 | 携程Presto技术演进之路

干货 | 携程Presto技术演进之路

作者简介

张巍,携程技术中心大数据资深研发工程师。2017年加入携程,在大数据平台部门从事基础框架的研发和运维,目前主要负责 Presto,Kylin,StructedStreaming 等大数据组建的运维,优化,设计及调研工作。对资源调度,OLAP引擎,存储引擎等大数据模块有浓厚的兴趣, 对 hdfs,yarn,presto,kylin,carbondata 等大数据组建有相关优化和改造经验。

一、背景介绍

携程作为中国在线旅游的龙头,提供酒店,机票,度假等服务,这些服务的背后是基于各个部门每天对海量数据的分析。

随着业务的不断增长,用户体验的不断提升,每个部门对数据处理的响应时间要求越来越短,对各个部门报表的响应速度要求越来越快,对跨部门的数据交互和查询也越来越紧密,所以需要一个统一的快速查询引擎,且这个查询引擎需要从GB到PB以上的海量数据集中获取有价值的信息。

我们在技术选型上对比了Presto,Spark,Impala等MPP数据库。综合考量框架本身性能和社区活跃程度,最终选择了Presto。

Presto是Facebook开源的MPP数据库,先简单了解下架构图:

它是一个Master-Slave的架构,由下面三部分组成:

  • 一个Coordinator节点
  • 一个Discovery Server节点
  • 多个Worker节点

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又OOM了。只能采取重启Presto恢复服务,实际上对于用户来说,系统挂掉是最恶劣的一种体验了。
  • Presto严格的分区类型检查和表类型检查,导致大量用户在Presto上发起的查询以失败告终,对于那些使用老分区重新刷数据的用户简直就是灾难。
  • 一些大数据量的查询经常占用着计算资源,有时运行了2、3个小时,累计生成上百万个split,导致其他小的查询,响应速度受到严重影响。

认证不规范

  • 很早以前,携程在Presto中内部嵌入一个Mysql的驱动, 通过在Mysql表中存放用户账号和密码访问Presto的权限认证。实际上和大数据团队整体使用Kerberos的策略格格不入。

性能浪费

  • 所有的join查询默认都是使用Broadcast join,用户必须指定join模式才能做到Broadcast join 和 Map join的切换。
  • 数据传输过程中并没有做压缩,从而带来网络资源的极大浪费。

没有监控

  • Presto自身没有监控分析系统,只能通过Presto自身提供的短时监控页面看到最近几分钟的用户查询记录,对分析和追踪历史错误查询带来很大的不便。
  • 无法知道用户的查询量和用户的查询习惯,从而无法反馈给上游用户有效的信息,以帮助应用层开发人员更合理的使用Presto引擎。

三、携程Presto引擎上所做的改进

为了提供稳定可靠的Presto服务,我们在性能,安全,资源管控,兼容性,监控方面都做了一些改动,以下列出一些主要的改进点。

性能方面

  • 根据Hive statistic信息,在执行查询之前分析hive扫描的数据,决定join查询是否采用Broadcast join还是map join。
  • Presto Page在多节点网络传输中开启压缩,减少Network IO的损耗,提高分布计算的性能。
  • 通过优化Datanode的存储方式,减少presto扫描Datanode时磁盘IO带来的性能影响。
  • Presto自身参数方面的优化。

安全方面

  • 启用Presto Kerberos模式,用户只能通过https安全协议访问Presto。
  • 实现Hive Metastore Kerberos Impersonating 功能。
  • 集成携程任务调度系统(宙斯)的授权规则。
  • 实现Presto客户端Kerberos cache模式,简化Kerberos访问参数,同时减少和KDC交互。

资源管控方面

  • 控制分区表最大查询分区数量限制。
  • 控制单个查询生成split数量上限, 防止计算资源被恶意消耗。
  • 自动发现并杀死长时间运行的查询。

兼容性方面

  • 修复对Avro格式文件读取时丢失字段的情况。
  • 兼容通过Hive创建 view,在Presto上可以对Hive view 做查询。(考虑到Presto和Hive语法的兼容性,目前能支持一些简单的view)。
  • 去除Presto对于表字段类型和分区字段类型需要严格匹配的检测。
  • 修复Alter table drop column xxx时出现ConcurrentModification问题。

四、携程Presto升级之路

升级之初Presto 的使用场景如图。

第一阶段,版本升级

对于版本选择,我们关心的几个问题:1)是否很好地解决各类内存泄漏的问题;2)对于查询的性能是否有一定提升。

综上考虑,决定使用0.190版本的Presto作为目标的升级版本。

通过这个版本的升级,结合对Presto的一部分改进,解决了几个主要问题:

  • Presto内存泄漏问题。
  • Presto读取Avro文件格式存在字段遗漏的问题。
  • Presto语法上无法支持整数类型相乘。

第二阶段,权限和性能优化

在第二个版本中,我们主要解决了以下问题:

  • Kerberos替换Mysql
  • Join模式的自动感知和切换
  • 限流(拒绝返回100万以上数据量的查询)

认证机制

这里简单介绍下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内存中。

第三阶段,资源管控和监控平台

在第三个版本中,我们解决了以下问题:

  • 拦截大量生成split的查询SQL
  • 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 on carbon data 的功能和性能的问题
  • 对比了Presto on carbon data 和Presto on hive,得出结论:Presto on Carbon整体性能和Presto on orc的整体性能相当。同样的数据量Carbon snappy的存储是ORC zlib的六倍,就目前存储吃紧的情况下,不适合使用。
  • 目前仅在线上提供Carbondata 连接器,暂未投入业务使用。

当前Presto的架构为:

五、携程Presto未来升级方向

架构完善和技术改进

  • 启用Presto资源队列,规划通过AppName划分每个资源队列的最大查询并发数, 避免某个应用大量的查询并发同时被Presto执行,从而影响其他的App。
  • 实时告警平台,对于错误的查询,Presto能够实时的发送异常查询到告警平台,帮助运维人员快速响应和发现错误以便及时处理。
  • 统一的查询引擎,统一的查询引擎可以在presto,kylin,hive spark-sql之间匹配最优的查询引擎,做语法转换后路由过去。

业务方向

  • 未来携程内部OLAP报表系统(Art Nova) 会更大范围的采用携程Presto作为用户自定义报表的底层查询引擎,以用来提高报表的响应速度和用户体验。
  • 部分业务部门的vdp也计划调研,实时数据计算采用Presto作为其默认的查询引擎的可能性。

下个阶段我们期望的Presto整体架构图:

六、结束语

随着Presto社区的蓬勃发展,最新版本为0.203,其中包含了大量的优化和Bug Fix,希望跟大家一起讨论。

本文分享自微信公众号 - 携程技术中心(ctriptech),作者:张巍

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2018-07-03

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 干货 | 性能提升400%,ClickHouse在携程酒店数仓的实践

    随着时间推移和业务的快速发展,携程酒店数据累积越来越多。目前流量日数据在3T左右,再加上各种订单、价、量、态等数据更是庞大。现有Hive(Spark引擎)执行速...

    携程技术
  • 干货 | 去哪儿网快速 App 开发及问题解决平台实践

    作者简介 张子天,去哪儿网平台事业部客户端技术总监。2011 年加入去哪儿网,曾担任无线机票 Android 总监、无线架构总监,目前主要负责 Qunar 客户...

    携程技术
  • 干货 | Trip.com 机票React Native整洁架构2.0实践

    2019年上半年携程机票前台团队基于clean architecture思想,结合具体业务特点和复杂度,对App机票查询列表页进行了一次技术重构。重构后的机票列...

    携程技术
  • 惊闻Facebook开源大数据引擎Presto团队正在分裂

    这几天忙着出差,跨大洋的飞又在祖国到处飞。受时差和疲倦双重影响,完全不想更新公众号。但是看到Presto团队正在分裂这个大事件,还是顶着疲倦和时差更新一发。

    用户1564362
  • Presto在滴滴的探索与实践

    桔妹导读:Presto在滴滴内部发展三年,已经成为滴滴内部Ad-Hoc和Hive SQL加速的首选引擎。目前服务6K+用户,每天读取2PB ~ 3PB HDFS...

    用户6543014
  • Presto 在有赞的实践之路

    本文主要介绍了 Presto 的简单原理,以及 Presto 在有赞的实践之路。

    有赞coder
  • Presto系列 | Presto基本介绍

    Presto是一款Facebook开源的MPP架构的OLAP查询引擎,可针对不同数据源执行大容量数据集的一款分布式SQL执行引擎。因为工作中接触到Presto,...

    Monica2333
  • 快速学习-Presto简介

    Presto是一个开源的分布式SQL查询引擎,适用于交互式分析查询,数据量支持GB到PB字节。 Presto的设计和编写完全是为了解决像Facebook这样规...

    cwl_java
  • Presto查询执行过程和索引条件下推分析

    《Presto 分布式SQL查询引擎及原理分析》详细介绍了Presto 的数据模型、技术架构,解释了Presto 对于查询分析有着较高性能。任何SQL引擎,执行...

    yuanyi928
  • 请正确使用http状态码,谢谢!

    最近,由于某些特别原因。打开一些网址一直显示404, 想请问下,xx站的程序员,能不能按照http协议来返回呢? 什么是HTTP状态码451? 根据定义,HTT...

    爬虫

扫码关注云+社区

领取腾讯云代金券