Presto查询引擎简单分析

Hive查询流程分析

cdn.xitu.io/2019/6/24/16b8778e2a2c1915?imageView2/0/w/1280/h/960/format/webp/ignore-error/1">

各个组件的作用

UI(user interface)(用户接口)：提交数据操作的窗口
Driver(引擎)：负责接收数据操作，实现了会话句柄，并提供基于JDBC / ODBC的execute和fetch API
Metastore(元数据)：Hive元数据，存储所有表信息以及相关的HDFS文件存储目录，一般采用MySQL或者derby存储
Compiler(编译器)：解析查询的SQL，生成阶段性的执行计划（包含MapReduce、元数据操作）
Execution Engine(执行引擎)：执行compiler生成的执行计划。该执行计划是一个阶段的DAG

查询流程

Step 1：UI调用的Driver的execute接口

Step 2：Driver为查询创建会话句柄，并将查询发送给compiler以生成执行计划，

Step 3，4：compiler从metastore获取相关的元数据

Step 5：检查元数据，基于查询谓词调整分区，解析SQL，生成执行计划

Step 6，6.1，6.2，6.3：由compiler生成的执行计划是阶段的DAG，每个阶段都会涉及到Map/Reduce job，元数据的操作或者HDFS文件的操作。
在Map/Reduce阶段，执行计划包含Map操作树(操作树在Mappers上执行)和reduce操作树(Reduce 操作树在 Reducers上执行)，
Execution Engine 将各个阶段提交个适当的组件执行。
Step 7, 8 and 9：在每个任务(mapper / reducer)中，表或者中间输出相关的反序列化器从HDFS读取行，并通过相关的操作树进行传递。
一旦这些输出产生，将通过序列化器生成零时的的HDFS文件(这个只发生在只有Map没有reduce的情况)，生成的HDFS零时文件用于执行计划后续的Map/Reduce阶段。
对于DML操作，临时文件最终移动到表的位置。该方案确保不出现脏数据读取(文件重命名是HDFS中的原子操作)，
对于查询，临时文件的内容由Execution Engine直接从HDFS读取，作为从Driver Fetch API的一部分

Presto查询流程分析

在Map/Reduce阶段 执⾏计划包含Map操作树 操作树在Mappers上执⾏ 和reduce

各个组件的作用

Client(客户端)：提交数据操作的窗口

Discovery Server(服务发现者)：存储可用的Server列表
Coordinator(协调者): 接收数据操作，解析SQL语句，生成查询计划，分发任务至Worker机
Connector Plugin(连接插件)：连接Storagr，提供元数据，支持Hive、Kafka、MySQL、MonogoDB、Redis、JMX等数据源，可自定义
Worker(执行者)：执行查询计划

查询流程

1、Client使用HTTP协议发送一个query请求
2、通过Discovery Server发现可用的Server
3、Coordinator构建查询计划（通过Anltr3解析为AST（抽象语法树），然后通过Connector获取原始数据的Metadata信息，生成分发计划和执行计划）
4、Coordinator向workers发送任务
5、Worker通过Connector插件读取数据
6、Worker在内存里执行任务（Worker是纯内存型计算引擎）
7、Worker将数据返回给Coordinator，汇总之后再响应客户端

Presto与Hive对比

区别：
MapReduce每个操作都需要写磁盘，每个stage需要等待前一个stage全部完成才开始执行，  
而Presto将SQL转换为stage，每个stage又由多个tasks执行，每个tasks又将分为多个split。  
所有的task是并行的方式执行，stage之间数据是以pipeline形式流式的执行，  
数据之间的传输也是通过网络以Memory-to-Memory的形式进行，没有磁盘io操作。  
这也是Presto性能比Hive快5-10倍的决定性原因

Presto缺点

1、没有容错能力，当一个query分发到多个Worker去执行时，当有一个Worker因为各种原因查询失败，Master感知到之后，整个query也会失败

2、内存限制，由于Presto是纯内存计算，所以当内存不够时，Presto并不会将结果dump到磁盘上，所以查询也就失败了(据说最新版本的Presto已经支持写盘操作)

3、并行查询，因为所有的task都是并行执行，如果其中一台Worker因为各种原因查询很慢，那么整个query就会变得很慢

4、并发限制，因为全内存操作+内存限制，能同时处理的数据量有限，因而导致并发能力不足

Mob项目的应用
http://gitlab.code.mob.com/mobdata-plat/dbcloud-api