presto 架构

presto 介绍

• 是Facebook开源的，彻底基于内存的并⾏计算，分布式SQL交互式查询引擎
• 是一种Massively parallel processing (MPP)架构，多个节点管道式执⾏
• ⽀持任意数据源（经过扩展式Connector组件），数据规模GB~PB级
• 使用的技术，如向量计算，动态编译执⾏计划，优化的ORC和Parquet Reader等
• presto不太支持存储过程，支持部分标准sql
• presto的查询速度比hive快5-10倍

presto应用场景

• 适合：PB级海量数据复杂分析，交互式SQL查询，⽀持跨数据源查询
• 不适合：多个大表的join操做，由于presto是基于内存的，多张大表在内存里可能放不下

框架对比

presto：facebook开源的一个java写的分布式数据查询框架，是一个交互式查询引擎，原生集成了Hive、Hbase和关系型数据库，Presto背后所使用的执行模式与Hive有根本的不一样，它没有使用MapReduce，大部分场景下比hive快一个数量级，其中的关键是全部的处理都在内存中完成。 
Druid：是一个实时处理时序数据的Olap数据库，由于它的索引首先按照时间分片，查询的时候也是按照时间线去路由索引。 
spark SQL：基于spark平台上的一个olap框架，本质上也是基于DAG的MPP， 基本思路是增长机器来并行计算，从而提升查询速度。 
kylin：核心是Cube，cube是一种预计算技术，基本思路是预先对数据做多维索引，查询时只扫描索引而不访问原始数据从而提速。

presto整体架构

跟hive架构类似

hive：client将查询请求发送到hive server，它会和metastor交互，获取表的元信息，如表的位置结构等，以后hive server会进行语法解析，解析成语法树，变成查询计划，进行优化后，将查询计划交给执行引擎，默认是MR，而后翻译成MR

presto内部架构

这里面三个服务：

Coordinator是一个中心的查询角色，它主要的一个做用是接受查询请求，将他们转换成各类各样的任务，将任务拆解后分发到多个worker去执行各类任务的节点

一、解析SQL语句

二、⽣成执⾏计划

三、分发执⾏任务给Worker节点执⾏

Worker，是一个真正的计算的节点，执行任务的节点，它接收到task后，就会到对应的数据源里面，去把数据提取出来，提取方式是经过各类各样的connector：

一、负责实际执⾏查询任务

Discovery service，是将coordinator和woker结合到一块儿的服务：

一、Worker节点启动后向Discovery Server服务注册

二、Coordinator从Discovery Server得到Worker节点

coordinator和woker之间的关系是怎么维护的呢？是经过Discovery Server，全部的worker都把本身注册到Discovery Server上，Discovery Server是一个发现服务的service，Discovery Server发现服务以后，coordinator便知道在个人集群中有多少个worker可以给我工做，而后我分配工做到worker时便有了根据

最后，presto是经过connector plugin获取数据和元信息的，它不是⼀个数据存储引擎，不须要有数据，presto为其余数据存储系统提供了SQL能⼒，客户端协议是HTTP+JSON