presto 0.166概述

presto是什么

是Facebook开源的,完全基于内存的并⾏计算,分布式SQL交互式查询引擎

是一种Massively parallel processing (MPP)架构,多个节点管道式执⾏

⽀持任意数据源(通过扩展式Connector组件),数据规模GB~PB级

使用的技术,如向量计算,动态编译执⾏计划,优化的ORC和Parquet Reader等

presto不太支持存储过程,支持部分标准sql

presto的查询速度比hive快5-10倍

上面讲述了presto是什么,查询速度,现在来看看presto适合干什么

适合:PB级海量数据复杂分析,交互式SQL查询,⽀持跨数据源查询

不适合:多个大表的join操作,因为presto是基于内存的,多张大表在内存里可能放不下

和hive的对比:

hive是一个数据仓库,是一个交互式比较弱一点的查询引擎,交互式没有presto那么强,而且只能访问hdfs的数据

presto是一个交互式查询引擎,可以在很短的时间内返回查询结果,秒级,分钟级,能访问很多数据源

hive在查询100Gb级别的数据时,消耗时间已经是分钟级了

但是presto是取代不了hive的,因为p全部的数据都是在内存中,限制了在内存中的数据集大小,比如多个大表的join,这些大表是不能完全放进内存的,实际应用中,对于在presto的查询是有一定规定条件的,比比如说一个查询在presto查询超过30分钟,那就kill掉吧,说明不适合在presto上使用,主要原因是,查询过大的话,会占用整个集群的资源,这会导致你后续的查询是没有资源进行查询的,这跟presto的设计理念是冲突的,就像是你进行一个查询,但是要等个5分钟才有资源继续查询,这是很不合理的,交互式就变得弱了很多

presto基本架构

在谈presto架构之前,先回顾下hive的架构

 

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

presto:presto是在它内部做hive类似的逻辑

 

接下来,深入看下presto的内部架构

这里面三个服务:

Coordinator(考第内ter),是一个中心的查询角色,它主要的一个作用是接受查询请求,将他们转换成各种各样的任务,将任务拆解后分发到多个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

Presto支持的数据源和存储格式

Hadoop/Hive connector与存储格式:

HDFS,ORC,RCFILE,Parquet,SequenceFile,Text

开源数据存储系统:

MySQL & PostgreSQL,Cassandra,Kafka,Redis

其他:

MongoDB,ElasticSearch,HBase

Presto中SQL运行过程:整体流程

1、当我们执行一条sql查询,coordinator接收到这条sql语句以后,它会有一个sql的语法解析器去把sql语法解析变成一个抽象的语法树AST,这抽象的语法书它里面只是进行一些语法解析,如果你的sql语句里面,比如说关键字你用的是int而不是Integer,就会在语法解析这里给暴露出来

2、如果语法是符合sql语法规范,之后会经过一个逻辑查询计划器的组件,他的主要作用是,比如说你sql里面出现的表,他会通过connector的方式去meta里面把表的schema,列名,列的类型等,全部给找出来,将这些信息,跟语法树给对应起来,之后会生成一个物理的语法树节点,这个语法树节点里面,不仅拥有了它的查询关系,还拥有类型的关系,如果在这一步,数据库表里某一列的类型,跟你sql的类型不一致,就会在这里报错

3、如果通过,就会得到一个逻辑的查询计划,然后这个逻辑查询计划,会被送到一个分布式的逻辑查询计划器里面,进行一个分布式的解析,分布式解析里面,他就会去把对应的每一个查询计划转化为task

4、在每一个task里面,他会把对应的位置信息全部给提取出来,交给执行的plan,由plan把对应的task发给对应的worker去执行,这就是整个的一个过程

这是一个通用的sql解析流程,像hive也是遵循类似这样的流程,不一样的地方是distribution planner和executor pan,这里是各个引擎不一样的地方,前面基本上都一致的

Presto中SQL运行过程:MapReduce vs Presto

