Presto是FB开源出来的实时分析引擎，可以federated的从多种数据源去读取数据，做联合查询，支持实时Interactive BI或bath ETL的需求
从其问题域来看，基本是和spark是重合的，那么两者区别是什么？
https://stackoverflow.com/questions/50014017/why-presto-is-faster-than-spark-sql
这两个答案说的比较清楚，
所以可以看出，Presto并没有什么创新的东西，对于Spark而言，主要是做减法，降低overhead，提升性能
所以Presto更偏实时一些，更适用于MPP的场景，较为简单的SQL
Presto的架构和查询流程，都是典型的MPP方式
特点是，执行都是pipeline的方式，所有中间数据和状态都放在内存中，这样比spark那样落盘，再读出的方式要快
查询过程，
首先是parsing，并形成逻辑计划，
接着是查询优化，和生成物理执行计划
Presto的查询优化没啥创新的
需要注意的是，
首先他也有stage的概念，和spark一样，stage里面可以直接local完成的，所以上面的逻辑计划，
被分成5个stage，stage之间需要shuffle，做过流系统的都知道，一旦shuffle，性能就不行了，对cpu，网络，buffer的消耗都很大
Inter-node，节点间的并行，通过在不同的worker上并行相同的task，处理不同的数据split
所以思路一定是要尽量减少shuffle，思路也比较直观，比如做join，如果相同join id的数据都在一个节点，就不用shuffle
这个就叫，Data Layout Properties，数据分布
还有，Node Properties，根据node的属性来，减少不必要的shuffle，合并stage
再者，看看Intra-node，节点内的并行，通过thread，这个应该是Presto的特点，可以大大提升查询性能
右图可以看出，在pipeline1，pipeline2中加了很多并发的thread来并行的做
计划生成完后，就是调度，
Coordinator将plan stages以可执行tasks，分发到各个workers上去，task一个执行单元
Task中又包含很多pipelines，pipeline由operators组成
调度分为3种，
Stage调度，可以all in，或分阶段
all in，延迟会小，但会耗费更多的资源
Task Scheduling，
Split Scheduling
最终还要给各个leaf stage分配splits，因为leaf stage必须要被分配splits后才能启动
presto这里的优化，先只会enumerate一小批的splits，分配给各个task，不会一下把所有的splits都捞出来分配，优点下面也说了
调度完，最后就是执行
Query Execution
开始执行，driver loop开始pass split
这里产生page的概念，source从split读出的结构就是pages，Operator的输入输出也是pages，类似spark中的RDD
从右图可以看出，page是一种以column方式组织的结构，便于AP
第二步是shuffle，
presto是延迟优先的，所以shuffle的中间结果不能落盘，放在memory buffer里面
其他worker通过Http Long-Polling的方式来拉数据
同时要监控，output和input的buffer的使用情况，来调整并发，避免内存占用过高
output buffer太大了，让写并发降一些，如果input buffer太大，让读并发降些，这样也会触发前面的写并发的反压
最后是把结果写出，
写吞吐如果要高，多开写并发，但是写并发高，对存储的要求就比较高，
比如对于S3，每个并发都需要写一个文件，会导致很多小文件，查询起来就很麻烦
Presto采用的是adaptive来决定写并发
