Presto【基础 01】简介+架构+数据源+数据模型+特点（一篇即可入门支持到PB字节的分布式SQL查询引擎Presto）

淩亂°似流年 2023-09-28 10:58 22阅读 0赞

## 1. 简介 ##

Presto 是一个 facebook 开源的`分布式SQL查询引擎`，主要用来处理响应时间小于1秒到几分钟的场景。 适用于`交互式分析查询`，`数据量支持GB到PB字节`。支持在线数据查询，包括 Hive，关系数据库（MySQL、Oracle）以及专有数据存储。查询可以将多个数据源的数据进行合并，可以跨越整个组织进行分析。它的架构由关系型数据库的架构演化而来。它能在各个内存计算型数据库中脱颖而出，在于以下几点：

1.  清晰的架构，是一个能够独立运行的系统，不依赖于任何其他外部系统。例如调度，Presto 自身提供了对集群的监控，可以根据监控信息完成调度。
2.  简单的数据结构，列式存储，逻辑行，大部分数据都可以轻易的转化成 Presto 所需要的这种数据结构。
3.  丰富的插件接口，完美对接外部存储系统，或者添加自定义的函数。

![在这里插入图片描述][eb7df06199a4451682a7836d8f5ae1af.png_pic_center]

> 需要注意的是：虽然 Presto 可以解析SQL，但它不是一个标准的数据库。不是MySQL、Oracle的代替品，也不能用来处理在线事务（OLTP）。

## 2. 架构 ##

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

![在这里插入图片描述][c293cb01e83747d7a27df781a87f20bf.png_pic_center]

### 2.1 Coordinator ###

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

### 2.2 Worker ###

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

### 2.3 数据源 ###

Presto特定的数据源：Connector、Catalog、Schema 和 Table。

1.  Connector `n. 连接器，连接头`

>  *  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。如果使用 Catalog 配置文件，每个文件都必须包含connector.name 属性，用于指定 Catalog 管理器（创建特定的 Connector 使用）。一个或多个 Catalog 用同样的 connector 是访问同样的数据库。例如，有两个Hive集群。可以在一个 Presto 集群上配置两个 Catalog，两个 Catalog 都是用 Hive Connector，从而达到可以查询两个 Hive 集群的目的。

1.  Catalog `n. [图情][计]目录；登记`

>  *  一个 Catalog 包含 Schema 和 Connector。例如，配置 JMX 的 Catalog，通过 JXM Connector 访问 JXM 信息。当执行一条SQL语句时，可以同时运行在多个 Catalog。
>  *  Presto 处理 table 时，是通过表的完全限定（fully-qualified）名来找到 Catalog。例如，一个表的权限定名是 hive.test\_data.test，则 test 是表名，test\_data 是 Schema，Hive 是 Catalog。
>  *  Catalog 的定义文件是在 Presto 的配置目录中。

1.  Schema `n. [计][心理] 模式；计划；图解；概要`

>  *  Schema 是用于组织 table。当通过 Presto 访问 Hive 或 MySQL 时，一个 Schema 会同时转为 Hive 或 MySQL 的同等概念。

1.  Table

>  *  Table 跟关系型的表定义一样，但数据和表的映射是交给 Connector。

### 2.4 数据模型 ###

> 1）Presto 的三层表结构

*  Catalog：对应某一类数据源，例如 Hive 的数据，或 MySQL 的数据。
 *  Schema：对应特定数据源中的数据库。
 *  Table：对应特定数据库中的表。

![在这里插入图片描述][3809e82d380b4ed29ca2888de6e72367.png_pic_center]

> 2）Presto 的存储单元

*  Page：多行数据的集合，包含多个列的数据，内部仅提供逻辑行，实际以列式存储。
 *  Block：一列数据，根据不同类型的数据，通常采取不同的编码方式，了解这些编码方式，有助于自己的存储系统对接 Presto。

![在这里插入图片描述][b351ea4b0c024ef29b8ba3022227b388.png_pic_center]

> 3）不同类型的Block

*  Array 类型的，应用于固定宽度的类型，例如 int，long，double。Block 由两部分组成：

1.  boolean valueIsNull\[\] 表示每一行是否有值。
2.  T values\[\] 每一行的具体值。

*  可变宽度的，应用于 String 类数据，由三部分信息组成

1.  Slice：所有行的数据拼接起来的字符串。
2.  int offsets\[\]：每一行数据的起始便宜位置。每一行的长度等于下一行的起始便宜减去当前行的起始便宜。
3.  boolean valueIsNull\[\] 表示某一行是否有值。如果有某一行无值，那么这一行的便宜量等于上一行的偏移量。

*  固定宽度的String类型的，所有行的数据拼接成一长串Slice，每一行的长度固定。
 *  字典：对于某些列，distinct 值较少，适合使用字典保存。主要有两部分组成：

1.  字典，可以是任意一种类型的 block（甚至可以嵌套一个字典block），block 中的每一行按照顺序排序编号。
2.  int ids\[\]表示每一行数据对应的 value 在字典中的编号。在查找时，首先找到某一行的id，然后到字典中获取真实的值。

## 3. 特点 ##

### 3.1 与MapReduce对比 ###

Presto 中 SQL 运行过程与 MapReduce 对比：  
![在这里插入图片描述][f7cdbb5d038547d381fc266c55e49b10.png_pic_center]

> **所有阶段均采用管道连接，无需等待时间，无需容错系统，内存到内存数据传输，无需磁盘IO，数据块必须适合内存。**

### 3.2 与Hive对比 ###

1）Presto 与 Hive 对比，都能够处理PB级别的海量数据分析，由于 Presto 是基于内存运算，所以减少没必要的硬盘 IO，所以更快。【硬件成本较高】  
2）能够连接多个数据源，跨数据源连表查询，如从 Hive 查询部分，然后从 MySQL 中匹配相关信息。  
3）部署也比 Hive 简单，因为 Hive 是基于 HDFS 的，需要先部署 HDFS。

![在这里插入图片描述][24ffcc2db64f4a02b5db00b95dbf5641.png_pic_center]

### 3.3 缺点 ###

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

[eb7df06199a4451682a7836d8f5ae1af.png_pic_center]: https://img-blog.csdnimg.cn/eb7df06199a4451682a7836d8f5ae1af.png#pic_center
[c293cb01e83747d7a27df781a87f20bf.png_pic_center]: https://img-blog.csdnimg.cn/c293cb01e83747d7a27df781a87f20bf.png#pic_center
[3809e82d380b4ed29ca2888de6e72367.png_pic_center]: https://img-blog.csdnimg.cn/3809e82d380b4ed29ca2888de6e72367.png#pic_center
[b351ea4b0c024ef29b8ba3022227b388.png_pic_center]: https://img-blog.csdnimg.cn/b351ea4b0c024ef29b8ba3022227b388.png#pic_center
[f7cdbb5d038547d381fc266c55e49b10.png_pic_center]: https://img-blog.csdnimg.cn/f7cdbb5d038547d381fc266c55e49b10.png#pic_center
[24ffcc2db64f4a02b5db00b95dbf5641.png_pic_center]: https://img-blog.csdnimg.cn/24ffcc2db64f4a02b5db00b95dbf5641.png#pic_center