task是放在每个worker上该执行的,每个task执行完之后,数据是存放在内存里了,而不像mr要写磁盘,然后当多个task之间要进行数据交换,比如shuffle的时候,直接从内存里处理

Presto监控和配置:监控

Web UI

  Query基本状态的查询

JMX HTTP API

  GET /v1/jmx/mbean[/{objectName}]
    • com.facebook.presto.execution:name=TaskManager
    • com.facebook.presto.execution:name=QueryManager
    • com.facebook.presto.execution:name=NodeScheduler
事件通知
  Event Listener
    • query start, query complete

Presto监控和配置:配置

执行计划计划(Coordinator)

node-scheduler.include-coordinator

  • 是否让coordinator运行task

query.initial-hash-partitions

  • 每个GROUP BY操作使⽤的hash bucket(=tasks)最大数目(default: 8)

node-scheduler.min-candidates

  • 每个stage并发运行过程中可使用的最大worker数目(default:10)

query.schedule-split-batch-size

  • 每个split数据量

任务执行(Worker)

query.max-memory (default: 20 GB)

  • 一个查询可以使用的最大集群内存

  • 控制集群资源使用,防止一个大查询占住集群所有资源

  • 使用resource_overcommit可以突破限制

query.max-memory-per-node (default: 1 GB)

  • 一个查询在一个节点上可以使用的最大内存

举例

  • Presto集群配置: 120G * 40

  • query.max-memory=1 TB

  • query.max-memory-per-node=20 GB

query.max-run-time (default: 100 d)

  • 一个查询可以运行的最大时间

  • 防止用户提交一个长时间查询阻塞其他查询

task.max-worker-threads (default: Node CPUs * 4)

  • 每个worker同时运行的split个数

  • 调大可以增加吞吐率,但是会增加内存的消耗

队列(Queue)

任务提交或者资源使用的一些配置,是通过队列的配置来实现的

资源隔离,查询可以提交到相应队列中

• 资源隔离,查询可以提交到相应队列中
• 每个队列可以配置ACL(权限)
• 每个队列可以配置Quota
  可以并发运行查询的数量
  排队的最大数量

大数据OLAP引擎对比

Presto:内存计算,mpp架构

Druid:时序,数据放内存,索引,预计算

Spark SQL:基于Spark Core,mpp架构

Kylin:Cube预计算  

最后,一些零散的知识点

presto适合pb级的海量数据查询分析,不是说把pb的数据放进内存,比如一张pb表,查询count,vag这种有个特点,虽然数据很多,但是最终的查询结果很小,这种就不会把数据都放到内存里面,只是在运算的过程中,拿出一些数据放内存,然后计算,在抛出,在拿,这种的内存占用量是很小的,但是join这种,在运算的中间过程会产生大量的数据,或者说那种查询的数据不大,但是生成的数据量很大,这种也是不合适用presto的,但不是说不能做,只是会占用大量内存,消耗很长的时间,这种hive合适点

presto算是hive的一个补充,需要尽快得出结果的用presto,否则用hive

work是部署的时候就事先部署好的,work启动100个,使用的work不一定100个,而是根据coordinator来决定拆分成多少个task,然后分发到多少个work去

一个coordinator可能同时又多个用户在请求query,然后共享work的去执行,这是一个共享的集群

coordinator和discovery server可以启动在一个节点一个进程,也可以放在不同的node上,但是现在公司大部分都是放在一个节点上,一个launcher start会同时把上述两个启动起来

对于presto的容错,如果某个worker挂掉了,discovery server会发现并通知coordinator

但是对于一个query,是没有容错的,一旦一个work挂了,那么整个qurey就是败了

因为对于presto,他的查询时间是很短的,与其查询这里做容错能力,不如重新执行来的快来的简单

对于coordinator和discovery server节点的单点故障,presto还没有开始处理这个问题貌似

posted @ 2017-06-21 16:19  Super_Orco  阅读(22300)  评论(1编辑  收藏