presto 架构

2018/09/19 12:14
阅读数 2.1K

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去执行各种任务的节点

1、解析SQL语句

2、⽣成执⾏计划

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

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

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

Discovery service,是将coordinator和woker结合到一起的服务:

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

2、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

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
1 收藏
0
分享
返回顶部
顶部