Presto 架构原理与优化介绍| 青训营笔记
# Presto 架构原理与优化介绍| 青训营笔记
这是我参与「第四届青训营 」笔记创作活动的的第 7 天
# 大数据与 OLAP 的演进
什么是大数据?
在信息化时代背景下,由于信息交互,信息存储,信息处理能力大幅增加而产生的数据
什么是 OLAP?
OLAP (OnLine Analytical Processing) 对业务数据执行多维分析,并提供复杂计算,趋势分析和复杂数据建模的能力。是许多商务智能(BI)应用程序背后的技术。现如今 OLAP 已经发展为基于数据库通过 SQL 对外提供分析能力
OLAP VS MapReduce
- MapReduce 代表了抽象的物理执行模型,使用门槛较高
- 与 Mapreduce Job 相比,OLAP 引擎常通过 SQL 的形式,为数据分析、数据开发人员提供统一的逻辑描述语言,实际的物理执行由具体的引擎进行转换和优化。
OLAP 核心概念: 
- 维度
- 度量
常见的 OLAP 引擎:
- 预计算引擎: Kylin, Druid
- 批式处理引 I 擎:Hive, Spark
- 流式处理引擎:Flink
- 交互式处理引擎:Presto, Clickhouse, Doris
Presto 设计理念

Presto 最初是由 facebook 研发的构建于 Hadoop/HDFS 系统之上的 PB 级交互式分析引擎,其具有如下的特点:
- 多租户任务的管理与调度
- 多数据源联邦查询
- 支持内存化计算
- pipeline 式数据处理
有很多公司也基于 Presto 进行了二次开发:
# Presto 基础原理与概念
Presto 是 Facebook 推出的一个开源的分布式 SQL 查询引擎,数据规模可以支持 GB 到 PB 级,主要应用于处理秒级查询的场景。Presto 的设计和编写完全是为了解决像 Facebook 这样规模的商业数据仓库的交互式分析和处理速度的问题。
# 基础概念
# 服务相关

Presto 采用典型的 master-slave 模型:
- coordinator (master) 负责 meta 管理,worker 管理,query 的解析和调度
- 解析 SQL 语句
- 生成执行计划
- 分发执行任务给 Worker 节点
- worker 则负责计算和读写。
- 执行 Task 处理数据
- 与其他 Worker 交互传输数据
- discovery server, 通常内嵌于 coordinator 节点中,也可以单独部署,用于节点心跳。在下文中,默认 discovery 和 coordinator 共享一台机器。
# 数据源相关

Connector:
- 一个 Connector 代表一种数据源。可以认为 Connector 是由 Presto 提供的适配多数据源的统一接口。
Catalog:
- 管理元信息与实际数据的映射关系。一个 Catelog 包含 Schema 和 Connector 。
# Query 相关
Query
- 基于 SQL parser 后获得的执行计划
Stage
- 根据是否需要 shuffle 将 Query 拆分成不同的 subplan,每一个 subplan 便是一个 stage
Fragment
- 基本等价于 Stage,属于在不同阶段的称呼,在本门课程可以认为两者等价
Task
- 单个 Worker 节点上的最小资源管理单元:在一个节点上,一个 Stage 只有一个 Task, 一个 Query 可能有多个 Task
Pipeline
- Stage 按照 LocalExchange 切分为若干 Operator 集合,每个 Operator 集合定义一个 Pipeline.
Driver
- Pipeline 的可执行实体,Pipeline 和 Driver 的关系可类比 程序和进程,是最小的执行单元,通过火山迭代模型执行每一个 Operator.
Split
- 输入数据描述 (数据实体是 Page), 数量上和 Driver 一一对应,不仅代表实际数据源 split,也代表了不同 stage 间传输的数据。
Operator
- 最小的物理算子。
# 数据传输相关

- Exchange:
- 表示不同 Stage 间的数据传输,大多数意义下等价于 Shuffle
- LocalExchange:
- Stage 内的 rehash 操作,常用于提高并行处理数据的能力 (Task 在 Presto 中只是最小的容器,而不是最小的执行单元)
- LocalExchange 的默认数值是 16。
# Presto 组件架构

# 服务发现

Discovery Service:
- Worker 配置文件配置 DiscoveryService 地址
- Worker 节点启动后会向 Discovery Service 注册
- Coordiantor 从 Discovery Service 获取 Worker 的地址
# 通信机制
- Presto Client / JDBC Client 与 Server 间通信
- Http
- Coordinator 与 Worker 间的通信
- Thrift / Http
- Worker 与 Worker 间的通信
- Thrift / Http
Http 1.1 vs Thrift
Thrift 具有更好的数据编码能力,Http 1.1 还不支持头部信息的压缩,Thrift 具有更好的数据压缩率
Presto Worker 的不同状态:
- Active
- InActive
- Shutdown
- 在不影响任何正在运行的任务的情况下关闭服务的能力是服务的一个重要方面(通常称为优雅关闭(graceful shutdown))。在这种状态下 Worker 不接受新的任务,并且开始一个 2 分钟超时时间,在这段时间内尽可能把在该 worker 上的任务跑完,如跑不完 2 分钟过后会将未结束的任务 kill 掉,然后进行关闭 worker
# 小结
- 从服务、数据源、Query、数据传输四个角度,介绍了 Presto 相关的基础概念
- 服务、数据源、Query、数据传输包含哪些基本概念?
- 如何衡量一个任务的并行度(Task 并不是最小的执行单元)
- . 通过服务发现、通信机制、节点状态三方面介绍了 Coordinator 与 Worker 是如何协调和工作的
# Presto 重要机制
# 多租户资源管理
假设 zhnagyanbing 用户,在 Prestio-cli 客户端下提交了一个 sql
select
customer_type,
avg(cost) as a
from
test_table
group by
customer_type
order by
a
limit 10;
2
3
4
5
6
7
8
9
10
# Resource Group
Resource Group:
- 类似 Yarn 多级队列的资源管理方式
- 基于 CPU、MEMORY、SQL 执行数进行资源使用量限制



