【论文分享】Presto: SQL on Everything（一）

这篇文章是 Facebook 在 2019 年的顶会 ICDE 上的综述类的文章，本文比较系统的讲解了 Presto 的特性、运行机制、优化措施等，与大家分享。

一、起源

首先来简述一下 Presto 的发展起源，Presto 其实是由 FaceBook 开源的一个 MPP 计算引擎，主要用来以解决 Facebook 海量 Hadoop 数据仓库的低延迟交互分析问题，Facebook 版本的 Presto 更多的是以解决企业内部需求功能为主，也叫 PrestoDB，版本号以 0.xxx 来划分。后来，Presto 其中的几个人出来创建了更通用的 Presto 分支，取名 Presto SQL，版本号以 xxx 来划分，例如 345 版本，这个开源版本也是更为被大家通用的版本。前一段时间，为了更好的与 Facebook 的 Presto 进行区分，Presto SQL 将名字改为 Trino，除了名字改变了其他都没变。不管是 Presto DB 还是 Presto SQL，它们”本是同根生“，因此它们的大部分的机制原理是一样的。本文参照 ICDE 的一篇论文[1]来详细介绍一下 Presto 引擎。

二、特点及场景介绍

1.特点

Presto 引擎相较于其他引擎的特点正如文章标题描述的这样，多源、即席。多源就是它可以支持跨不同数据源的联邦查询，即席即实时计算，将要做的查询任务实时拉取到本地进行现场计算，然后返回计算结果。除此之外，对于引擎本身，它有几个值得关注的特点：

（1）多租户：它支持并发执行数百个内存、I/O 以及 CPU 密集型的负载查询，并支持集群规模扩展到上千个节点；

（2）联邦查询：它可以由开发者利用开放接口自定义开发针对不同数据源的连接器（Connector），从而支持跨多种不同数据源的联邦数据查询；

（3）内在特性：为了保证引擎的高效性，Presto 还进行了一些优化，例如基于 JVM 运行，Code- Generation 等。

2.场景

Presto 的应用场景非常广泛，接下来我们主要介绍几种使用比较广泛的场景进行介绍。

（1）交互式分析：交互式分析主要包括一些数据探查类的操作，可能是一些简单的、低数据量的查询，对于响应时间要求较高。交互式查询也是 Presto 主打的应用场景，Presto 的即席计算特性和内部设计机制就是为了能够更好地支持用户进行交互式分析。可以类比用户基于 Hive 交互式查询 HDFS 中的数据，用户可以基于 Presto 查询各种不同的数据源的数据。

（2）批量 ETL：ETL 是最典型的一类批量操作，它一般针对大数据量进行的一些列转换、计算等操作，一般耗时较长，对响应时间要求较低。

（3）除此之外， Facebook 的 A/B Test 基础架构是基于 Presto 构建的，用户希望在数小时内获得测试结果，并希望数据完整和准确；另外，Facebook 为外部开发人员和广告客户提供的一些自定义报告工具[2]也是基于 Presto 构建的。

三、整体架构

图 1 Presto 架构图

如上图所示，Presto 主要是由 Client、Coordinator、Worker 以及 Connector 等几部分构成，这几个部分互相配合完成“一条 SQL 语句从提交到获取查询结果”整个生命周期。

1.SQL 语句提交

用户或应用通过 Presto 的 JDBC 接口或者 CLI 来提交 SQL 查询，提交的 SQL 最终传递给 Coordinator 进行下一步处理；

2.词/语法分析：

首先会对接收到的查询语句进行词法分析和语法分析，形成一棵抽象语法树（AST）；然后，会通过分析抽象语法树来形成逻辑查询计划，如图 2、图 3 所示。

图 2 查询 SQL

​

3.生成逻辑计划：

图 2 是 TPC-H 测试基准中的一条 SQL 语句，表达的是两表连接同时带有分组聚合计算的例子，经过词法语法分析后，得到 AST，然后进一步分析得到如下的逻辑计划。

图 3 逻辑计划

上图就是一棵逻辑计划树，每个节点代表一个物理或逻辑操作，每个节点的子节点作为该节点的输入。逻辑计划只是一个单纯描述 SQL 的执行逻辑，但是并不包括具体的执行信息，例如该操作是在单节点上执行还是可以在多节点并行执行，再例如什么时候需要进行数据的 shuffle 操作等。