关于数据库:Presto在滴滴的探索与实践

​桔妹导读：Presto 在滴滴外部倒退三年，曾经成为滴滴外部 Ad-Hoc 和 Hive SQL 减速的首选引擎。目前服务 6K+ 用户，每天读取 2PB ~ 3PB HDFS 数据，解决 30 万亿~35 万亿条记录，为了承接业务及丰盛应用场景，滴滴 Presto 须要解决稳定性、易用性、性能、老本等诸多问题。咱们在 3 年多的工夫里，做了大量优化和二次开发，积攒了十分丰盛的教训。本文分享了滴滴对 Presto 引擎的改良和优化，同时也提供了大量稳定性建设教训。

1. Presto 简介

▍1.1 简介

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

▍1.2 架构

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 实现低延时查问的原理，以下几点是其性能怀才不遇的次要起因：

• 齐全基于内存的并行计算
• 流水线
• 本地化计算
• 动静编译执行打算
• 小心应用内存和数据结构
• GC 管制
• 无容错

2. Presto 在滴滴的利用

▍2.1 业务场景

• Hive SQL 查问减速
• 数据平台 Ad-Hoc 查问
• 报表（BI 报表、自定义报表）
• 流动营销
• 数据品质检测
• 资产治理
• 固定数据产品

▍2.2 业务规模

▍2.3 业务增长

▍2.4 集群部署

目前 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 数量来辨别查问大小，架构图见：

3. 引擎迭代

咱们从 2017 年 09 月份开始调研 Presto，经验过 0.192、0.215，共公布 56 次版本。而在 19 年初（0.215 版本是社区分家版本），Presto 社区分家，分为两个我的项目，叫 PrestoDB 和 PrestoSQL，两者都成立了本人的基金会。咱们决定降级到 PrestoSQL 最新版本（340 版本）起因是：

• PrestoSQL 社区活跃度更高，PR 和用户问题可能及时回复
• PrestoDB 次要主力还是 Facebook 保护，以其外部需要为主
• PrestoDB 将来方向次要是 ETL 相干的，咱们有 Spark 兜底，ETL 性能依赖 Spark、Hive

4. 引擎改良

在滴滴外部，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 视图
• Parquet HDFS 文件读取反对
• 大量 UDF 反对
• 其余

Hive SQL 兼容，咱们迭代了三个大版本，目前线上 SQL 通过率 97~99%。而业务从 Spark/Hive 迁徙到 Presto 后，查问性能均匀晋升 30%~50%，甚至一些场景晋升 10 倍，Ad-Hoc 场景共节俭 80% 机器资源。下图是线上 Presto 集群的 SQL 查问通过率及失败起因占比，’null’ 示意查问胜利的 SQL，其余示意谬误起因：

▍4.2 物理资源隔离

上文说到，对性能要求高的业务与大查问业务方混合跑，查问性能容易受到影响，只有独自搭建集群。而独自搭建集群导致 Presto 集群太多，保护老本太高。因为目前咱们 Presto Coordinator 还没有遇到瓶颈，大查问次要影响 Worker 性能，比方一条大 SQL 导致 Worker CPU 打满，导致其余业务方 SQL 查问变慢。所以咱们批改调度模块，让 Presto 反对能够动静打 Label，动静调度指定的 Label 机器。如下图所示：

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

▍4.3 Druid Connector

应用 Presto + HDFS 有一些痛点：

• latency 高，QPS 较低 
• 不能查实时数据，如果有实时数据需要，须要再构建一条实时数据链路，减少了零碎的复杂性
• 要想取得极限性能，必须与 HDFS DataNode 混部，且 DataNode 应用高级硬件，有自建 HDFS 的需要，减少了运维的累赘

所以咱们在 0.215 版本实现了 Presto on Druid Connector，此插件有如下长处：

• 联合 Druid 的预聚合、计算能力（过滤聚合）、Cache 能力，晋升 Presto 性能（RT 与 QPS）
• 让 Presto 具备查问 Druid 实时数据能力
• 为 Druid 提供全面的 SQL 能力反对，扩大 Druid 数据的利用场景
• 通过 Druid Broker 获取 Druid 元数据信息
• 从 Druid Historical 间接获取数据
• 实现了 Limit 下推、Filter 下推、Project 下推及 Agg 下推

在 PrestoSQL 340 版本，社区也实现了 Presto on Druid Connector，然而此 Connector 是通过 JDBC 实现的，毛病比拟显著：

• 无奈划分多个 Split，查问性能差
• 申请查问 Broker，之后再查问 Historical，多一次网络通信
• 对于一些场景，如大量 Scan 场景，会导致 Broker OOM
• Project 及 Agg 下推反对不欠缺

