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

二个二个二
511 阅读7分钟

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

一、笔记内容

1、概述

2、Presto 的基础原理与概念

3、Presto 的重要机制

4、性能优化实战

二、概述

1.大数据与 OLAP 系统的演进

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

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

OLAP的核心概念：维度、度量

graph TD
常见的OLAP引擎 --> 预计算引擎(空间换时间) --> Kylin

预计算引擎 --> Druid

常见的OLAP引擎 --> 批式处理引擎(吞吐量) --> Hive

批式处理引擎 --> Spark

常见的OLAP引擎 --> 流式处理引擎(实时性) --> Flink

常见的OLAP引擎 --> 交互式处理引擎(查询时延) --> Presto

交互式处理引擎 --> Clickhouse

交互式处理引擎 --> Doris

OLAP相比于MapReduce的优势：

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

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

2.Presto 的设计思想

  image.png

Presto最初是由facebook研发的构建于Hadoop/HDFS系统之上的PB级交互式分析引擎。

Presto的特点：

  • 多租户任务的管理与调度

  • 多数据源联邦查询

  • 支持内存化计算

  • pipeline式数据处理

基于Presto 的二次开发:

三、Presto 的基础原理与概念

1.基础概念

image.png

1.服务相关概念

1.Coordinator

  • 解析SQL语句

  • 生成执行计划

  • 分发执行任务给Worker节点

2.Worker

  • 执行Task处理数据

  • 与其他Worker交互传输数据

2.数据源相关概念

1.Connector

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

2.Catalog

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

3.Query相关概念

1.Query

基于SQL parser后获得的执行计划。

2.Stage

根据是否需要shuffle将Query拆分成不同的subplan，每一个subplan便是一个stage。

3.Fragment

基本等价于Stage，属于在不同阶段的称呼，在本课程中可以认为两者等价。

4.Task

单个 Worker节点上的最小资源管理单元，在一个节点上，一个 Stage只有一个Task，一个Query可能有多个Task。

5.Pipeline

Stage按照LocalExchange 切分为若干Operator集合，每个Operator集合定义一个 Pipeline。

6.Driver

Pipeline的可执行实体，Pipeline 和 Driver的关系可类比程序和进程，是最小的执行单元，通过火山迭代模型执行每一个Operator。

7.Split

输入数据描述（数据实体是 Page），数量上和Driver——对应,不仅代表实际数据源split，也代表了不同stage间传输的数据。

8.Operator

是最小的物理算子。

4.数据传输相关概念

1.Exchange

表示不同 Stage 间的数据传输，大多数意义下等价于 Shuffle。

2.LocalExchange

Stage 内的rehash 操作，常用于提高并行处理数据的能力(Task在Presto中只是最小的容器，而不是最小的执行单元)。LocalExchange的默认数值是16。

多租户下的任务调度问题(数据传输相关)

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

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

解析：

Query拆分为多个subplan，每个subplan对应一个Stage；

Stage拆分为多个Operator，每个Operator对应一个Pipeline；

Pipeline下有多个Split，一个Split 对应一个Driver。

因此，一个Stage下所有Pipeline 中Split(Driver) 的数目和即为Stage的真实并行度。

2.核心组件架构

image.png

1.服务发现

Discovery Service

  • Worker配置文件配置Discovery Service地址；

  • Worker节点启动后会向Discovery Service注册；

  • Coordiantor 从Discovery Service获取Worker的地址。

2.通信机制

  1. Presto Client / JDBC Client 与Server 间通信 --> Http

  2. Coordinator与 Worker间的通信 --> Thrift / Http

  3. Worker 与 Worker间的通信 --> Thrift / Http

Thrift通信相较于Http的优点：

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

Presto Worker的不同状态

graph TD
节点状态 --> Active

节点状态 --> InActive

节点状态 --> Shutdown

Shutdown状态的作用：

