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

01.概述

1.1 大数据与OLAP的演进

什么是大数据?

大数据 = 大规模的数据量?

关于大数据这里我们参考马丁▪️希尔伯特的总结:大数据其实是在2000年后，因为信息化的快速发展。信息交换、信息存储、信息处理三个方面能力的大幅增长而产生的数据。

截屏2022-08-02 12.53.58.png

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

1.谷歌在2003、2004年发布Google File System论文、MapReduce论文。

2.2008年，Hadoop成为apache顶级项目

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

➢OLAP VS MapReduce

1.MapReduce代表了抽象的物理执行模型，使用门槛较高

2.与Mapreduce Job相比，OL AP引擎常通过SQL的形式，为数据分析、数据开发人员提供统一的逻辑描述语言，实际的物理执行由具体的引擎进行转换和优化。

截屏2022-08-02 12.57.23.png

OLAP核心概念：

▪️ 维度
▪️ 度量

➢常见的OL AP引擎:

● 预计算引擎: Kylin, Druid

● 批式处理引擎: Hive, Spark

● 流式处理引擎: Flink

● 交互式处理引擎: Presto, Clickhouse, Doris

1.2 Presto 设计思想

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

1）多租户任务的管理与调度

2）多数据源联邦查询

3）支持内存化计算

4）Pipeline 式数据处理

截屏2022-08-02 13.01.16.png

有很多公司也基于Presto进行了二次开发:

1）Prestodb: github.com/prestodb/pr…

2）Trino: github.com/trinodb/tri…

3）Openlookeng: github.com/openlookeng…

02. Presto基础原理与概念

基础概念介绍 - 服务相关

1）Coordinator

（1）解析SQL语句

（2）生成执行计划

（3）分发执行任务给Worker节点

2）Worker

（1）执行Task处理数据

（2）与其他Worker交互传输数据

截屏2022-08-02 13.04.46.png

2.1基础概念介绍-数据源相关

➢Connector:

一个Connector代表一种数据源。可以认为Connector是由Presto提供的适配多数据源的统一接口。

➢Catalog:

管理元信息与实际数据的映射关系。

截屏2022-08-02 13.06.06.png

2.1基础概念介绍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

最小的物理算子。

截屏2022-08-02 13.09.30.png

2.1基础概念介绍数据传输相关

➢Exchange & LocalExchange:

1）Exchange:

（1）表示不同Stage间的数据传输，大多数意义下等价于Shuffile

2） LocalExchange: （1）Stage 内的rehash操作，常用于提高并行处理数据的能力(Task在Presto中只是最小的容器，而不是最小的执行单元)

LocalExchange的默认数值是16。

截屏2022-08-02 13.11.20.png

Q:如何衡量某个任务某个Stage的真实并行度?

A:在不同Pipeline下Split (Driver)的数目之和。

截屏2022-08-02 13.12.10.png

截屏2022-08-02 13.12.33.png

2.2核心组件架构介绍

Presto架构图

截屏2022-08-02 13.13.24.png

2.2核心组件架构介绍服务发现

Discovery Service:

Worker配置文件配置Discovery Service地址
Worker节点启动后会向Discovery Service注册
Coordiantor从Discovery Service获取Worker的地址

截屏2022-08-02 13.15.43.png

2.2核心组件架构介绍通信机制

➢通信机制

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

● Http

2.Coordinator与Worker间的通信

● Thrift / Http

3.Worker与Worker间的通信

● Thrift / Http

➢Http 1.1 VS Thrift

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

节点状态:

▪️ ACTIVE

▪️ INACTIVE

▪️ SHUTDOWN

2.2核心组件架构介绍

➢Graceful Shutdown (优雅的扩缩容):

截屏2022-08-02 13.20.14.png

03. Presto重要机制

3.1多租户资源管理 - Case介绍

假设某个用户提交一个sq|:

提交方式: Presto-cli

提交用户: zhangyanbing

提交SQL: seLect customer. type,avg (cost) as a from test_ table group by customer. _type order by a timit 10;

3.1多租户资源管理一Resource Group

➢ Resource Group

1）类似Yarn多级队列的资源管理方式

2）基于CPU、MEMORY、SQL执行数进行资源使用量限制

截屏2022-08-02 13.23.26.png

截屏2022-08-02 13.23.55.png

优点:

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

缺点

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

3.1多租户下的任务调度一物理计划生成

1.Antlr4解析生成AST

2.转换成Logical Plan

3.按照是否存在Shuffle (Exchange)，切分成不同的Stage (Fragment)

提交SQL: select customer_ type, avg(cost) as a from test_ table group by customer_ type order by a limit 10;

截屏2022-08-02 13.27.59.png

3.2多租户下的任务调度

1）Stage 调度

2）Task 调度

3）Split 调度

3.2多租户下的任务调度一Stage调度

➢Stage的调度策略

1）AllAtOnceExecutionPolicy

同时调度

2）PhasedExecutionPolicy

分阶段调度

➢PhasedExecutionPolicy:

不代表每个stage都分开调度

典型的应用场景(join查询)

1） Build 端:右表构建用户join的hashtable

2） Probe端:对用户左表数据进行探查，需要等待build端完成

3） Build 端构建hashtable端时，probe 端是一直在空跑的

截屏2022-08-02 13.46.38.png

➢Stage的调度策略:

1）AllAtOnceExecutionPolicy

延迟点，会存在任务空跑

2）PhasedExecutionPolicy

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

3.2多租户下的任务调度一 Task 调度

➢ Task调度

▪️ Task的数量如何确定

▪️ 选择什么样的节点(调度方式有那些)

Task的数量如何确定:

1）Source :根据数据meta决定分配多少个节点

2）Fixed: hash partition count确定，如集群节点数量

3）Sink: 汇聚结果，一台机器

4）Scaled: 无分区限制，可拓展，如write数据

5）Coordinator _Only: 只需要coordinator参与

截屏2022-08-02 13.50.01.png

选择什么样的节点

➢HARD_ AFFINITY:计算、存储Local模式，保障计算与存储在同-一个节点，减少数据传输

➢SOFT_ AFFINITY:基于某些特定算法，如一致性HASH函数，常用于缓存场景，保证相似的Task调度到同一个Worker

➢NO_ PREFERENCE:随机选取，常用于普通的纯计算Task

3.2多租户下的任务调度一 Split 调度

Query A大SQL先提交

Query B小SQL后提交

是否应该等Query A执行完了再执行Query B ?

FIFO:顺序执行，绝对公平

优先级调度:快速响应

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

MultilevelSplitQueue

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

优势:

1.优先保证小Query快速执行

2.保障大Query存在固定比例的时间片，不会被完全饿死

3.3内存计算

● Pipeline化的数据处理

● Back Pressure Mechanism

3.3内存计算一Pipeline 化数据处理

Pipeline (按LocalExchange拆分):

1）Pipeline 的引入更好的实现算子间的并行

2）语义上保证了每个Task内的数据流式处理

截屏2022-08-02 13.57.26.png

3.3内存计算

▪️ Back Pressure Mechanism

（1）控制split生成流程

（2）控制operator的执行

targetConcurrency auto-scale- out 定时检查，如果OutputBuffers使用率低于0.5 (下游消费较快，需要提高生产速度)，并发度+1
"sink.max. buffer size"写入buffer的大小控制 "exchange.max- buffer- size"读取buffer的大小控制

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