论文领读：Presto: SQL on Everything

本篇论文是Facebook 2019年发表介绍Presto的综述类论文，本篇论文从Presto的使用示例、架构、系统设计等几个方面系统的介绍了Presto的内核和实现原理，对于通识性的了解Presto有一定帮助。
注：本篇论文中所介绍的Presto版本是0.211版本，当时Presto还没分裂出PrestoDB和PrestoSQL。

一、Presto介绍

Presto作为一个分布式查询引擎，于2013年开始就已经在Facebook的生产环境中使用。并且如今已经在Uber、Netflix、Airbnb、Bloomberg以及LinkedIn这样的大公司中使用。
Presto具有自适应、灵活以及可扩展等特性。Presto提供了标准的ANSI SQL接口来查询存储于各系统中的数据，如Hadoop、RDBMS、NoSQL数据库中的数据，以及Kafka这样的流式组件中的数据（Presto中内置了非常多的connectors供用户使用）。Presto对外提供了开放式的HTTP API、提供对JDBC的支持并且支持商业标准的BI的查询工具（如Tableau）。其内置的Hive connector源生支持对HDFS或Amazon S3上的文件进行读写，并且支持多种流行的开源文件格式，包括ORC、Parquet以及Avro。

二、Presto在Facebook的使用示例

1.Interactive Analytics（交互式分析）

Facebook内运行着一个庞大的多租户数据仓库，一些业务部门或个别团队会共享其中一小部分托管的集群。其数据存储在一个分布式文件系统之上，而元数据则存储在单独的服务中，这些系统分别具有HDFS和Hive Metastore服务类似的API。
Facebook的工程师经常会检索少量的数据(50GB-3TB的压缩数据)，用来验证假设，并构建可视化的数据展板。这些用户通常会使用查询工具、BI工具或Jupyter notebooks来进行查询操作。各个群集需要支持50-100的并发查询能力，并且对查询响应时间非常敏感。而对于某些探索性的查询，用户可能并不需要获取所有的查询结果。通常在返回初始结果后，查询就会被立即取消或者用户会通过LIMIT来限制系统返回的结果。

2.Batch ETL （批量ETL）

上面我们介绍到的数据仓库会使用ETL查询任务定期填充新的数据。查询任务通常是通过一个工作流系统依次调度执行的。Presto支持用户从历史遗留的批处理系统迁移ETL任务，目前ETL查询任务在Facebook的Presto工作负载中占了很大一部分。这些查询通常是由数据工程师开发并优化的。相对于Interactive Analytics中涉及的查询，它们通常会占用更多的硬件资源，并且会涉及大量的CPU转换和内存（通常是数TB的分布式内存）密集型的计算，例如大表之间的join及聚合。因此相对于资源利用率以及集群吞吐量来说，查询延迟不是首要关注的。

3.A/B Testing （A/B测试）

Facebook使用A/B测试，通过统计假设性的测试来评估产品变更带来的影响。在Facebook大量的A/B测试的基础架构是基于Presto构建的。用户期望测试结果可以在数小时之内呈现（而不是数天），并且结果应该是准确无误的。对于用户来说，能够在交互式延迟的时间内（5~30s），对结果数据进行任意切分来获得更深入的见解同样重要。而通过预处理来聚合这些数据往往很难满足这一需求，因此必须得实时计算。生成这样的结果需要关联多个大型数据集，包括用户、设备、测试以及事件属性等数据。由于查询是通过编程方式实现的，所以查询需要被限制在较小的集合内。

4.Developer/Advertiser Analytics（开发者/广告主分析）

为外部开发者和广告客户提供的几种自定义报表工具也都是基于Presto构建的。Facebook Analytics就是其中一个实际案例，它为使用Facebook平台构建应用程序的开发人员提供了高级的分析工具。这些工具通常对外开放一个Web界面，该界面可以生成一组受限的查询模型。查询需要聚合的数据量是非常大的，但是这些查询是有目的性的，因为用户只能访问他们的应用程序或广告的数据。大部分的查询包括连接、聚合以及窗口函数。由于这些工具是交互式的，因此有非常严格的查询延迟限制（约50ms~5s）。鉴于用户的数量，集群需要达到99.999%的高可用，并且支持数百个并发查询。

三、Presto架构概览

一个Presto集群需要由一个Coordinator以及一个或多个Worker节点组成。Coordinator主要负责接收查询请求、解析语句、生成计划、优化查询以及查询调度。Worker节点主要负责查询处理。如下所示的即为Presto架构：

整体的执行流程可以简述如下：
客户端向Coordinator发送一个包含sql的http请求。Coordinator接收到这个请求，会通过评估队列策略，解析和分析sql文本，创建和优化分布式执行计划来处理请求。
Coordinator将执行计划分发给Worker节点，接着Worker节点开始启动tasks并且开始枚举splits，而这些splits是对外部存储系统中可寻址的数据块的一种隐晦处理。Splits会被分配给那些负责读取数据的tasks。
Worker节点运行这些tasks来处理从外部存储系统获取的splits，以及来自于其他Worker节点处理过得中间数据。Worker节点之间通过多任务合作机制来并发处理来自不同查询的tasks。任务尽可能的以流水线的方式来执行，这使得数据可以在tasks之间进行流动。对于某些特定的查询，Presto能够在处理完所有数据之前就返回结果。中间数据以及状态会尽可能地存储在内存中。当在节点之间对数据进行shuffle时，Presto会调整缓冲区来达到最小化的延迟。