干货 | 携程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)

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

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Jerry的SAP技术分享

SAP订单编排和流程增强概述

SAP产品里的订单处理,无论是On-Premises解决方案还是云产品,我认为归根到底可以概括成四个字:订单编排,包含两个层次的内容:

1131
来自专栏SAP最佳业务实践

从SAP最佳业务实践看企业管理(131)-MM-134交货的库存调拨

MM 134交货的库存调拨 库存调拨流程始于在同一个公司代码中将物料从一个工厂调拨到另一工厂的请求。该请求,以库存调拨申请的形式在采购工厂通过 MRP 自动创建...

2214
来自专栏逸鹏说道

03.SQLServer性能优化之---存储优化系列

汇总篇:http://www.cnblogs.com/dunitian/p/4822808.html#tsql 概 述:http://www.cnblogs....

3095
来自专栏大数据

什么是Kafka

Kafka的增长是爆炸性的。财富500强企业中超过三分之一使用卡夫卡。这些公司包括十大旅游公司,十大银行中的七家,十大保险公司中的八家,十大电信公司中的九家,等...

1.1K2
来自专栏SAP最佳业务实践

SAP最佳业务实践:MM–转包(138)-3交货请求

3.4 MIGO创建外向交货请求 此活动为要发送到供应商的部件创建外向交货请求。 角色:仓库文员 后勤-物料管理-库存管理-货物一定-货物移动 (MIGO) ...

4026
来自专栏Jerry的SAP技术分享

一些SAP Partners能够通过二次开发实现打通C4HANA和S4HANA

有好几位朋友在公众号后台给我留言询问SAP C/4HANA和S/4HANA集成的方案。

1340
来自专栏BestSDK

Oculus 发布1.5.0版 SDK,新增 Touch 功能

1.5.0 版本 SDK 的发布主要是引入了新的 Touch 的功能,以及为静态层添加了压缩格式的支持。 新特性 · SDK现在可以检测到用户的拇指是否接触到T...

2428
来自专栏IT大咖说

容器化RDS|计算存储分离架构下的 IO 优化

摘要 在基于 Kubernetes 和 Docker 构建的私有 RDS 中,普遍采用了计算存储分离架构。该架构优势明显, 但对于数据库类 Latency Se...

3668
来自专栏杨建荣的学习笔记

多套Oracle 10g整合迁移到11g的方案

在数据迁移中,除了跨平台,全量,增量数据迁移之外,还有一类会把已有的难度升级,那就是整合式迁移,比如原来有两个数据,迁移后是一个,类似这样的需求,如果再加...

4093
来自专栏圣杰的专栏

性能优化知多少

1. 引言 最近一段时间,系统新版本要发布,在beta客户测试期间,暴露了很多问题,除了一些业务和异常问题外,其他都集中在性能上。有幸接触到这些性能调优的机会,...

2189

扫码关注云+社区

领取腾讯云代金券