Presto中的基础概念

翻译 2018年04月15日 19:33:11

https://prestodb.io/docs/current/overview/concepts.html#data-sources

目录

一、概览

要理解Presto,您必须首先理解整个Presto文档中使用的术语和概念。

虽然很容易理解语句和查询,但作为最终用户,您应该熟悉一些概念,例如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产生的数据。


企业级大数据架构指南(hadoop\kafka\spark\presto\elk)

不论实时分析还是离线计算,一套好的技术架构能够起到事半功倍的效果,一线大数据架构师亲述企业级大数据架构之路
  • 2017年04月27日 17:26

近实时运算的利器---presto在公司实践

1.起因 公司hadoop集群里的datanonde和tasktracker节点负载主要集中于晚上到凌晨,平日工作时间负载不是很高。但在工作时间内,公司业务人员有实时查询需求,现在主要 借助于hive...
  • joomlaer
  • joomlaer
  • 2015-05-21 11:45:46
  • 23970

Presto、Impala性能比较

下面是Presto、Impala这两种典型的内存数据库的简单测试比较,当然这种内存数据库类似的还有spark sql,这种数据库在大数据量,多表关联查询时,会展现出自己的优势,下面是一组impala和...
  • u012551524
  • u012551524
  • 2018-01-22 01:32:09
  • 1469

Presto实现原理和美团的使用实践

 Presto实现原理和美团的使用实践 Facebook的数据仓库存储在少量大型Hadoop/HDFS集群。Hive是Facebook在几年前专为Hadoop打造的一款数据仓库工具。在...
  • starzhou
  • starzhou
  • 2015-03-27 21:05:09
  • 836

presto测试

hadoop用来做数据仓库的主流技术HIVE比重比较大,支持SQL是原因之一。除此之外,还有一个原因是HADOOP生态圈能够用来作为仓库技术的实际并不多,但是HIVE的缺陷也很明显,那就是慢,因此才有...
  • tom_fans
  • tom_fans
  • 2018-02-01 18:09:53
  • 86

presto的安装与部署(对接kafka)

Preston 官网:http://prestodb.io/ Preston Github 主页:https://github.com/facebook/presto 一 安装环境 操作系统:Ce...
  • ouyang111222
  • ouyang111222
  • 2016-01-12 23:19:43
  • 4289

Presto阅读源码记录(Sql执行过程)

前言 Presto源码主要从两部分入手阅读,presto-cli与presto-main分别对应的是client端的入口与server端的入口工程。 版本如下 com.facebook.pres...
  • q2365921
  • q2365921
  • 2018-02-01 20:31:32
  • 172

数据仓库(十二)---分布式SQL查询引擎---teradata版本的presto安装和使用

我们在使用presto过程中,发现facebook原版和京东原版都是 解压可用,teradata版本的安装要麻烦一些。 下面对teradata版本的安装过程进行记录。 首要条件 1、需要pyth...
  • q383965374
  • q383965374
  • 2018-03-02 17:32:21
  • 49

OLAP OLTP presto、druid、sparkSQL、kylin的对比分析,如性能、架构等,有什么异同?

https://www.zhihu.com/question/41541395?sort=created https://www.cnblogs.com/andy6/p/6011959.html ...
  • z69183787
  • z69183787
  • 2017-11-22 17:59:52
  • 1088

presto集群安装以及集成kerberos

博客地址:http://www.fanlegefan.com 文章地址:http://www.fanlegefan.com/index.php/2017/07/31/prestokerberos/ p...
  • woloqun
  • woloqun
  • 2017-08-01 22:06:46
  • 954
收藏助手
不良信息举报
您举报文章:Presto中的基础概念
举报原因:
原因补充:

(最多只允许输入30个字)