presto领读 查询引擎翻译

原文链接：https://prestodb.io/docs/current/overview/concepts.html#data-sources

 

最近在看presto-分布式SQL查询引擎的代码，使用翻译工具翻译了一版，有些概念比较难以理解，整理如下：

一、概览

 

虽然很容易理解语句和查询，但作为最终用户，您应该熟悉一些概念，例如stage和split，以充分利用Presto执行有效的查询。作为一个Presto管理员或一个Presto贡献者，您应该理解Presto的阶段映

射到任务的概念，以及任务如何包含一组处理数据的驱动程序。

这一节为整个Presto中引用的核心概念提供了一个可靠的定义，这些部分按照通用程度进行了排序。

二、服务节点类型

Presto中的服务节点有两种具体类型：Coordinator和Worker。下面的章节会具体介绍他们之间的区别。

2.1 Coordinator

Presto中的Coordinator节点负责解析查询语句、生成查询计划并调度Presto的Worker节点。它是Presto架构中的“大脑”并且也是presto client连接和提交执行语句的对象。每一个Presto集群都必须有

一个Presto Coordinator和至少一个Worker节点。在开发和测试过程中，单个Presto实例可以通过配置来同时具有这两种角色。

Coordinator节点会保持对Worker节点的监听并且协调一次查询中的执行过程。Coordinator节点会创建一个包含一系列stage的查询逻辑模型，然后将这些stage转换为一系列的连接任务，运行在

Presto集群中的Worker节点上。

Coordinator和Worker节点以及client之间通过REST API来进行通信。

2.2 Worker

Worker节点在Presto集群中负责执行任何和处理数据。Worker节点从连接中获取数据并相互交换中间数据。Coordinator节点负责从Worker节点上获取数据并返回最终结果到client上。

当一个Presto的Worker启动时，它会将自身信息广播到Coordinator中的发现服务中，这使得它在Presto的Coordinator节点的任务执行中是可用的。

Worker节点和其他Worker节点以及Coordinator节点通过REST API进行通信。

三、数据源

本文整体介绍了Presto中的connector、catalog、schema和table等概念。这些在Presto中用于描述特定数据源的基础信息将会在本章进行具体介绍。

3.1 Connector

Connector让Prestor能够适配诸如Hive或是关系型数据库。你可以认为Connector是一种数据库驱动。它由Presto的SPI实现，允许Presto通过标准API和外部资源进行交互。

Presto具有几个内置的Connector：JMX Connector，提供对于内置系统table的系统Connector，Hive Connector和用于提供TPC-H基准数据的TPCH Connector。除此之外，许多第三方开发者也向

Presto贡献了不同数据源的Connector。

每个Catalog都和一个指定的Connector绑定。如果你检查Catalog的配置文件，就会发现每一个Catalog都包含了一个强制的属性connector.name，用于Catalog Manager来针对给定的Catalog创建

Connector。在Presto，可以支持多个Catalog使用相同的Connector来访问两个类似的不同数据库实例。例如，如果你有两个Hive集群，你可以在一个Presto集群中配置两个都是用Hive Connector的Catalog，允许用户从两个Hive集群中查询数据（甚至在一个查询SQL中也支持）。

3.2 Catalog

一个Presto中的Catalog维护了Schema信息和通过Connector连接的数据源信息。例如，你可以使用JMX Connector配置一个JMX Catalog来提供对JMX信息的访问。当你再Presto上运行一个SQL语

句时，实际上是在一个或多个Catalog上运行。

在Presto中对一个table进行寻址时，表的全限定名称总是在Catalog中管理。例如，hive.test_data.test的全限定表名会指向hive catalog的test_data schema中的test table。

Catalog在Presto的配置路径中存储的属性文件中定义。

3.3 Schema

Schema是一种组织表的方式。Catalog和Schema定义了一组可以被查询的table集合。当在Presto中访问Hive或是类似于MySQL的关系型数据库时，Schema会将概念转换为目标数据库中的对应概

