Presto介绍及常用查询优化方法总结
1、Presto简介
Presto是Facebook开源的MPP（Massive Parallel Processing）SQL引擎，其理念来源于一个叫Volcano的并行数据库，该数据库提出了一个并行执行SQL的模型，它被设计为用来专门进行高速、实时的数据分析。
Presto是一个SQL计算引擎，分离计算层和存储层，其不存储数据，通过Connector SPI实现对各种数据源（Storage）的访问。
1.1 架构
Presto沿用了通用的Master-Slave架构，一个Coordinator，多个Worker。
Coordinator负责解析SQL语句，生成执行计划，分发执行任务给Worker节点执行，Worker节点负责实际执行查询任务。
Presto提供了一套Connector接口，用于读取元信息和原始数据。
Presto 内置有多种数据源，如 Hive、MySQL、Kudu、Kafka 等。
Presto 的扩展机制允许自定义 Connector，从而实现对定制数据源的查询。
假如配置了Hive Connector，需要配置一个Hive MetaStore服务为Presto提供Hive元信息，Worker节点通过Hive Connector与HDFS交互，读取原始数据。
1.2 实现低延时的原理
Presto是一个交互式查询引擎，我们最关心的是Presto实现低延时查询的原理，以下几点是其性能脱颖而出的主要原因：
完全基于内存的并行计算
流水线
本地化计算
动态编译执行计划
小心使用内存和数据结构
GC控制
无容错
2、Presto查询优化
2.1 存储优化
① 合理设置分区
与Hive类似，Presto会根据元信息读取分区数据，合理的分区能减少Presto数据读取量，提升查询性能。
② 使用列式存储
Presto对ORC文件读取做了特定优化，因此在Hive中创建Presto使用的表时，建议采用ORC格式存储。相对于Parquet，Presto对ORC支持更好。
③ 使用压缩
数据压缩可以减少节点间数据传输对IO带宽压力，对于即席查询需要快速解压，建议采用snappy压缩
④ 预先排序
有条件的话提前做好排序，对于已经排序的数据，在查询的数据过滤阶段，ORC格式支持跳过读取不必要的数据。
比如对于经常需要过滤的字段可以预先排序。
2.2 查询优化
① select时只选择必要字段，避免使用 * 号
② 过滤条件加上分区字段，减少查询数据量
③ 合理安排Group by语句中字段顺序对性能有一定提升
将Group By语句中字段按照每个字段distinct数据多少进行降序排列。示例中uid是用户id，比性别数据大很多。
[GOOD]: SELECT GROUP BY uid, gender
[BAD]: SELECT GROUP BY gender, uid④ Order by时使用Limit
Order by需要扫描数据到单个worker节点进行排序，导致单个worker需要大量内存。如果是查询Top N或者Bottom N，使用limit可减少排序计算和内存压力。
⑤ 用regexp_like代替多个like语句
Presto查询优化器没有对多个like语句进行优化，使用regexp_like对性能有较大提升
[GOOD]
SELECT ...
FROM access
WHERE regexp_like(method, 'GET|POST|PUT|DELETE')
[BAD]
SELECT ...
FROM access
WHERE
method LIKE '%GET%' OR
method LIKE '%POST%' OR
method LIKE '%PUT%' OR
method LIKE '%DELETE%'⑥ 使用Rank函数代替row_number函数来获取Top N
在进行一些分组排序场景时，使用rank函数性能更好
2.3 Join优化
① 使用Join语句时将大表放在左边
Presto中join的默认算法是broadcast join，即将join左边的表分割到多个worker，然后将join右边的表数据整个复制一份发送到每个worker进行计算。
如果右边的表数据量太大，则可能会报内存溢出错误。
② 如果左表和右表都比较大
为防止内存溢出，做如下配置：
1）修改配置distributed-joins-enabled (presto version >=0.196)
2）在每次查询开始使用distributed_join的session选项
set session distributed_join = 'true'
SELECT ...
FROM
large_table1
join large_table2
on large_table1.id = large_table2.id核心点就是使用distributed join，也就是hash join。
Presto的这种配置类型会将左表和右表同时以join key的hash value为分区字段进行分区。
所以即使右表也是大表，也会被拆分，相比broadcast join，这种join方式的会增加很多网络数据传输，效率慢。
③ 多个join的OR条件使用union代替
SELECT ...
FROM
t1
JOIN t2
ON t1.a1 = t2.a1 OR
t1.a2 = t2.a2
改为
SELECT ...
FROM
t1
JOIN t2
ON t1.a1 = t2.a1
union
SELECT ...
FROM
t1
JOIN t2
ON t1.a2 = t2.a2④ 使用WITH语句
使用Presto分析统计数据时，可考虑把多次查询合并为一次查询，用Presto提供的子查询完成。
WITH tmp AS (
SELECT DISTINCT a1, a2
FROM t2
)
SELECT ...
FROM t1
JOIN tmp
ON t1.a1 = tmp.a1
union
SELECT ...
FROM t1
JOIN tmp
ON t1.a2 = tmp.a2;⑤ 尽量用UNION ALL代替UNION
和distinct类似, UNION有去重的功能, 所以会使用到内存，如果只是拼接两个或者多个SQL查询的结果, 考虑用UNION ALL
八千里路云和月 | 从零到大数据专家学习路径指南
互联网最坏的时代可能真的来了
我在B站读大学，大数据专业
我们在学习Flink的时候，到底在学习什么？
193篇文章暴揍Flink，这个合集你需要关注一下
Flink生产环境TOP难题与优化，阿里巴巴藏经阁YYDS
Flink CDC我吃定了耶稣也留不住他！| Flink CDC线上问题小盘点
我们在学习Spark的时候，到底在学习什么？
在所有Spark模块中，我愿称SparkSQL为最强！
硬刚Hive | 4万字基础调优面试小总结
数据治理方法论和实践小百科全书
标签体系下的用户画像建设小指南
4万字长文 | ClickHouse基础&实践&调优全视角解析
【面试&个人成长】2021年过半，社招和校招的经验之谈
大数据方向另一个十年开启 |《硬刚系列》第一版完结
我写过的关于成长/面试/职场进阶的文章
当我们在学习Hive的时候在学习什么？「硬刚Hive续集」