节点关闭预警，即将关闭节点。此时Coordinator不会再向Work调度任何的Task，会有一个超时时间，在这个超时时间内Work会继续处理正在运行的Task，如果不能处理完，超时时间一到，立刻强制关闭Work节点。

四、Presto 的重要机制

1.多租户资源管理Presto Resource Group

1. Resource Group特点

  • 类似Yarn多级队列的资源管理方式；

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

2. Resource Group优缺点

  • 优点：

    • 支持通配符的形式，对不同租户，不同提交场景下的用户进行限制；

    • 轻量的Query级别的多级队列资源管理模式。

  • 缺点：

    • 资源的管理和判断是以当前用户正在运行的SQL资源使用量为基准，对于低频大SQL场景不太适用；

    • 存在—定滞后性，只会对Group 中正在运行的SQL讲行判断。

2.多租户下的任务调度

1.物理计划生成

1.Antlr4解析生成AST

2.转换成Logical Plan

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

image.png

2.Stage调度策略

  • AllAtOnceExecutionPolicy（同时调度）

    • 延迟低，会存在任务空跑。

  • PhasedExecutionPolicy（分阶段调度）

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

分阶段调度不代表每个stage都分开调度

分阶段调度典型的应用场景(join查询)

  • Build端：右表构建用户join的hashtable；

  • Probe端：对用户左表数据进行探查，需要等待build端完成；

  • Build端构建hashtable端时，probe端是一直在空跑的。

image.png

 

3.Task的节点选择策略

image.png

1.Task的数量确定

  • Source：根据数据meta决定分配多少个节点；（Fragment2）

  • Fixed：hash partition count确定，如集群节点数量；（Fragment1）

  • Sink：汇聚结果，一台机器；（Fragment0）

  • Scaled：无分区限制，可拓展，如write数据；（写入语句，DML语句）

  • Coordinator Only：只需要coordinator参与；（结果可直接判断出）

2.Task的调度方法

  • HARD_AFFINITY： 计算、存储 Local 模式，保障计算与存储在同一个节点，减少数据传输；

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

  • NO_PREFERENCE： 随机选取，常用于普通的纯计算 Task。

4.Split调度策略

Query A大SQL先提交，Query B小SQL后提交，是否应该等Query A执行完了再执行Query B ?

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

Split调度：

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

2.Split间存在优先级。

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

优势

1．优先保证小Query快速执行；

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

3.内存计算 

1. 特点

  • Pipeline化的数据处理

    • 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会进入阻塞状态。

4.多数据源联邦查询

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

image.png

局限性：

  • 谓词下推；

  • 每个数据源都需要单独的一套catalog管理；

  • 如何针对数据源进行分片操作。

五、性能优化实战

1.常用的性能分析工具

1.Grafana：埋点、系统指标如CPU、内存、网络等的可视化界面，时序化的数据展示

2.Java相关指令

  • Jstack查看Java线程星栈信息，排查是否有死锁，或者异常线程存在；

  • JMX(Java Management Extensions)是一个为应用程序植入管理功能的框架，常用来做—些监控指标的统计收集；

  • JMAP &GC日志等等内存分析工具。

3.线上问题排查工具

  • Arthas

  • watch：监控每个函数入参、返回参数、异常等信息；

  • Trace：统计函数内每一步的执行时间。

  • Flame Figure（火焰图）

Flame Figure（火焰图）：用于分析热点代码占用大量cpu，从而导致服务性能下降的情况。如下图，自底向上为调用关系。上层宽度越宽表示当前函数cpu耗时越久，我们关注最宽的函数调用。

image.png

  • Presto Ul

    • Query级别统计信息

    • Logical plan

    • Stage、Task 信息

    • Worker状态信息 

2.字节内部优化实践

  • Multi Coordinator

  • History Server

  • Support Remote UDF

  • RaptorX的多级缓存

参考文章：juejin.cn/post/712494…

avatar
文章
阅读
粉丝