从 0 到 1 学习 Presto，这一篇就够了

本文已收录github：https://github.com/BigDataScholar/TheKingOfBigData，里面有大数据高频考点，Java一线大厂面试题资源，上百本免费电子书籍，作者亲绘大数据生态圈思维导图…持续更新，欢迎star！

前言

        Presto 作为现在在企业中流行使用的即席查询框架，已经在不同的领域得到了越来越多的应用。本期内容，我会从一个初学者的角度，带着大家从 0 到 1 学习 Presto，希望大家能够有所收获！

1. Presto简介

1. 1 Presto概念

        Presto是 Facebook 推出的一个开源的分布式SQL查询引擎，数据规模可以支持GB到PB级，主要应用于处理秒级查询的场景。Presto 的设计和编写完全是为了解决像 Facebook 这样规模的商业数据仓库的交互式分析和处理速度的问题。

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

1.2 Presto 应用场景

        Presto 支持在线数据查询，包括 Hive，关系数据库（MySQL、Oracle）以及专有数据存储。一条 Presto 查询可以将多个数据源的数据进行合并，可以跨越整个组织进行分析。

        Presto 主要用来处理 响应时间小于 1 秒到几分钟的场景 。

1.3 Presto架构

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

        Presto 有两类服务器：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 特定的数据源

• 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 集群。

• 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 的配置目录中。

• Schema

        Schema 是用于组织 table。把 catelog 和 schema 结合在一起来包含一组的表。当通过Presto 访问 hive 或 Mysq 时，一个 schema 会同时转为 hive 和 mysql 的同等概念。

• Table

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

1.4 Presto 数据模型

        1）Presto 采取三层表结构：

        Catalog：对应某一类数据源，例如 Hive 的数据，或 MySql 的数据

        Schema：对应 MySql 中的数据库

        Table：对应 MySql 中的表

        2）Presto 的存储单元包括：

        Page：多行数据的集合，包含多个列的数据，内部仅提供逻辑行，实际以列式存储。

        Block：一列数据，根据不同类型的数据，通常采取不同的编码方式，了解这些编码方式，有助于自己的存储系统对接 presto。

        3）不同类型的 Block：

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

• boolean valueIsNull[] 表示每一行是否有值。
• T values[] 每一行的具体值

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

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

        （3）固定宽度的 String 类型的 block，所有行的数据拼接成一长串 Slice，每一行的长度固定。

        （4）字典 block：对于某些列，distinct 值较少，适合使用字典保存。主要有两部分组成：

        字典，可以是任意一种类型的 block(甚至可以嵌套一个字典 block)，block 中的每一行按照顺序排序编号。

        int ids[]表示每一行数据对应的 value 在字典中的编号。在查找时，首先找到某一行的 id， 然后到字典中获取真实的值。

1.5 Presto 优缺点

        学习一个新的框架，免不了来探讨一下它的优缺点：

        通过下面一张图，我们来看看 Presto 中 SQL 运行过程：MapReduce vs Presto

        我们可以很明显地感受到，Presto 使用内存计算，减少与硬盘交互

1.5.1 优点

        1）Presto 与 Hive 对比，都能够处理 PB 级别的海量数据分析，但 Presto 是基于内存运算，减少没必要的硬盘 IO，所以更快。

        2）能够连接多个数据源，跨数据源连表查，如从 Hive 查询大量网站访问记录，然后从 Mysql 中匹配出设备信息。

        3）部署也比 Hive 简单，因为 Hive 是基于 HDFS 的，需要先部署 HDFS。

        找了张对比图，大家感受下：
        

1.5.2 缺点

        1）虽然能够处理 PB 级别的海量数据分析，但不是代表 Presto 把 PB 级别都放在内存中计算的。而是根据场景，如 count，avg 等聚合运算，是边读数据边计算，再清内存，再读数据再计算，这种耗的内存并不高。但是连表查，就可能产生大量的临时数据，因此速度会变慢，反而 Hive此时会更擅长。

        2）为了达到实时查询，可能会想到用它直连 MySql 来操作查询，这效率并不会提升， 瓶颈依然在 MySql，此时还引入网络瓶颈，所以会比原本直接操作数据库要慢。

1.6 Presto、Impala性能比较

        Presto 和 Impala这两种典型的内存数据库之间具体的性能测试比较就不详细展开叙述，感兴趣可以去看这篇链接：https://blog.csdn.net/u012551524/article/details/79124532

        我就说下总结的结论：

他们的共同点就是吃内存，当然在内存充足的情况下，并且有规模适当的集群，性能应该会更可观。并且从几次性能的比较查询来看，Impala性能稍领先于presto，但是presto在数据源支持上非常丰富，包括hive、图数据库、传统关系型数据库、Redis等

        大家也可以根据上面的链接，自己也尝试去做下对比测试。

1.7 官网地址

        就在 2020 年 12 月 27 日，prestosql 与 facebook 正式分裂,并改名为trino。分裂之前和之后的官网分别是：https://prestosql.io/ 和 https://trino.io。

1.8 Prestodb VS Prestosql(trino)

        根据目前社区活跃度和使用广泛度,更加推荐 prestosql。具体的区别详见：

        http://armsword.com/2020/05/02/the-difference-between-prestodb-and-prestosql/

2. Presto安装部署

2.1 prestosql 版本的选择

        在 presto330 版本里已经提到，jdk8 只支持到 2020-03 月发行的版本.详情参考:
https://prestosql.io/docs/current/release/release-330.html。在 2020 年 4 月 8 号 presto 社区发布的 332 版本开始，需要 jdk11 的版本.由于现在基本都使 用的是 jdk8，所以我们选择 presto315 版本的,此版本在 jdk8 的环境下是可用的。如果我们生产环境是 jdk8，但是又想使用新版的 presto，可以为 presto 单独指定 jdk11 也可使用。

2.2 集群安装规划

host	coordinator	wor