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

一、概述

大数据与 OLAP 的演进

1. 什么是大数据

在信息化时代背景下，由于信息交互、信息存储、信息处理能力大幅增加而产生的数据。

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

为商业化大数据应用普及奠定基础。
之前处理海量数据没有好的物理模型，或是受限于单机性能。增加单机成本不能换来等价性能提升。———— 廉价机器堆叠可以使成本与性能线性增长。
存算分离：不需要存储结点和计算结点在同一个物理机上，可以使CPU性能好的机器专门负责计算，磁盘大但CPU性能差的机器负责存储。

2. 什么是 OLAP

OLAP (OnLine Analytical Processing)

对业务数据执行多维分析，并提供复杂计算，趋势分析和复杂数据建模的能力。是许多商务智能（BI）应用程序背后的技术。现如今 OLAP 已经发展为基于数据库通过 SQL 对外提供分析能力。
OLAP vs MapReduce
- MapReduce 代表了抽象的物理执行模型，使用门槛较高。
- 与 MapReduce Job 相比，OLAP 引擎常通过 SQL 的形式，为数据分析、数据开发人员提供统一的逻辑描述语言实际的物理执行由具体的引擎进行转换和优化。

Presto 设计理念

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

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

二、Presto 基础原理与概念

基础概念介绍

Presto基础概念主要可以分为哪几类？

服务相关概念
数据源相关概念
Query相关概念
数据传输相关概念

（黄色为数据源，深绿和浅绿为服务，蓝色为用户）

服务概念

Coordinator（负责调度）：
- 解析 SQL 语句
- ⽣成执⾏计划
- 分发执⾏任务给 Worker 节点执⾏
Worker：
- 执行 Task 处理数据
- 与其他 Worker 交互传输数据
当客户端提交一个查询的时候，coordinator 则会从当前存活的 worker 列表中选择出适合的 worker 节点去运行 task，而 worker 在执行每个 task 的时候又会进一步对当前 task 读入的每个 split 进行一系列的操作和处理。
Discovery Service（将 coordinator 和 woker 结合到一起的服务）:
- Worker 节点启动后向 Discovery Server 服务注册
- Coordinator 从 Discovery Server 获得 Worker 节点
所有的 worker 都把自己注册到 Discovery Server 上，Discovery Server 是一个发现服务的 service，Discovery Server 发现服务之后，coordinator 便知道在集群中有多少个 worker 能够工作，分配工作到 worker 时便有了根据。

数据源

Connector

Presto 通过 Connector 来支持多数据源，一个 Connector 代表一种数据源，如 Hive Connector 代表了对 Hive 数据源的支持。可以认为 Connector 是由 Presto 提供的适配多数据源的统一接口。
Catalog

针对不同的数据源，Connector 和 Catalog 是一一对应的关系，Catalog 包含了 schema 和 data source 的映射关系。

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 中只是最小的容器，而不是最小的执行单元）。

核心组件架构

通信机制

1. Presto Client / JDBC Client 与 Server 间通信

Http

2. Coordinator 与 Worker 间通信

Thrift / Http

3. Worker 与 Worker 间通信

Thrift / Http

Thrift 具有更好的数据编码能力，Http 1.1 还不支持头部信息的压缩，Thrift 具有更好的数据压缩率。

节点状态

Active
InActive
Shutdown

节点在该状态下，即将关闭还未关闭，coordinator 不会再调度 task，当前还未完成的 task 在超时时间内继续运行；超时时间到，强行关闭。

三、Presto 重要机制

多租户资源管理

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 执行数进行资源使用量限制
- 优点：轻量的 Query 级别的多级队列资源管理模式
```
可以基于通配符，或者提交 sql 过程中的 session（比如 username 信息）自动生成队列，不需要提前创建好每个队列
对不同租户，不同提交场景下的用户进行限制
```
- 缺点：存在一定滞后性，只对 Group 中正在运行的 SQL 进行判断
```
对于低频大 SQL 场景不太适用
```

