Presto简介

刺骨的言语ヽ痛彻心扉 2021-06-10 20:38 506阅读 0赞

是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的架构

![format_png][]

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

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

![format_png 1][]

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

![format_png 2][]

这里面三个服务：

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运行过程：整体流程 ##

![format_png 3][]

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 ##

![format_png 4][]

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  
　　可以并发运行查询的数量  
　　排队的最大数量

![format_png 5][]

## 大数据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还没有开始处理这个问题貌似

[format_png]: /images/20210527/69c45145ccb74117bbd82ff27cced54c.png
[format_png 1]: /images/20210527/de7d6c7f63ec4ce08c682d236a5244ef.png
[format_png 2]: /images/20210527/d7569e63d3a04215bb98edf82085366a.png
[format_png 3]: /images/20210527/7c86eabc729f4c0d91414b77bab98c22.png
[format_png 4]: /images/20210527/25d75283b1c44c9fbf46776c7395c6a2.png
[format_png 5]: /images/20210527/fc6d1aa019dc47439f47b0554d519a1a.png