具体架构图见：

应用了 Presto on Druid 后，一些场景，性能晋升 4~5 倍。▍4.4 易用性建设 为了反对公司的几个外围数据平台，包含：数梦、提取工具、数易及特色减速及各种散户，咱们对 Presto 做了很多二次开发，包含权限治理、语法反对等，保障了业务的疾速接入。次要工作：

1. 租户与权限

• 与外部 Hadoop 买通，应用 HDFS SIMPLE 协定做认证
• 应用 Ranger 做鉴权，解析 SQL 使 Presto 领有将列信息传递给上游的能力，提供用户名 + 数据库名 / 表名 / 列名，四元组的鉴权能力，同时提供多表同时鉴权的能力
• 用户指定用户名做鉴权和认证，大账号用于读写 HDFS 数据
• 反对视图、表别名鉴权

1. 语法拓展

• 反对 add partition
• 反对数字结尾的表
• 反对数字结尾的字段

1. 个性加强

• insert 数据时，将插入数据的总行数写入 HMS，为业务方提供毫秒级的元数据感知能力
• 反对查问进度滚动更新，晋升了用户体验
• 反对查问能够指定优先级，为用户不同等级的业务提供了优先级管制的能力
• 批改通信协议，反对业务方能够传播自定义信息，满足了用户的日志审计须要等
• 反对 DeprecatedLzoTextInputFormat 格局
• 反对读 HDFS Parquet 文件门路

▍4.5 稳定性建设

Presto 在应用过程中会遇到很多稳定性问题，比方 Coordinator OOM，Worker Full GC 等，为了解决和不便定位这些问题，首先咱们做了监控体系建设，次要包含：

• 通过 Presto Plugin 实现日志审计性能
• 通过 JMX 获取引擎指标将监控信息写入 Ganglia
• 将日志审计采集到 HDFS 和 ES；对立接入运维监控体系，将所有指标发到 Kafka；
• Presto UI 改良：能够查看 Worker 信息，能够查看 Worker 死活信息

通过以上性能，在每次呈现稳定性问题时，不便咱们及时定位问题，包含指标查看及 SQL 回放等，如下图所示，能够查看某集群的胜利及失败 SQL 数，咱们能够通过定义查问失败率来触发报警：

在 Presto 交换社区，Presto 的稳定性问题困扰了很多 Presto 使用者，包含 Coordinator 和 Worker 挂掉，集群运行一段时间后查问性能变慢等。咱们在解决这些问题时积攒了很多教训，这里说下解决思路和办法。

依据职责划分，Presto 分为 Coordinator 和 Worker 模块，Coordinator 次要负责 SQL 解析、生成查问打算、Split 调度及查问状态治理等，所以当 Coordinator 遇到 OOM 或者 Coredump 时，获取元信息及生成 Splits 是重点狐疑的中央。而内存问题，举荐应用 MAT 剖析具体起因。如下图是通过 MAT 剖析，得出开启了 FileSystem Cache，内存透露导致 OOM。

这里咱们总结了 Coordinator 常见的问题和解决办法：

• 应用 HDFS FileSystem Cache 导致内存透露，解决办法禁止 FileSystem Cache，后续 Presto 本人保护了 FileSystem Cache
• Jetty 导致堆外内存透露，起因是 Gzip 导致了堆外内存透露，降级 Jetty 版本解决
• Splits 太多，无可用端口，TIME_WAIT 太高，批改 TCP 参数解决
• JVM Coredump，显示 ”unable to create new native thread”，通过批改 pid_max 及 max_map_count 解决
• Presto 内核 Bug，查问失败的 SQL 太多，导致 Coordinator 内存透露，社区已修复

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

• 通过 Resource Group 管制业务并发，避免重大超卖
• 通过 JVM 调优，解决一些常见内存问题，如 Young GC Exhausted
• 善用 MAT 工具，发现内存瓶颈

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

这里咱们也总结了 Worker 常见的问题和解决办法：