优点:
- 轻量的 Query 级别的多级队列资源管理模式
缺点:
- 存在一定滞后性,只会对 Group 中正在运行的 SQL 进行判断
# 多租户下的任务调度
- Stage 调度
- Task 调度
- Split 调度
# 物理计划生成
- Antlr4 解析生成 AST
- 转换成 Logical Plan
- 按照是否存在 Shuffle (Exchang 同的 Stage (Fragment)

# Stage 调度
- AllAtOnceExecutionPolicy(同时调度)
- 延迟低,会存在任务空跑的情况
- PhasedExecutionPolicy(分阶段调度)默认调度策略
- 不代表每个 stage 都分开调度,如在 join 查询时,在 build 另外一张表 join 的 hashtable 时,probe 端需要等待 build 端完成后才进行探查。
- 有一定的延迟,节省部分资源
# Task 调度
Task 的数量如何确定:
- Source : 根据数据 meta 决定分配多少个节点
- Fixed:hash partition count 确定,如集群节点数量
- Sink:汇聚结果,一台机器
- Scaled:无分区限制,可拓展,如 write 数据
- Coordinator_Only:只需要 coordinator 参与
选择什么样的节点:
- HARD_AFFINITY:计算、存储 Local 模式,保障计算与存储在同一个节点,减少数据传输
- SOFT_AFFINITY:基于某些特定算法,如一致性 HASH 函数,常用于缓存场景,保证相似的 Task 调度到同一个 Worker
- NO_PREFERENCE:随机选取,常用于普通的纯计算 Task
# Split 调度
- 按照固定的时间片,轮训 Split 处理数据,处理 1s,再重新选择一个 Split 执行
- Split 间存在优先级
- FIFO: 顺序执行,绝对公平
- 优先级调度:快速响应
MultilevelSplitQueue
- 5 个优先级 level 理论上分配的时间占比为 16:8:4:2:1 (2-based)
优势:
- 优先保证小 Query 快速执行
- 保障大 Query 存在固定比例的时间片,不会被完全饿死
# 内存计算
# Pipeline 化的数据处理
Pipeline(按 LocalExchange 折分):
- Pipeline 的引入更好的实现算子间的并行
- 语义上保证了每个 Task 内的数据流式处理

# Back Pressure Mechanism
Presto 是如何实现 Back pressure mechanism 的
- 控制 split 生成流程
- 针对每个 Task 定时检查,如果 OutputBuffers 使用率低于 0.5 (下游消费较快,需要提高生产速度), Split 并发度 + 1
- 控制 Operator 执行速度
- "sink.max-buffer-size" 写入 buffer 的大小控制
- "exchange.max-buffer-size" 读取 buffer 的大小控制
- Buffer 达到最大值时 Operator 会进入阻塞状态
# 多数据源联邦查询
将各个数据源进行统一的抽象,最后由 presto server 进行统一的物理执行。

优点:支持多数据源的联邦查询
缺点:针对不同数据源,还存在许多问题需要解决
- 谓词下推
- 元数据管理与映射(每个数据源都需要单独的一套 catalog 管理)
- 如何针对数据源进行分片操作
# 性能优化
# 常用性能分析工具
# Grafana
埋点、系统指标如 CPU、内存、网络等的可视化界面,时序化的数据展示


# Java 相关指令
- Jstack 查看 Java 线程栈信息,排查是否有死锁或有异常或程行在
- JMX (Java Management Extensions) 是一个为应用程序植入管理功能的框架,常用来做一些监控指标的统计收集
- JMAP & GC 日志等等内存分析工具
# Arthas
arthas 是阿里巴巴开源的 Java 诊断工具,基本使用场景是定位复现一些生产环境比较难以定位问题。可以在线排查问题,以及动态追踪 Java 代码,实时监控 JVM 状态等等。
Arthas 在 presto 常用哪些命令
watch:监控每个函数入参、返回参数、异常等信息

trace:统计函数内每一步的执行时间

# Flame Graphs(火焰图)
火焰图是基于 perf 结果产生的 SVG 图片 (opens new window),用来展示 CPU 的调用栈。
火焰图用于分析热点代码占用大量 cpu, 从而导致服务性能下降的情况。如下图,自底向上为调用关系。上层宽度越宽表示当前函数 cpu 耗时越久,我们关注最宽的函数调用。

# Presto UI
- Query 级别统计信息
- Logical plan
- Stage、Task 信息
- Worker 状态信息
