presto简介

MapReduce不能满足大数据快速实时adhoc查询计算的性能要求，Facebook2012年开发，2013年开源

基于内存的并行计算，Facebook推出的分布式SQL交互式查询引擎 多个节点管道式执行

支持任意数据源 数据规模GB~PB 是一种Massively parallel processing（mpp）(大规模并行处理)模型

数据规模PB 不是把PB数据放到内存，只是在计算中拿出一部分放在内存、计算、抛出、再拿

多数据源、支持SQL、扩展性（可以自己扩展新的connector）、混合计算（同一种数据源的不同库 or表；将多个数据源的数据进行合并）、高性能、流水线（pipeline）

数据仓库 交互式略弱的查询引擎 只能访问HDFS文件 磁盘

但是presto是无法代替hive的

基于spark core mpp模式 详细课件spark sql一文

cube预计算

时序，数据放内存 索引 预计算

不适合多个大表的join *** 作，因为presto是基于内存的，太多数据内存放不下的

如果一个presto查询查过30分钟，那

就kill吧，说明不适合 也违背了presto的实时初衷

相当于MySQL的一个实例，

相当于MySQL的database

大内存、万兆网络、高计算能力

presto 查询引擎是一个Master-Slave的拓扑架构

中心的查询角色 接收查询请求、解析SQL 生成执行计划 任务调度 worker管理

coordinator进行是presto集群的master进程

执行任务的节点

presto以插件形式对数据存储层进行了抽象，它叫做连接器，不仅包含Hadoop相关组件的连接器还包括RDBMS连接器

具体访问哪个数据源是通过catalog 中的XXXX.properties文件中connector.name决定的

提取数据 负责实际执行查询计划

将coordinator和worker结合在一起服务；

worker节点启动后向discovery service服务注册

coordinator通过discovery service获取注册的worker节点

1、coordinator接到SQL后，通过SQL语法解析器把SQL语法解析变成一个抽象的语法树AST，只是进行语法解析如果有错误此环节暴露

2、语法符合SQL语法，会经过一个逻辑查询计划器组件，通过connector 查询metadata中schema 列名 列类型等，将之与抽象语法数对应起来，生成一个物理的语法树节点 如果有类型错误会在此步报错

3、如果通过，会得到一个逻辑的查询计划，将其分发到分布式的逻辑计划器里，进行分布式解析，最后转化为一个个task

4、在每个task里面，会将位置信息解析出来，交给执行的plan，由plan将task分给worker执行

1、如果某个worker挂了，discovery service 会通知coordinator

2、对于query是没有容错的，一旦worker挂了，query就执行失败了，与其在这里容错不如直接执行

3、coordinator 和discovery service 的单点故障问题还没有解决

presto主要配置文件如下： catalog/:配置各数据源的信息。presto是由facebook开源，基于内存的分布式查询引擎。支持多数据源，可支持PB级海量数据查询，本身不作数据存储。由于基于内存查询，减少了IO开销，故查询效率很高，但不适用于多表联合查询。

拓展资料：

1、presto架构 ：

与众多分布式框架类似，由某组件进行请求处理以及分发任务至各执行节点。在presto架构中，Coordinator即为这样的角色。负责解析SQL，生成执行计划，分发任务到各节点。 Worker即各实际执行查询的节点。worker收到任务后,通过各种connector取各数据源中的数据。 Discovery service即联系Coordinator及Worker的服务。Worker启动会向Discovery server注册服务，Coordinator向Discovery server获取Worker节点信息。

2、Presto因其优秀的查询速度被我们所熟知，它本身基于MPP架构，可以快速的对Hive数据进行查询，同时支持扩展Connector，目前对Mysql、MongoDB、Cassandra、Hive等等一系列的数据库都提供了Connector进行支持。是我们常用的SQL on Hadoop的解决方案。那么我们今天就来看一下，当我们选择Presto作为我们的查询引擎之后，我们需要考虑的问题。

3、单机维度

GENERAL_POOL每次内存申请时，都会判断内存使用量是否超过了最大内存，如果超过了就报错，错误为“Query exceeded local memory limit of x”，这保护了Presto会无限申请内存，只会导致当前查询出错。同时，如果该节点的GENERAL_POOL可使用内存以及可回收内存为0，那么认为该node为Block node。RESERVED_POOL可以认为是查询最大的SQL，其能满足GENERAL_POOL的内存限制策略，那么肯定会满足RESERVED_POOL的策略(复用了GENERAL_POOL策略)。

4、Resource Groups

Resource Groups 可以认为是Presto实现了一个弱资源限制和隔离功能。其可以为每个group指定队列大小、并发大小、内存使用大小。为每个group设置合理的hardConcurrencyLimit(最大并发数)、softMemoryLimit(内存最大使用值)及maxQueued(队列大小)一方面可以使不同业务影响降低，另一方面也大概率避免OOM问题，当然善于运用user及做下二次开发，就可以让Presto支持多用户共用同一分组和权限认证功能。

可以浏览很多数据库呀！Presto

是

Facebook

推出的一个基于Java开发的大数据分布式

SQL

查询引擎，可对从数

G

到数

P

的大数据进行交互式的查询，查询的速度达到商业数据仓库的级别，据称该引擎的性能是

Hive

的

10

倍以上。Presto

可以查询包括

Hive、Cassandra

甚至是一些商业的数据存储产品，单个

Presto

查询可合并来自多个数据源的数据进行统一分析。Presto

的目标是在可期望的响应时间内返回查询结果，Facebook

在内部多个数据存储中使用

Presto

交互式查询，包括

300PB

的数据仓库，超过

1000

个

Facebook

员工每天在使用

Presto

运行超过

3

万个查询，每天扫描超过

1PB

的数据。

---