presto是个开源的，分布式的查询引擎，基于内存的并行计算，MPP架构，速度比hive快5-6倍，但并不能完全取代hive。

上面讲述了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的架构:

 首先来看下hive的技术架构

hive是通过客户端将数据发送给hiveServer中的，然后hive服务会将与metastore进行交互，获取表的位置结构，存储路径以及元数据信息等，之后hiveServer会进行语法解析，解析成语法树，变成查询计划，进行优化后，将查询计划交给执行引擎，也就是mapReduce。 当然了,Presto也是类似的逻辑。

 

接下来，深入了解下preso的内部架构

Coordinator是个协调器，也是个中心查询角色，主要工作是接收客户端的响应请求，然后将请求翻译成各样的任务，将任务拆解后发到多个worker上去执行各种各样的任务节点。

1.  解析sql语句
2. 生在执行计划
3. 任务分发到worker节点上去执行

worker 接收任务后，执行真正的计算，会到对应的数据源中，通过各种各样的conector把数据提取出来。

Discovery Service 发现服务, worker启动后会向discovery进行注册，而coordinator会从discovery中获取对应的worker节点，然后coordinator就可以知道 有多少个worker可以工作。

 

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，这里是各个引擎不一样的地方，前面基本上都一致的。