Presto

最新推荐文章于 2026-07-24 20:23:06 发布

原创最新推荐文章于 2026-07-24 20:23:06 发布 · 1.8k 阅读

39 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

Presto

在这里插入图片描述

Presto是一个由Facebook开源的分布式SQL查询引擎，适用于交互式分析查询，数据量支持GB到PB字节。它被设计为使用MapReduce作业（如Hive或Pig）的管道查询HDFS的工具的替代品，但Presto不限于访问HDFS。Presto可以扩展到在不同类型的数据源上运行，包括传统的关系数据库和其他数据源。Presto提供了SQL的解析和标准数据库的功能，但是它是不能替代MySQL、PostgreSQL或Oracle等数据
库，它不是为处理在线事务处理（OLTP）而设计的。Presto旨在处理数据仓库和分析：数据分析、聚合大量数据和生成报告。这些工作负载通常被分类为联机分析处理（OLAP）

Presto是一个分布式的查询引擎，本身是不具备存储功能的
Presto可接入多种数据源，并支持跨数据源的数据查询计算
与mysql对比
与Hive对比
优点
- Presto与Hive对比，都能够处理PB级别的海量数据分析，但Presto是基于内存运算，减少没必要的硬盘IO，所以更快
- 能够连接多个数据源，跨数据源连表查，如从Hive查询大量网站访问记录，然后从Mysql中匹配出设备信息。
- 部署也比Hive简单，因为Hive是基于HDFS的，需要先部署HDFS。
缺点
- 虽然能够处理PB级别的海量数据分析，但不是代表Presto把PB级别都放在内存中计算的。而是根据场景，如count，avg等聚合运算，是边读数据边计算，再清内存，再读数据再计算，这种耗的内存并不高。但是连表查，就可能产生大量的临时数据，因此速度会变慢，反而Hive此时会更擅长。
- 为了达到实时查询，可能会想到用它直连MySql来操作查询，这效率并不会提升，瓶颈依然在MySql，此时还引入网络瓶颈，所以会比原本直接操作数据库要慢。

Presto的模型架构

系统架构

在这里插入图片描述

presto集群是master worker架构，有如下几个组件：

Coordinator
- Coordinator 服务器是用来解析语句，执行计划分析和管理 Presto 的 Worker 节点。Presto 安装必须有一个 Coordinator 和多个 Worker。如果用于开发环境和测试，则一个 Presto 实例可以同时担任这两个角色。
- Coordinator 跟踪每个 Work 的活动情况并协调查询语句的执行。Coordinator 为每个查询建立模型，模型包含多个Stage，每个Stage再转为Task 分发到不同的 Worker 上执行。
Discovery server
- 只能有一个，负责维护coordinator和worker节点关系，worker节点启动后向discovery service服务注册，coordinator通过discovery service获取注册的worker节点以及catalog，通常内嵌于coordinator节点中。
Worker
- Worker 是负责执行任务和处理数据。Worker 从 Connector 获取数据。Worker 之间会交换中间数据。Coordinator 是负责从Worker 获取结果并返回最终结果给 Client。
- 当 Worker 启动时，会广播自己去发现 Coordinator，并告知 Coordinator 它是可用，随时可以接受 Task。
Catalog
- 一个 Catelog 包含 Schema 和 Connector，对应了某一类的数据源
Connector
- Connector 是适配器，用于 Presto 和数据源（如 Hive、RDBMS）的连接，每个 Catalog 都有一个特定的 Connector
Schema
- Schema 是用于组织 table。把 catelog 和 schema 结合在一起来包含一组的表，Schema对应了某一类数据源的数据库
Table
- Table 跟关系型的表定义一样，但数据和表的映射是交给 Connector。

SQL执行流程

在这里插入图片描述

解析器：coordinator接收到SQL之后，通过解析器将SQL转换成抽象语法树AST
逻辑计划器：SQL语法正确，会通过connector将meta表中的schema、列名、列的数据类型进行对比是否与SQL中一致，对性能进行优化，生成逻辑执行计划，
分发计划器：将逻辑执行计划进行分布式解析分发到执行器中
执行器：将逻辑执行计划转换成物理执行计划分发到对应的worker中去执行

MapReduce vs Presto

在这里插入图片描述

MapReduce：每次执行任务中间结果需要写磁盘，计算的时候需要从磁盘中拿，导致速度很慢
Presto：Task是在每个worker上执行的，每个Task执行完之后数据还是存放在内存里的，多个Task之间需要进行数据交换的时候直接从内存中拿。

环境搭建

上传安装
- [root@node01 ~]# tar -zxf presto-server-0.279.tar.gz
- [root@node01 ~]# mv presto-server-0.279 /opt/yjx/
- [root@node01 ~]# rm -rf presto-server-0.279.tar.gz

配置文件

注意：解压之后并不会有etc文件夹，需要我们自己去创建
[root@node01 presto-server-0.279]# mkdir etc

需要配置文件：

node.properties: 每个节点的环境配置
jvm.config : JVM参数配置
config.properties: Presto 服务配置
xx_catalog.properties: 数据源连接器配置 xx_catalog.properties

