由于公司的安规要求，不允许又第三方的聊天工具、云盘及笔记，导致有道云无法使用，故将有道云笔记整理发布在CSDN
首先，可以把Presto理解为一个类似ES的搜索引擎，主要是加快各种数据库的实时查询速度。
一、Presto的服务进程：
- Coordinato：Presto的管理节点
Coordinator服务进程部署于集群中一个单独的节点上，是整个Presto集群的管理节点。
Coordinator服务进程主要用于接收客户端提交的查询，查询语句解析，生成查询执行计划、Stage和Task并对生成的Task进行调度。除此之外，Coordinator还对集群中的所有Worker进行管理。Coordinator 进程是整个Presto集群的Master 进程，该进程既与Worker进行通信从而获得最新的Worker信息，又与Client进行通信，从而接受查询请求，而所有的这些工作都是通过Coordinator 上的StatementResource类提供的RESTful服务来完成的。
- Worker：Persto的工作节点
在一个Presto集群中，存在一个Coordinator 节点和多个Worker 节点。Coordinator 节点是管理节点，而Worker节点就是工作节点。在每个Worker节点上都会存在一个Worker服务进程，该服务进程主要进行数据的处理以及Task的执行。Worker服务进程每隔一定的时间都会向Coordinator 上的RESTful服务发送心跳，从而告知Coordinator：我还活着，并接受你的调度。当客户端提交一个查询的时候，Coordinator则会从当前存活的Worker列表中选择出合适的Worker节点去运行Task。而Worker在执行每个Task的时候又会进一步对当前Task读入的每个Spit进行一系列的操作和处理。
二、Presto模型
Presto 可以通过多种不同类型的Connector 访问多种数据源，目前支持的Connector包括：Hive、JMX、MySQL、Cassandra、PostgreSQL以及Kafka。
- Connector（连接器）：通过Connector访问不同数据源，具体如下
Presto是通过多种多样的Connector来访问多种不同的数据源的。你可以将Connector当作Presto访问各种不同数据源的驱动程序。一般情况下，Presto针对每种数据源都有与之对应的Connector。每种Connector都实现了Presto中标准的SPI接口，因此只要你实现Presto中标准的SPI接口，就可以轻易地实现使用适合自己特定需求的Connector来访问特定的数据源。Presto目前可以支持的Connector有 Hive、Kafka、JMX、MySQL、Cassandra等，都有其对应的Build-In Connector（内置的Connector）。
当你需要使用某种Connector 访问特定的数据源时，需要在SPRESTO_HOME/etc/catalog/中创建一个配置文件：example.properties（文件名字无限制，但是其后缀名必须为properties），在该配置文件中必须要设置一个属性：connector.name，该属性是必须设置的。Presto中的Connector Manager 就是通过该配置属性来决定使用哪个Connector去访问相应的数据源的。例如，你现在需要访问一个Hive数据源，那么你在配置文件中就需要将属性connector.name设置为Hive-cdh5或者Hive-cdh4，这样Presto就会使用内置的Hive connector 去访问Hive数据仓库中相应的数据。
- Catalog：可以理解为一个MySQL数据库
Presto中的Catalog类似于MySQL中的一个数据库实例。而Schema就类似于MySQL中的一个Database。通过使用特定的Connector 访问Catalog中指定的数据源，一个Catalog中可以包含多个Schema。那么怎么定义一个Catalog呢？其实你不需要特意去指定Catalog。
假设你想要访问Hive中的数据，则需要在$PRESTO_HOME/etc/catalog/中创建一个配置文件：example.properties。该配置文件中定义了诸如Hive metastore的URI等访问Hive中的数据所需要的所有配置项，并且配置文件的名字就是Catalog的名称：example。从这里可以看出Presto中配置文件的名字（不带.properties）就是Catalog的名字。
当你访问Catalog中的某个表时，该表的全名总是以Catalog的名字开始。例如名字为example.schemal.table1的表，指的是表tablel位于名为schemal的schema中，而schemal又位于名为example的Catalog中。
- Schema：可以理解为MySQL里面的一个数据库
Presto 中的Schema就类似于MySQL中的Database。一个Catalog名称和一个Schema名称唯一确定了可以查询的一系列表的集合。当通过Presto 去查询Hive或者MySQL中的数据时，你会发现Presto中的Schema与Hive或者MySQL中的Database是相对应的。
- Table：就是一张表，不用理解
三、Presto查询执行模型
Presto在执行SQL语句时，将这些SQL语句解析为相应的查询，并在分布式集群中执行这些查询。
- Statement：就是我们输入的SQL语句
Statement语句。其实就是指我们输入的SQL语句。Presto支持符合ANSI标准的SQL语句。这种语句由子句（Clause）、表达式（expression）和断言（Predicate）组成。
Presto为什么将语句（Statement）和查询（Query）的概念分开呢？因为在Presto中，语句和查询本身就是不同的概念。语句指的是终端用户输入的用文字表示的SQL语句；当Presto执行输入的SQL语句时，会根据SQL语句生成查询执行计划，进而生成可以执行的查询（Query），而查询代表的是分布到所有的Worker之间执行的实际查询操作。
- Query：查询执行结果
当Presto接收一个SQL语句并执行时，会解析该SQL语句，将其转变成一个查询执行和相关的查询执行计划。一个查询执行代表可以在Presto集群中运行的查询，是由运行在各个Worker上且各自之间相互关联的阶段（Stage）组成的。
那么SOL语句与查询执行之间有什么不同呢？
其实很简单，你可以认为SQL语句就是提交给Presto的用文字表示的SQL执行语句。
而查询执行则是为了完成SQL语句所表述的查询而实例化的配置信息、组件、查询执行计划和优化信息等。一个查询执行由Stage、Task、Driver、Split、Operator和DataSource组成。
这些组件之间通过内部联系共同组成了一个查询执行，从而得到SQL语句表述的查询，并得到相应的结果集。
- Stage：查询执行阶段
当Presto运行Query时，Presto会将一个Query拆分成具有层级关系的多个Stage，一个Stage就代表查询执行计划的一部分。例如，当我们执行一个查询，从Hive的一张具有1亿条记录的表中查询数据并进行聚合操作时，Presto会创建一个Root Stage（在后面的章节你会知道，该Stage就是Single Stage），该Stage聚合其上游Stage的输出数据，然后将结果输出给Coordinator，并由Coordinator将结果输出给终端用户。
通常情况下，Stage之间是树状的层级结构。每个Query都有一个Root Stage。该Stage用于聚集所有其他Stage的输出数据，并将最终的数据反馈给终端用户。需要注意的是，Stage并不会在集群中实际执行，它只是Coordinator用于对查询执行计划进行管理和建模的逻辑概念。每个Stage（除了Single Stage和Source Stage）都会有输入和输出，都会从上游Stage读取数据，然后将产生结果输出给下游Stage。需要注意的是：Source Stage 没有上游Stage，它从Connector 获取数据。Single Stage没有下游Stage，它的结果直接输出给Coordinator，并由Coordinator输出给终端用户。
Presto中的Stage共分为4种，具体介绍如下。
Coordinator_Only：这种类型的Stage用于执行DDL或者DML语句中最终的表结构创建或者更改。
Single：这种类型的Stage用于聚合子Stage的输出数据，并将最终数据输出给终端用户。
Fixed：这种类型的Stage用于接受其子Stage产生的数据并在集群中对这些数据进行分布式的聚合或者分组计算。
Source：这种类型的Stage用于直接连接数据源，从数据源读取数据，在读取数据的时候，该阶段也会根据Presto对查询执行计划的优化完成相关的断言下发（Predicate PushDown）和条件过滤等。
- Task：Stage的子集
在Presto集群中，一个查询执行被分解成具有层级关系的一系列的Stage，一个Stage又被拆分为一系列的Task。每个Task处理一个或者多个Split。每个Task都有对应的输入和输出。一个Stage被分解为多个Task，从而可以并行地执行一个Stage。Task也采用了相同的机制：一个Task也可以被分解为一个或者多个Driver，从而并行地执行一个Task。
说明：由于一个SQL查询可以被分解为多个前后关联的Stage，而每个Stage中均含有一个或者多个Task，在这里我们约定：按照数据的流向，越靠近数据源的Task越处于上游，越远离数据源的Task越处于下游。
- Driver：Task的子集
一个Task包含一个或者多个Driver。一个Driver其实就是作用于一个Split的一系列Operator的集合。因此一个Driver用于处理一个Split，并且生成相应的输出，这些输出由Task收集并且传送给其下游Stage中的一个Task。一个Driver拥有一个输入和一个输出。
- Operator：一种操作
一个Operator代表对一个Split的一种操作，例如过滤、加权、转换等。一个Operator依次读取一个Split中的数据，将Operator所代表的计算和操作作用于Split的数据上，并产生输出。每个Operator均会以Page为最小处理单位分别读取输入数据和产生输出数据。
Operator每次只会读取一个Page对象，相应地，每次也只会产生一个Page对象。
- Split：分片
Split即分片。一个分片其实就是一个大的数据集中的一个小的子集。而Driver则是作用于一个分片上的一系列操作的集合，而每个节点上运行的Task，又包含多个Driver，从而一个Task可以处理多个Split。其中每一种操作均由一个Operator表示。分布式查询执行计划的源 Stage（Source Stage）通过Connector从数据源获得多个分片。Source Stage对Split处理完毕之后，会将输出传递给其下游Stage（通常其下游Stage的类型为Fixed或者Single）。
当Presto执行一个查询的时候，首先会从Coordinator得到一个表对应的所有Split。然后Presto就会根据查询执行计划，选择合适的节点运行相应的Task处理Split。
- Page：
Page是Presto中处理的最小数据单元。一个Page对象包含多个Block对象，而每个Block对象是一个字节数组，存储一个字段的若干行。多个Block横切的一行是真实的一行数据。一个Page最大为1MB，最多16×1024行数据。Page的结构如图1-1所示。
综上所述，Presto执行查询的模型关系如图1-2所示。
