即席查询之Presto

Presto ：

分布式sql查询引擎 GB–PB
处理秒级查询的场景

注意：不是一个标准 的数据库，不是mysql的替代品，也不能处理在线事务（OLTP）
属于OLAP分析引擎：

1）客户端提交查询，从Presto命令行CLI提交到Coordinator
2）Coordinator解析查询计划，把任务分发给Worker
3) Worker负责执行任务和处理数据
4）Catolog表示数据源。一个Catolog包含Schema和Connector

5）Connector相当于jdbc连接池
6）Schema 相当于mysql，hive，redis数据库，table是表

7）Coordinator负责从Worker获取结果并返回给Client（客户端）

优缺点：

1.基于内存运算，减少了磁盘IO，计算更快
2.能够连接多个数据源，跨数据源联表查询

缺点：
能够处理PB数据，边读边计算，好用内存不高
如果是多表的联表查询，可能产生大量的临时数据，
速度会更慢，反而hive此时会更擅长

Impla和Presto对比
结论：Impla在性能上稍微优先于Presto，但是Presto在数据源的支持上非常丰富
包括：hive，图数据库，传统关系型数据库，redis等

解压缩： jar：tar -zxvf jar包
zip：unzip zip包

yanagishima：presto可视化 b/s端

Presto优化：
1.）合理设置分区数：和hive类似，Presto会根据元数据信息读取分区的数据
，合理的的分区能减少Presto数据的读取量，提升查询性能
2.）使用列式存储：因此在hive中创建Presto使用得表时，
建议采用ORC格式存储，相对于Parquet，Presto对orc的支持更好
3.）使用压缩：压缩可以减少节点间数据传输对IO的带宽压力，即席查询需要快速解压
建议使用snappy压缩
snappy压缩+orc格式存储
4.）优化查询sql：
尽量避免用*读取所有字段
过滤条件必须加上分区字段
group by 语句优化：字段的顺序按照DISTINCT数据多少
进项降序排列
order by使用limit（减少排序计算和内存压力）
使用join时将大表放在左边（如果右边表数据量太大可能内存溢出报错）
默认的算法是broadcast join，即将join左边的表分割到多个worker
然后将join右边的表数据整个赋值一份发送到每个worker进行计算

5.）避免和关键字冲突：mysql 单引号 Presto是双引号
对于时间函数：timestamp 需要添加timestamp 关键字
6.）不支持insert overwrite写法 只能先删除在insert into