Presto 概念 及 架构

一、概念：

Presto 是一个开源的分布式SQL查询引擎，数据量支持GB到PB字节，主要用来处理秒级查询的场景。

1.1 Presto概念

Presto是一个开源的分布式SQL查询引擎，适用于交互式分析查询，数据量支持GB到PB字节。
Presto的设计和编写完全是为了解决像Facebook这样规模的商业数据仓库的交互式分析和处理速度的问题。
注意：虽然Presto可以解析SQL，但它不是一个标准的数据库。不是MySQL、Oracle的代替品，也不能用来处理在线事务（OLTP）。

1.2 Presto应用场景

Presto支持在线数据查询，包括Hive，关系数据库（MySQL、Oracle）以及专有数据存储。
一条Presto查询可以将多个数据源的数据进行合并，可以跨越整个组织进行分析。
Presto主要用来处理响应时间小于1秒到几分钟的场景。

1.3 Presto的架构组成部分：

1、）由客户端提交查询，从Presto命令行CLi提交到Coordinator
2、) Coordinator 解析查询计划，然后把任务分发给work 执行。
3、）work负责执行和任务处理。
4、）一个catalog表示数据源。一个catalog表示schema和connector

1.4 Presto 优点：

（1）Presto基于内存运算，减少了磁盘IO，计算更快。
（2）能够连接多个数据源，跨数据源连表查，从Hive查询大量网站访问记录，然后从Mysql中匹配出设备信息。
（3）Presto 支持多数据源。
（4）部署也比Hive简单，因为Hive是基于HDFS的，需要先部署HDFS。

Presto 缺点：

Presto 能够处理PB级别的海量数据分析，但Presto并不是把PB级数据都放在内存中计算的。而是根据场景，如count（） AVG等聚合函数，是边读数据，边计算，在清内存，在读数据，在计算，这种耗的内存并不高。

二、Presto优化

2.1数据存储

1）合理设置分区
与Hive类似，Presto会根据元信息读取分区数据，合理的分区能减少Presto数据读取量，提升查询性能。
2）使用列式存储
Presto对ORC文件读取做了特定优化，因此在Hive中创建Presto使用的表时，建议采用ORC格式存储。相对于Parquet，Presto对ORC支持更好。
3）使用压缩
数据压缩可以减少节点间数据传输对IO带宽压力，对于即席查询需要快速解压，建议采用Snappy压缩。
4）预先排序
对于已经排序的数据，在查询的数据过滤阶段，ORC格式支持跳过读取不必要的数据。比如对于经常需要过滤的字段可以预先排序。

2.2 查询SQL优化

1）只选择使用必要的字段
1）只选择使用必要的字段
3）Group By语句优化
4）Order by时使用Limit
Order by需要扫描数据到单个worker节点进行排序，导致单个worker需要大量内存。如果是查询Top N或者Bottom N，使用limit可减少排序计算和内存压力。
5）使用近似聚合函数
Presto有一些近似聚合函数，对于允许有少量误差的查询场景，使用这些函数对查询性能有大幅提升。比如使用approx_distinct() 函数比Count(distinct x)有大概2.3%的误差。
SELECT approx_distinct(user_id) FROM access
6）用regexp_like代替多个like语句
Presto查询优化器没有对多个like语句进行优化，使用regexp_like对性能有较大提升
7）使用Join语句时将大表放在左边
Presto中join的默认算法是broadcast join，即将join左边的表分割到多个worker，然后将join右边的表数据整个复制一份发送到每个worker进行计算。如果右边的表数据量太大，则可能会报内存溢出错误。

2.3 无缝替换Hive表

如果之前的hive表没有用到ORC和snappy，那么怎么无缝替换而不影响线上的应用：
比如如下一个hive表：
1、建立对应的orc表
2、先将数据灌入orc表，然后更换表名
3、其中原表不要删除，若线上运行一段时间后没有出现问题，则可以删除该源表。

2.4 建表格式的选择

ORC和Parquet都支持列式存储，但是ORC对Presto支持更好（Parquet对Impala支持更好）
对于列式存储而言，存储文件为二进制的，对于经常增删字段的表，建议不要使用列式存储（修改文件元数据代价大）。对比数据仓库，dwd层建议不要使用ORC，而dm层则建议使用。

搭建部分不写了就。官网查看。

 

【转载注明出处，还望尊重原创 】

 

【作者水平有限，如有错误欢迎指正 .】