这是我参与「第四届青训营 」笔记创作活动的的第7天
Presto 基础原理与概念
Presto是一款Facebook开源的MPP架构的OLAP查询引擎，可针对不同数据源执行大容量数据集的一款分布式SQL执行引擎。因为工作中接触到Presto，研究它对理解SQL Parser、常见算子的实现（如SQL中table scan,join,aggregation）、资源管理与调度、查询优化（如向量化执行、动态代码生成）、大数据下各个组件为何适用不同场景等等都有帮助。
presto 优点：
- 完全基于内存的并行计算，Massively parallel processing（mpp）(大规模并行处理)模型
- 流水线
- 本地化计算
- 动态编译执行计划
- 小心使用内存和数据结构
- 类BlinkDB的近似查询
- GC控制
- presto数据处理能力到达PB级别，支持查询数据源有hive、kafka、cassandra、redis、mongodb、sql server等
核心组件架构介绍
Coordinator和Worker两种角色 当你第一次安装Presto时，你只用了一台机器来运行所有的查询。但是，单机环境是远远达不到理想的规模和性能的。
Presto是一个分布式的SQL查询引擎，组装了多个并行计算的数据库和查询引擎（这就是MPP模型的定义）。Presto不是依赖单机环境的垂直扩展性。她有能力在水平方向，把所有的处理分布到集群内的各个机器上。这意味着你可以通过添加更多节点来获得更大的处理能力。
利用这种架构，Presto查询引擎能够并行的在集群的各个机器上，处理大规模数据的SQL查询。Presto在每个节点上都是单进程的服务。多个节点都运行Presto，相互之间通过配置相互协作，组成了一个完整的Presto集群。
下图展示了从宏观层面概括了Presto的集群组件：1个coordinator，多个worker节点。用户通过客户端连接到coordinator，可以是JDBC驱动或者Presto命令行cli。
Coordinator是Presto上一个专门的服务，专门用来处理用户的查询请求，管理worker节点以执行查询。
Worker 节点则负责执行任务和处理数据。
Discovery服务通常跑在coordinator节点上，允许worker注册到集群信息中。
客户端、coordinator，worker之间的所有通信，都是用基于REST的HTTP/HTTPS交互。
Presto重要机制
查询流程如下：
- Client 使用 HTTP 协议发送一个 query 请求。
- 通过 Discovery Server 发现可用的 Server。
- Coordinator 构建查询计划（通过 Anltr3 解析为 AST（抽象语法树），然后通过 Connector 获取原始数据的 Metadata 信息，生成分发计划和执行计划）。
- Coordinator 向 Worker 发送任务。
- Worker 通过 Connector 插件读取数据。
- Worker 在内存里执行任务（Worker 是纯内存型计算引擎）。
- Worker 将数据返回给 Coordinator，汇总之后再响应客户端。
性能优化实战
-- 合理设置分区 与Hive类似，Presto会根据元数据信息读取分区数据，合理的分区能减少Presto数据读取量，提升查询性能。
-- 使用列式存储 Presto对ORC文件读取做了特定优化，因此在Hive中创建Presto使用的表时，建议采用ORC格式存储。相对于Parquet，Presto对ORC支持更好。
-- 使用压缩 数据压缩可以减少节点间数据传输对IO带宽压力，对于即席查询需要快速解压，建议采用Snappy压缩。
-- 字段名引用 避免和关键字冲突：MySQL对字段加反引号`、Presto对字段加双引号分割 当然，如果字段名称不是关键字，可以不加这个双引号。
-- 时间函数 对于Timestamp，需要进行比较的时候，需要添加Timestamp关键字，而MySQL中对Timestamp可以直接进行比较。
/MySQL的写法/
SELECT t FROM a WHERE t > '2020-01-01 00:00:00';
