presto的常用基本操作

Posted 2021-07-20 上官沐雪

presto的常用基本知识及操作

1.Presto 架构

Presto 是一个运行在多台服务器上的分布式系统。完整安装包括一个 Coordinator 和多 个 Worker。由客户端提交查询，从 Presto 命令行 CLI 提交到 Coordinator。Coordinator 进行 解析，分析并执行查询计划，然后分发处理队列到 Worker。

1）Coordinator
Coordinator 服务器是用来解析语句，执行计划分析和管理 Presto 的 Worker 结点。Presto 安装必须有一个 Coordinator 和多个 Worker。如果用于开发环境和测试，则一个 Presto 实例 可以同时担任这两个角色。 Coordinator 跟踪每个 Work 的活动情况并协调查询语句的执行。Coordinator 为每个查询 建立模型，模型包含多个 Stage，每个 Stage 再转为 Task 分发到不同的 Worker 上执行。 Coordinator 与 Worker、Client 通信是通过 REST API。

2）Worker
Worker 是负责执行任务和处理数据。Worker 从 Connector 获取数据。Worker 之间会交 换中间数据。Coordinator 是负责从 Worker 获取结果并返回最终结果给 Client。 当 Worker 启动时，会广播自己去发现 Coordinator，并告知 Coordinator 它是可用，随 时可以接受 Task。 Worker 与 Coordinator、Worker 通信是通过 REST API。

3）数据源
贯穿全文，你会看到一些术语：Connector、Catelog、Schema 和 Table。这些是 Presto 特定的数据源
（1）Connector
Connector 是适配器，用于 Presto 和数据源（如 Hive、RDBMS）的连接。你可以认为 类似 JDBC 那样，但却是 Presto 的 SPI 的实现，使用标准的 API 来与不同的数据源交互。 Presto 有几个内建 Connector：JMX 的 Connector、System Connector（用于访问内建的 System table）、Hive Connector、TPCH（用于 TPC-H 基准数据）。还有很多第三方的 Connector，所以 Presto 可以访问不同数据源的数据。 每个 Catalog 都有一个特定的 Connector。如果你使用 catelog 配置文件，你会发现每个 文件都必须包含 connector.name 属性，用于指定 catelog 管理器（创建特定的 Connector 使用）。 一个或多个 catelog 用同样的 connector 是访问同样的数据库。例如，你有两个 Hive 集群。 你可以在一个 Presto 集群上配置两个 catelog，两个 catelog 都是用 Hive Connector，从而达 到可以查询两个 Hive 集群。
（2）Catelog
一个Catelog包含Schema和Connector。例如，你配置JMX的catelog，通过JXM Connector访问 JXM 信息。当你执行一条 SQL 语句时，可以同时运行在多个 catelog。Presto 处理 table 时，是通过表的完全限定（fully-qualified）名来找catelog。例如， 一个表的权限定名是 hive.test_data.test，则 test 是表名，test_data 是 schema，hive 是 catelog。 Catelog 的定义文件是在 Presto 的配置目录中。
（3）Schema
Schema是用于组织table。把catelog好schema结合在一起来包含一组的表。当通过Presto 访问 hive 或 Mysq 时，一个 schema 会同时转为 hive 和 mysql 的同等概念。
（4）Table
Table 跟关系型的表定义一样，但数据和表的映射是交给 Connector。

2.presto优缺点

** 1.优点**
1）Presto 与 Hive 对比，都能够处理 PB 级别的海量数据分析，但 Presto 是基于内存运 算，减少没必要的硬盘 IO，所以更快。
2）能够连接多个数据源，跨数据源连表查，如从 Hive 查询大量网站访问记录，然后从 Mysql 中匹配出设备信息。
3）部署也比 Hive 简单，因为 Hive 是基于 HDFS 的，需要先部署 HDFS

2.缺点
1）虽然能够处理 PB 级别的海量数据分析，但不是代表 Presto 把 PB 级别都放在内存中 计算的。而是根据场景，如 count，avg 等聚合运算，是边读数据边计算，再清内存，再读 数据再计算，这种耗的内存并不高。但是连表查，就可能产生大量的临时数据，因此速度会 变慢，反而 Hive 此时会更擅长。
2）为了达到实时查询，可能会想到用它直连 MySql 来操作查询，这效率并不会提升， 瓶颈依然在 MySql，此时还引入网络瓶颈，所以会比原本直接操作数据库要慢。

presto连接hive脚本

/data/presto-server-0.239.1/bin --server core1:8080 --catalog hive --schema default

##执行sql语句
/data/presto-server-0.239.1/bin/presto-cli --server core1:8080 --catalog hive --execute 'show SCHEMAS;select * from agent_crm.iso_3166code'

##执行sql文件
/data/presto-server-0.239.1/bin/presto-cli  --server core1:8080 --catalog hive -f /data/presto-server-0.239.1/jobs/product_function_module/presto_product_function_module.sql

3.查询 SQL 优化

1）只选择使用必要的字段
2）过滤条件加上分区字段
3）Group By 语句优化，合理安排 Group by 语句中字段顺序对性能有一定提升。将 Group By 语句中字段按照每 个字段 distinct 数据多到少进行降序排列。
4）用 regexp_like 代替多个 like 语句
5）使用 Join 语句时将大表放在左边，Presto 中 join 的默认算法是 broadcast join，即将 join 左边的表分割到多个 worker，然后 将 join 右边的表数据整个复制一份发送到每个 worker 进行计算。如果右边的表数据量太大， 则可能会报内存溢出错误。