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

OLAP演进

OLAP (OnLine Analytical Processing) 对业务数据执行多维分析，并提供复杂计算，趋势分析和复杂数据建模的能力。是许多商务智能（BI）应用程序背后的技术。现如今OLAP已经发展为基于数据库通过SQL对外提供分析能力。

OLAP VS MapReduce

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

名词介绍

服务相关

coordinator：负责meta管理，worker管理，query的解析调度（相当于hdfs里的namenode）master

解析SQL语句
生成执行计划
分发执行任务给Worker节点

worker：负责计算读写

执行Task处理数据
与其他Worker交互传输数据

数据源相关

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。

架构

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具有更好的数据压缩率。

节点状态

Active
InActive
Shutdown

Presto重要机制

多租户资源管理

假设某租户用户通过Prestio-cli提交了一个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 级别的多级队列资源管理模式

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

多租户任务调度

物理计划生成

Antlr4解析生成AST
转换成 Logical Plan
按照是否存在Shuffle (Exchang同的 Stage(Fragment)

调度任务

stage
task
split

stage

参考：presto中的AllAtOnce与Phased

配置query.execution-policy，有两个选项，一个是all-at-once，另一个是phased，分别对应以下两种策略

策略

同时调度（AllAtOnceExecutionPolicy）：low latency，存在cpu空消耗
分阶段调度（PhasedExecutionPolicy）默认，不代表每个stage都得分开

join查询为例

select * 
from test1 
join test2 
on test1=test2.stuid

从执行计划上看，关键的有三个stage，分别是源头的stage2和stage3，以及做join的stage1。在这个简单的例子中，如果选择了AllAtOnceExecutionPolicy方式调度，那么stage(0,1,2,3)会在第一轮调度时一起进行调度，如果选择了PhasedExecutionPolicy调度方式，那么会进行两轮调度，第一轮调度stage(0,1,3)，然后下一轮调度stage(2)。相当于AllAtOnceExecutionPolicy顾名思义所有的stage一次性调。，PhasedExecutionPolicy顾名思义是分阶段调度，但是阶段怎么分就是个问题了，比如在这个例子中，如果phased先调度stage(0,1,2)那么不考虑exchange buffer的话，stage2是不可以运行的，因为join build端还未进行build。

Phase有一定延迟，一定程度上避免的了cpu的空消耗，以及spilt队列过长的问题。

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

FIFO: 顺序执行，绝对公平
优先级调度：快速响应

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

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

优势：

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

内存计算

Pipeline化的数据处理

Pipeline（按LocalExchange 折分）：

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

Back Pressure Mechanism

什么叫“背压”？

管道满了后给发送者一个反向压力。

硬盘的写入速度，远远小于硬盘的读取速度。如果可读流太快，而可写流的无法迅速的消费可读流传输的数据，写入流将会把 chunk，push 到写队列中方便之后使用，这样就会造成数据在内存中的累积。这个时候将会触发 backpressur（背压） 机制。如果没有 backpressur（背压） 机制，系统将会出现如下的问题：

内存溢出
其他进程变得缓慢
垃圾收集器将超负荷运作

怎么做的？

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

多数据源联邦查询

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

局限性

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

Presto 架构原理与优化介绍