（提交 SQL 的 source 为 Presto-cli，selectors 里前三个都不匹配，第四个是默认项不需要任何匹配）

（将 subGroups 展开，softMemoryLimit 使用 memory 不能超过10%，hardConcurrencyLimit 并行度上限 1，可排队数 100）

物理计划生成
1. Antlr4解析生成AST
2. 转换成Logical Plan
3. 按照是否存在Shuffle (Exchange)，切分成不同的Stage (Fragment)

多租户任务调度

Stage 调度

AllAtOnceExecutionPolicy 同时调度

默认调度方式，符合流式处理特点，可以一边分析，一边把处理好的数据传给下游。内存计算变得可行。

延迟低，会存在任务空跑。
PhasedExecutionPolicy 分阶段调度

不代表每个 Stage 都分开调度。

有一定延迟，节省部分资源。
- 典型的应用场景(join查询)
  - Build端：右表构建用户 join 的 hashtable
  - Probe端：对用户左表数据进行探查，需要等待 build 端完成
  - Build端构建 hashtable 端时，probe 端是一直在空跑的

Task 调度

Task的数量如何确定：
- Source：根据数据 meta 决定分配多少个节点
- Fixed：hash partition count 确定，如集群节点数量
- Sink：汇聚结果，一台机器
- Scaled：无分区限制，可拓展，如 write 数据
- Coordinator__Only：只需要 coordinator 参与

选择结点：
1. HARD_AFFINITY ：计算、存储 Local 模式，保障计算与存储在同一个节点，减少数据传输
2. SOFT_AFFINITY ：基于某些特定算法，如一致性 HASH 函数，常用于缓存场景，保证相似的 Task 调度到同一个 Worker
3. NO_PREFERENCE ：随机选取，常用于普通的纯计算 Task

Split 调度

按照固定的时间片，轮训 Split 处理数据，处理 1s，再重新选择一个 Split 执行
Split 间存在优先级

MultilevelSplitQueue

5个优先级level理论上分配的时间占比为 16:8:4:2:1 (2-based)

优势：

优先保证小Query快速执行
保障大Query存在固定比例的时间片，不会被完全饿死

内存计算

pipeline 化数据处理

Pipeline（按LocalExchange 拆分）：

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

Back pressure mechanism

控制 split 生成流程
针对每个 Task 定时检查, 如果 OutputBuffers 使用率低于 0.5（下游消费较快，需要提高生产速度）， Split 并发度+1
控制 Operator 执行速度
"sink.max-buffer-size" 写入buffer的大小控制
"exchange.max-buffer-size" 读取buffer的大小控制
Buffer 达到最大值时 Operator 会进入阻塞状态

多数据源联邦查询

缺点：针对不同数据源，还存在许多问题需要解决
- 谓词下推
- 每个数据源都需要单独的一套 catalog 管理
- 如何针对数据源进行分片操作

性能优化实战

常用性能分析工具

Grafana
- 埋点、系统指标如 CPU、内存、网络等的可视化界面，时序化的数据展示
Arthas
- watch：监控每个函数入参、返回参数、异常等信息
- trace：统计函数内每一步的执行时间
Flame Figure（火焰图）
- 用于分析热点代码占用大量 CPU，从而导致服务性能下降的情况。如下图，自底向上为调用关系。上层宽度越宽表示当前函数 CPU 耗时越久，我们关注最宽的函数调用。
java指令
- Jstack：查看Java线程栈信息，排查是否有死锁，或者异常线程存在
- JMX (Java Management Extensions) 是一个为应用程序植入管理功能的框架，常用来做一些监控指标的统计收集
- JMAP & GC 日志等等内存分析工具

总结

本节介绍了大数据与 OLAP 系统的演进，了解 Presto 相关设计理念。从服务、数据源、Query、数据传输四个角度介绍了 Presto 基础概念，通过服务发现、通信机制、结点状态三方面介绍了 Coordinator 与 Work 如何协调工作。Presto 重要机制包括多租户资源管理、多租户任务调度、内存计算、多数据源联邦查询。最后介绍了常用性能优化工具和项目实战。

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