念。其他类型的Connector可以选择以一种对底层数据源有意义的方式将tale以Schema的形式组织管理起来。

3.4 Table

Table是一组以有类型的命名列组织起来的无序行的集合。这在任何关系型数据库中都是一样的。从元数据到table的映射关系定义在Connector中。

四、查询执行模型

Presto执行SQL语句并将这些语句转换为执行在由Coordinator和Worker的分布式系统中的查询。

4.1 Statement

Presto执行与ANSI标准兼容的SQL语句。当Presto文档引用一个查询语句时，它指的是ANSI SQL标准中定义的查询语句，包含子句、表达式和谓词。

一些堵着可能会好奇为什么本章把Statement和Query两个概念进行了分离。这是必须的，因为，在Presto中，语句只指向SQL语句的文本标识。在执行语句时，Presto会创建一个查询和一个执行计划，它们会在Presto的Worker节点集合中进行分发。

4.2 Query

当Presto解析一个语句时，它将其转换为一个查询，并创建一个分布式查询计划，然后将其实现为在Presto Worker节点上上运行的一系列相互连接的阶段。当你在Presto中检索有关查询的信息时，您

将接收到为响应语句而生成结果集所涉及的每个组件的快照。

Statement和Query之间的区别是很简单的。一个Statement是传递给Presto的SQL文本，然而一个Query指的是用于执行Statement而创建的一系列配置项和组件。Query包含stage、task、split、

connector和其他配置以及为产生结果集而协作的data source。

4.3 Stage

当Presto执行查询时，它通过将查询执行过程拆分为分层stage来达成目的。例如，如果Presto需要对存储在Hive中的亿级别的数据进行聚合，它会创建一个根stage来对多个stage的输出，所有这些阶

段的设计都是为了实现分布式查询计划的不同部分。

构成一个Query的层次stage结构类似树。每个Query都有一个根stage，来负责聚合其他stage的输出。Coordinator使用Stage用来对分布式查询进行建模，但是stage本身并不会在Presto的Worker节

点上运行。

4.4 Task

如上章所说，stage对一个分布式查询计划进行建模，但是stage自身不会在Presto的Worker节点上运行。为了理解stage是如何执行的，我们需要了解stage是由分布在Presto集群中的Worker节点上

task集合实现的。

任务是Presto架构中的“work horse”，因为分布式查询计划被分解为一系列的阶段，然后被翻译成任务，然后执行或处理分割。一个Presto任务有输入和输出，就像一个阶段可以并行执行一系列任务

一样，一个任务与一系列驱动程序并行执行。

4.5 Split

任务是在一个大数据集上分段进行的。分布式查询计划的最底层stage会执行从split的Connector中检索数据的操作，并且分布式查询计划的高层中间stage会从其他stage上检索数据。

当Presto调度一个查询时，Coordinator会向一个Connector查询可用于表的split的所有列表。Coordinator会跟踪哪些机器正在运行哪些任务、哪些任务正在处理哪些split。

4.6 Driver

Task包含一个或多个并行Driver。Driver在数据上运行并且结合运算符来生产输出，这些输出稍后将会由一个task来进行聚合并传递给另外一个stage中的另外一个task上。Driver是一组Operator实例的

序列，或者你可以认为Driver是一组内存中的Operator的物理集合。它是Presto架构中的最低级的并行性。一个Driver会有一个输入和一个输出。

4.7 Operator

Operator消费、转换并生成数据。例如，一个table scan fetch可以从Connector中获取数据，并生成可以被其他Operator消费的数据，一个文件operator消费数据并且通过在输入数据上运行一个谓词

来产生一个数据子集。

4.8 Exchange

Exchange在Presto节点上为单次查询的不同stage来传输数据。Task向output缓存产生数据并且通过一个exchange client消费其他task产生的数据。