Presto架构原理与优化介绍 | 青训营笔记

这是我参与「第四届青训营」笔记创作活动的的第7天。

一、本课堂重点内容

大数据与 OLAP 系统的演进，初步认识 Presto，了解其相关设计理念
从服务、数据源、Query、数据传输四个角度介绍 Presto 相关的基础概念
通过服务发现、通信机制、节点状态三方面介绍 Coordinator 与 Worker 是如何协调和工作
常见的性能优化工具

二、详细知识点介绍

1. 概述

大数据与 OLAP 系统的演进
Presto 设计思想

1.1 大数据与 OLAP 的演进

问：什么是大数据？

马丁·希尔伯特：“大数据其实是在2000年后，因为信息化的快速发展。信息交换、信息存储、信息处理三个方面能力的大幅増长而产生的数据。”

问：大数据 = 大规模的数据量？

答：否。

Hadoop：基于廉价机器的存算分离的大规模分布式处理系统。

OLAP(OnLine Analytical processing) 对业务数据执行多维分析，并提供复杂计算，趋势分析和复杂数据建模的能力。是许多商务智能（BI）应用程序背后的技术。
OLAP VS MapReduce

MapReduce 代表了抽象的物理执行模型，使用门槛较高
与 Mapreduce Job 相比，OLAP 引擎常通过 SQL 的形式，为数据分析、数据开发人员提供统一的逻辑述语言，实际的物理执行由具体的引擎进行转换和优化。

OLAP 核心概念：

维度
度量

常见的 OLAP 引掌：

预计算引擎：Kylin，Druid
批式处理引擎：Hive，Spark
流式处理引擎：Flink
交互式处理引擎：Presto，Clickhouse，Doris

1.2 Presto 设计思想

Presto 最初是由 Facebook 研发的构建于 Hadoop/HDFS 系统之上的 PB 级交互式分析引擎，其具有如下的特点：

多租户任务的管理与调度
多数据源联邦查询
支持内存华计算
Pipeline 式数据处理

2. Presto 基础原理和概念

基础概念的介绍
核心组件架构介绍

2.1 基础概念介绍

—— 服务相关

Coordinator
- 解析 SQL 语句
- 生成执行计划
- 分发执行任务给 Worker 节点
Worker
- 执行 Task 处理数据
- 与其他 Worker 交互传输数据

—— 数据源相关

Connector：一个 Connector 代表一种数据源。可以认为 Connector 是由 Presto 提供的适配多数据源的统一接口。
Catalog：管理元信息与实际数据的映射关系。

—— Query 相关

Query

基于 SQLparser 后获得的执行计划。

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 & LocalExchange：

Exchange：表示不同 Stage 间的数据传输，大多数意义下等价于 Shuffle
LocalExchange：Stage 内的 rehash 操作，常用于提高并行处理数据的能力（Task 在 Presto 中只是最小的容器，而不是最小的执行单元）

问：如何衡量某个任务某个 Stage 的真实并行度？

答：在不同 Pipeline 下 Split(Driver)的数目之和。

2.2 核心组建架构介绍

图源：教学PPT

—— 服务发现

Discovery Service：

Worker 配置文件配置 Discovery Service 地址
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 具有更好的数据压缩率。

节点状态：

ACTIVE
INACTIVE
SHUTDOWN

问：Shutdown 状态的作用是什么？

3. Presto 重要机制

多租户资源管理
多租户下的任务调度
内存计算
多数据源联邦查询

3.1 多租户资源管理

—— Case 介绍

假设某个用户提交一个sql:

提交方式：Presto-cli

提交用户：zhangyanbing

提交SQL：

select customer_type,avg(cost)
as a from test_table group by
customer_type order by a limit 10;

—— Resource Group

类似 Yarn 多级队列的资源管理方式
基于 CPU、MEMORY、SQL 执行数进行资源使用量限制

优点： 1.轻量的 Query 级别的多级队列资源管理模式

缺点： 2.存在一定的滞后性，只会对 Group 中正在运行的 SQL 进行判断

—— 物理计划生成

Antlr4 解析生成 AST
转换成 Logical Plan
按照是否存在 Shuffle(Exchange)，切分成不同的 Stage(Fragment)

图源：教学PPT

3.2 多租户下的任务调度

—— Stage 调度

同时调度：AllAtOnceExecutionPolicy

延迟点，会存在任务空跑。

分阶段调度：PhasedExecutionPolicy

有一定延迟、节省部分资源。

—— 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 间存在优先级

3.3 内存计算

—— Pipeline 化的数据处理

Pipeline 的引入更好的实现算子间的并行
语义上保证了每个 Task 内的数据流式处理

—— Back Pressure Mechanism

控制 split 生成流程
控制 operator 的执行

targetConcurrency auto-scale-out

定时检查，如果 OutputBuffers 使用率低于0.5（下游消费较快，需要提高生产速度），并发度+1

"sink.max-buffer-size"写入 buffer 的大小控制, "exchange.max-buffer-size"读取 buffer 的大小控制

达到最大值时Operator会进入阻塞状态

3.4 多数据源联邦查询

将各个数据源进行统一的抽象，最后由 presto server 进行统一的物理执行。

局限性：

元数据管理与映射（每个 connector 管理一套元数据服务）
谓词下推
数据源分片

4. 性能优化实战

4.1 常用性能分析工具

Grafana：埋点、系统指标可视化界面，时序化的数据展示
Java 指令
Arthas
Flame Figure