• Sys load 过高，导致业务查问性能影响很大，钻研 jvm 原理，通过参数（-XX:PerMethodRecompilationCutoff=10000 及 -XX:PerBytecodeRecompilationCutoff=10000）解决，也可降级最新 JVM 解决
• Worker 查问 hang 住问题，起因 HDFS 客户端存在 bug，当 Presto 与 HDFS 混部署，数据和客户端在同一台机器上时，短路读时始终 wait 锁，导致查问 Hang 住超时，Hadoop 社区已解决
• 超卖导致 Worker Young GC Exhausted，优化 GC 参数，如设置 -XX:G1ReservePercent=25 及 -XX:InitiatingHeapOccupancyPercent=15
• ORC 太大，导致 Presto 读取 ORC Stripe Statistics 呈现 OOM，解决办法是限度 ProtoBuf 报文大小，同时帮助业务方正当数据治理
• 批改 Presto 内存治理逻辑，优化 Kill 策略，保障当内存不够时，Presto Worker 不会 OOM，只须要将大查问 Kill 掉，后续熔断机制会改为基于 JVM，相似 ES 的熔断器，比方 95% JVM 内存时，Kill 掉最大 SQL

▍4.6 引擎优化及调研

作为一个 Ad-Hoc 引擎，Presto 查问性能越快，用户体验越好，为了进步 Presto 的查问性能，在 Presto on Hive 场景，咱们做了很多引擎优化工作，次要工作：

• 某业务集群进行了 JVM 调优，将 Ref Proc 由单线程改为并行执行，一般查问由 30S~1 分钟升高为 3 -4S，性能晋升 10 倍 +
• ORC 数据优化，将指定 string 字段增加了布隆过滤器，查问性能晋升 20-30%，针对一些业务做了调优
• 数据治理和小文件合并，某业务方查问性能由 20S 升高为 10S，性能晋升一倍，且查问性能稳固
• ORC 格局性能优化，查问耗时缩小 5%
• 分区裁剪优化，解决指定分区但获取所有分区元信息问题，缩小了 HMS 的压力
• 下推优化，实现了 Limit、Filter、Project、Agg 下推到存储层

18 年咱们为了进步 Presto 查问性能，也调研了一些技术计划，包含 Presto on Alluxio 和 Presto on Carbondata，然而这 2 种计划最初都被舍弃了，起因是：

• Presto on Alluxio 查问性能晋升 35%，然而内存占用和性能晋升不成正比，所以咱们放弃了 Presto on Alluxio，后续可能会对一些性能要求敏感的业务应用
• Presto on Carbondata 是在 18 年 8 月份测试的，过后的版本，Carbondata 稳定性较差，性能没有显著劣势，一些场景 ORC 更快，所以咱们没有再持续跟踪调研 Presto on Carbondata。因为滴滴有专门保护 Druid 的团队，所以咱们对接了 Presto on Druid，一些场景性能晋升 4~5 倍，后续咱们会更多关注 Presto on Clickhouse 及 Presto on Elasticsearch

5. 总结

通过以上工作，滴滴 Presto 逐步接入公司各大数据平台，并成为了公司首选 Ad-Hoc 查问引擎及 Hive SQL 减速引擎，下图能够看到某产品接入后的性能晋升：

上图能够看到大概 2018 年 10 月该平台开始接入 Presto，查问耗时 TP50 性能晋升了 10+ 倍，由 400S 升高到 31S。且在工作数逐步增长的状况下，查问耗时保障稳固不变。

而高性能集群，咱们做了很多稳定性和性能优化工作，保障了均匀查问工夫小于 2S。如下图所示：

6. 瞻望

Presto 次要利用场景是 Ad-Hoc 查问，所以其高峰期次要在白天，如下图所示，是网约车业务下午 12-16 点的查问，能够看到均匀 CPU 使用率在 40% 以上。

然而如果看最近一个月的 CPU 使用率会发现，均匀 CPU 使用率比拟低，且波峰在白天 10~18 点，早晨基本上没有查问，CPU 使用率不到 5%。如下图所示：

所以，解决早晨资源节约问题是咱们今后须要解决的难题。

同时，为了不与开源社区脱节，咱们打算降级 PrestoDB 0.215 到 PrestoSQL 340 版本，届时会把咱们的 Presto on Druid 代码开源进去，回馈社区。

本文作者

滴滴 Presto 引擎负责人，负责率领引擎团队深刻 Presto 内核，解决在海量数据规模下 Presto 遇到的稳定性、性能、老本方面的问题。搜索引擎及 OLAP 引擎爱好者，公众号：FFCompute

对于团队

滴滴大数据架构部 OLAP & 检索平台组负责以 Elasticsearch、Clickhouse、Presto 及 Druid 为代表的 OLAP 引擎的内核级极致优化，为滴滴各个产品线提供稳固牢靠的 PB 级海量数据的实时数据分析、日志检索、监控及即席查问服务。

博闻强识，招贤纳士，滴滴用广大的舞台，在这里，期待你！

延长浏览

内容编辑 | Charlotte
分割咱们 | DiDiTech@didiglobal.com

滴滴技术 出品