Presto (三) --------- Presto 优化

---

一、数据存储

A、合理设置分区

与 Hive 类似，Presto 会根据元数据信息读取分区数据，合理的分区能减少Presto 数据读取量，提升查询性能。

B、使用列式存储

Presto 对 ORC 文件读取做了特定优化，因此在 Hive 中创建 Presto 使用的表时，建议采用 ORC 格式存储。相对于 Parquet，Presto 对 ORC 支持更好。

C、使用压缩

数据压缩可以减少节点间数据传输对 IO 带宽压力，对于即席查询需要快速解压，建议采用 Snappy 压缩。

二、查询 SQL

A、只选择使用的字段

由于采用列式存储，选择需要的字段可加快字段的读取、减少数据量。避免采用 * 读取所有字段。

[GOOD]: SELECT time, user, host FROM tbl
[BAD]:  SELECT * FROM tbl
1
2

B、过滤条件必须加上分区字段

对于有分区的表，where 语句中优先使用分区字段进行过滤。acct_day 是分区字段，visit_time 是具体访问时间。

[GOOD]: SELECT time, user, host FROM tbl where acct_day=20171101
[BAD]:  SELECT * FROM tbl where visit_time=20171101
1
2

C、Group By 语句优化

合理安排 Group by 语句中字段顺序对性能有一定提升。将 Group By 语句中字段按照每个字段 distinct 数据多少进行降序排列。

[GOOD]: SELECT GROUP BY uid, gender
[BAD]:  SELECT GROUP BY gender, uid
1
2

D、Order by 时使用 Limit

Order by 需要扫描数据到单个 worker 节点进行排序，导致单个 worker 需要大量内存。如果是查询 Top N 或者 Bottom N，使用 limit 可减少排序计算和内存压力。

[GOOD]: SELECT * FROM tbl ORDER BY time LIMIT 100
[BAD]:  SELECT * FROM tbl ORDER BY time
1
2

E、使用 Join 语句时将大表放在左边

Presto中 join 的默认算法是 broadcast join，即将 join 左边的表分割到多个worker，然后将 join 右边的表数据整个复制一份发送到每个 worker 进行计算。如果右边的表数据量太大，则可能会报内存溢出错误。

[GOOD] SELECT ... FROM large_table l join small_table s on l.id = s.id
[BAD] SELECT ... FROM small_table s join large_table l on l.id = s.id
1
2

三、注意事项

A、字段名引用

避免和关键字冲突：MySQL 对字段加反引号`、Presto对字段加双引号分割
当然，如果字段名称不是关键字，可以不加这个双引号。

B、时间函数

对于 Timestamp，需要进行比较的时候，需要添加 Timestamp 关键字，而 MySQL 中对 Timestamp 可以直接进行比较。

/*MySQL的写法*/
SELECT t FROM a WHERE t > '2017-01-01 00:00:00'; 
/*Presto中的写法*/
SELECT t FROM a WHERE t > timestamp '2017-01-01 00:00:00';
1
2
3
4

C、不支持 INSERT OVERWRITE 语法

Presto 中不支持 insert overwrite 语法，只能先 delete，然后 insert into。

D、PARQUET 格式

Presto 目前支持 Parquet 格式，支持查询，但不支持 insert。