分布式SQL查询引擎Presto原理引见

我们实时引擎组新引入了一款分布式SQL查询引擎，名字叫Presto，目前已经调研和测试了2个月了，并且期间某平台也从impala平台迁入到了Presto平台，查询性能有了2-3倍的提升（各种原因导致），所以本文将结合作者这段时间的测试和调研研究，来揭开Presto的神秘面纱。

Presto是神马

Presto是由Facebook开发的一个分布式SQL查询引擎， 它被设计为用来专门进行高速、实时的数据分析。它的产生是为了解决Hive的MapReduce模型太慢以及不能通过BI或Dashboards直接展现HDFS数据等问题。Presto是一个纯粹的计算引擎，它不存储数据，其通过Connector获取第三方Storage服务的数据。

历史

• 2012年秋季，Facebook启动Presto项目
• 2013年冬季，Presto开源
• 2017年11月，11888 commits，203 releases，198 contributors

功能和优点

• Ad-hoc，期望查询时间秒级或几分钟
• 比Hive快10倍
• 支持多数据源，如Hive、Kafka、MySQL、MonogoDB、Redis、JMX等，也可自己实现Connector
• Client Protocol: HTTP+JSON, support various languages(Python, Ruby, PHP, Node.js Java)
• 支持JDBC/ODBC连接
• ANSI SQL，支持窗口函数，join，聚合，复杂查询等

架构

• Master-Slave架构
• 三个模块
  • Coordinator、Discovery Service、Worker
• Connector

Presto沿用了通用的Master-Slave架构，Coordinator即Presto的Master，Worker即其Slave，Discovery Service就是用来保存Worker结点信息的，通过HTTP协议通信，而Connector用于获取第三方存储的Metadata及原始数据等。

Coordinator负责解析SQL语句，生成执行计划，分发执行任务给Worker节点执行；Worker节点负责实际执行查询任务。Worker节点启动后向Discovery Server服务注册，Coordinator从Discovery Server获得可以正常工作的Worker节点。假如配置了Hive Connector，需要配置一个Hive MetaStore服务为Presto提供Hive元信息，Worker节点与HDFS交互读取数据。

部署方式

Presto常见的部署方式如下图所示：

Coordinator与Discovery Server耦合在一起混合部署，然后部署多台Worker。然而这个有个问题，就是Coordinator存在单点问题，我们目前线上使用ip漂移的方法（网卡绑定多ip）。如下图所示：

查询流程

整体查询流程为：

• Client使用HTTP协议发送一个query请求。
• 通过Discovery Server发现可用的Server。
• Coordinator构建查询计划（Connector插件提供Metadata）
• Coordinator向workers发送任务
• Worker通过Connector插件读取数据
• Worker在内存里执行任务（Worker是纯内存型计算引擎）
• Worker将数据返回给Coordinator，之后再Response Client

SQL执行流程

当Coordinator收到一个Query，其SQL执行流程如上图所示。SQL通过Anltr3解析为AST（抽象语法树），然后通过Connector获取原始数据的Metadata信息，这里会有一些优化，比如缓存Metadata信息等，根据Metadata信息生成逻辑计划，然后会依次生成分发计划和执行计划，在执行计划里需要去Discovery里获取可用的node列表，然后根据一定的策略，将这些计划分发到指定的Worker机器上，Worker机器再分别执行。

与Hive比较

上图显示了MapReduce与Presto的执行过程的不同点，MR每个操作要么需要写磁盘，要么需要等待前一个stage全部完成才开始执行，而Presto将SQL转换为多个stage，每个stage又由多个tasks执行，每个tasks又将分为多个split。所有的task是并行的方式进行允许，stage之间数据是以pipeline形式流式的执行，数据之间的传输也是通过网络以Memory-to-Memory的形式进行，没有磁盘io操作。这也是Presto性能比Hive快很多倍的决定性原因。

实现低延时的原理

• 完全基于内存的并行计算
• 流水线
• 本地化计算
• 动态编译执行计划
• 小心使用内存和数据结构
• 类BlinkDB的近似查询
• GC控制

当然其优化方法也包括了一些传统的SQL优化原理，关于这些优化细节等后续文章详细介绍。

缺点

前面介绍了Presto的各种优点，其实其也有一些缺点，主要缺点为以下三条：

• No fault tolerance；当一个Query分发到多个Worker去执行时，当有一个Worker因为各种原因查询失败，那么Master会感知到，整个Query也就查询失败了，而Presto并没有重试机制，所以需要用户方实现重试机制。
• Memory Limitations for aggregations, huge joins；比如多表join需要很大的内存，由于Presto是纯内存计算，所以当内存不够时，Presto并不会将结果dump到磁盘上，所以查询也就失败了，但最新版本的Presto已支持写磁盘操作，这个待后续测试和调研。
• MPP(Massively Parallel Processing )架构；这个并不能说其是一个缺点，因为MPP架构就是解决大量数据分析而产生的，但是其缺点也很明显，假如我们访问的是Hive数据源，如果其中一台Worke由于load问题，数据处理很慢，那么整个查询都会受到影响，因为上游需要等待上游结果。
  这篇文章就先介绍这里吧，后续会陆续更新一系列Presto相关的文章，欢迎关注。

参考链接

https://tech.meituan.com/presto.html