Presto查询引擎简单分析

硅步至千里 2018-12-21

Hive查询流程分析

Presto查询引擎简单分析

各个组件的作用

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

Presto查询引擎简单分析

各个组件的作用

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

Presto查询引擎简单分析

[ShareSDK] 轻松实现社会化功能 强大的社交分享

[SMSSDK] 快速集成短信验证 联结通讯录社交圈

[MobLink] 打破App孤岛 实现Web与App无缝链接

[MobPush] 快速集成推送服务 应对多样化推送场景

[AnalySDK] 精准化行为分析 + 多维数据模型 + 匹配全网标签 + 垂直行业分析顾问

BBSSDK | ShareREC | MobAPI | MobPay | ShopSDK | MobIM | App工厂

截止2018 年4 月,Mob 开发者服务平台全球设备覆盖超过84 亿,SDK下载量超过3,300,000+次,服务超过380,000+款移动应用

相关推荐