今天学习了Presto架构原理与优化介绍，首先学习了Presto的基本原理和概念，然后学习了Presto重要机制，最后学习了性能优化实战。
presto是facebook开源的查询分析引擎，在国内是京东用的比较溜和成熟。presto数据处理能力到达PB级别，支持查询数据源有hive、kafka、cassandra、redis、mongodb、sql server等，在工作应用当中，我们发现presto的查询性能比hive要高40%以上。
主要组成部分是：
一个 coordinator+一个discovery server +多个worker。通常discovery server是内嵌在coodinator组件当中。三者的作用分布如下：
1、coodinator：用于解析查询sql，生成执行计划，并分发给worker执行。
2、discovery server：worker上线后，向discovery server注册。coodinator分发任务前，需要向discovery server获取可以正常工作worker列表。
3、worker：具体执行任务的工作节点。
二、presto的特点
低延时、基于内存的计算、本地化计算、GC控制。
三、执行查询过程
prosto查询过程。 presto 优点：
完全基于内存的并行计算，Massively parallel processing（mpp）(大规模并行处理)模型 流水线 本地化计算 动态编译执行计划 小心使用内存和数据结构 类BlinkDB的近似查询 GC控制 presto数据处理能力到达PB级别，支持查询数据源有hive、kafka、cassandra、redis、mongodb、sql server等 presto 缺点：
No fault tolerance；当一个Query分发到多个Worker去执行时，当有一个Worker因为各种原因查询失败，那么Master会感知到，整个Query也就查询失败了，而Presto并没有重试机制，所以需要用户方实现重试机制。
Memory Limitations for aggregations, huge joins；比如多表join需要很大的内存，由于Presto是纯内存计算，所以当内存不够时，Presto并不会将结果dump到磁盘上，所以查询也就失败了，但最新版本的Presto已支持写磁盘操作，这个待后续测试和调研。
MPP(Massively Parallel Processing )架构；这个并不能说其是一个缺点，因为MPP架构就是解决大量数据分析而产生的，但是其缺点也很明显，假如我们访问的是Hive数据源，如果其中一台Worke由于load问题，数据处理很慢，那么整个查询都会受到影响，因为上游需要等待上游结果。
presto不太支持存储过程，支持部分标准sql
presto的查询速度比hive快5-10倍
上面讲述了presto是什么，查询速度，现在来看看presto适合干什么
适合：PB级海量数据复杂分析，交互式SQL查询，⽀持跨数据源查询
不适合：多个大表的join操作，因为presto是基于内存的，多张大表在内存里可能放不下
和hive的对比：
hive是一个数据仓库，是一个交互式比较弱一点的查询引擎，交互式没有presto那么强，而且只能访问hdfs的数据。