创建node.properties
[root@node01 etc]# vim node.properties

# 部署环境名称，全集群统一
node.environment=yjxxt
# 节点id，每个节点唯一
node.id=1
# 数据存储路径
node.data-dir=/var/yjx/presto-data

创建jvm.config
[root@node01 etc]# vim jvm.config

-server
#最大堆内存
-Xmx3G
#使用G1垃圾回收器
-XX:+UseG1GC
-XX:G1HeapRegionSize=32M
-XX:+UseGCOverheadLimit
-XX:+ExplicitGCInvokesConcurrent
-XX:+HeapDumpOnOutOfMemoryError
-XX:+ExitOnOutOfMemoryError

创建config.properties

[root@node01 etc]# vim config.properties

#是否运行该实例为coordinator（接受client的查询和管理查询执行）。
coordinator=true
#：表示，将coordinator兼作worker，线上应false
node-scheduler.include-coordinator=true
#指定HTTP端口。Presto使用HTTP来与外部和内部进行交流。
http-server.http.port=18080
#单个query在整个集群上可以使用的最大用户内存
query.max-memory=1GB
# 单个query在整个集群可以使用的最大的总内存（系统内存+用户内存）
query.max-total-memory=2GB
#单个query在每个节点上能使用的最大用户内存，比如：排序等操作,超出限制将kill
query.max-memory-per-node=1GB
##单个query在每个节点上能使用的最大总内存（用户内存+系统内存），该参数据包括上一个参数，多出系统所用内存，比如系统分配读写等，超出限制将kill
query.max-total-memory-per-node=2GB
# Presto使用Discovery服务去找到集群中的所有结点。每个Presto实例在启动时都会在Discovery服务里注册。这样可以简化部署， 不需要额外的服务，Presto的coordinator内置一个Discovery服务。也是使用HTTP端口。
discovery-server.enabled=true
#Discovery服务的URI。为coordinator的host和端口。这个URI不能以斜杠结尾，这个错误需特别注意，不然会报404错误。
discovery.uri=http://node01:18080

数据分发

[root@node01 ~]# scp -r /opt/yjx/presto-server-0.279/ root@node02:/opt/yjx/
[root@node01 ~]# scp -r /opt/yjx/presto-server-0.279/ root@node03:/opt/yjx/

修改work节点配置
[root@node02 ~]# vim /opt/yjx/presto-server-0.279/etc/node.properties

#修改节点id
node.id=2

[root@node03 ~]# vim /opt/yjx/presto-server-0.279/etc/node.properties

#修改节点id
node.id=3

[root@node02 ~]# vim /opt/yjx/presto-server-0.279/etc/config.properties

#修改worker节点coordinate=false
coordinator=false
#注释node-scheduler.include-coordinator
#node-scheduler.include-coordinator=true
#注释discovery-server.enabled
#discovery-server.enabled=true

[root@node03 ~]# vim /opt/yjx/presto-server-0.279/etc/config.properties

#修改worker节点coordinate=false
coordinator=false
#注释node-scheduler.include-coordinator
#node-scheduler.include-coordinator=true
#注释discovery-server.enabled
#discovery-server.enabled=true

连接配置

创建存放连接配置的文件夹

[root@node01 etc]# mkdir catalog

hive连接配置

[root@node01 catalog]# vim hive.properties

# 这里命名需要为官网指定命名
connector.name=hive-hadoop2
# 获取hive配置文件
hive.config.resources=/opt/yjx/hadoop-3.3.4/etc/hadoop/core-site.xml,/opt/yjx/hadoop-3.3.4/etc/hadoop/hive-site.xml,/opt/yjx/hadoop-3.3.4/etc/hadoop/hdfs-site.xml
# 配置元数据服务地址
hive.metastore.uri=thrift://node01:9083

Mysql连接配置
[root@node01 catalog]# vim mysql.properties

# 这里命名需要为官网指定命名
connector.name=mysql
connection-url=jdbc:mysql://node01:3306?useSSL=false&useUnicode=true&characterEncoding=UTF8&serverTimezone=GMT
connection-user=root
connection-password=123456

配置分发

[root@node01 etc]# scp -r catalog/ root@node02:`pwd`
[root@node01 etc]# scp -r catalog/ root@node03:`pwd`

启动presto

注：我们这里测试的是Hive和mysql的连接，在启动之前优先保证Hive和mysql已启动
- 前台启动Presto，控制台显示日志
```
[root@node123 presto-server-0.279]# bin/launcher run
```
- 后台启动Presto
```
[root@node01 presto-server-0.279]# bin/launcher start
```
- WebUI查看情况，这里我们配置的地址是：node01:18080

连接使用

客户端命令行

下载jar包

修改名称为presto，执行chmod +x

[root@node01 ~]# mv presto-cli-0.279-executable.jar presto
[root@node01 ~]# chmod +x presto

./presto --server node01:18080 --catalog hive --schema default

退出
```
exit
```

参数说明

server ：presto服务地址
catalog ：配置连接的数据源（需要在集群中的指定文件夹中配置好）
schema ：配置连接的数据库

可视化连接DataGrip

标签

#hive #sql