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

Matrix8295
206 阅读8分钟

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

0 引言

整体架构.png

1 概述

1.1 大数据与OLAP系统的演进

大数据理解：我理解的大数据是大量数据，在各种技术框架中进行信息交换、信息存储、信息处理的过程，最终达到对数据的利用。

Hadoop简介：基于廉价机器的存算分离的大规模分布式处理系统。【HDFS：分布式文件存储、MapReduce：分布式计算、YRAN：资源调度】

OLAP(OnLine Analytical Processing)对业务数据执行多维分析，并提供复杂计算，趋势分析和复杂数据建模的能力。是许多商务智能(BI)应用程序背后的技术。【OLAP联机分析处理、OTAP联机事务处理】
OLAP核心概念：维度、度量。【可以理解为ML中的特征与样本数？】
常见的OLAP引擎:

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

OLAP与MapReduce的对比：

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

1.2 Presto设计思想

Presto是BP级交互式分析引擎，特点有：

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

2 Presto基础原理和概念

2.1 基础概念的介绍

服务+数据源.png 服务相关
Coordinator：解析SQL语句生成执行计划，分发执行任务给Worker节点
Worker：执行Task处理数据，与其他Worker交互传输数据

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

Query相关
Query：基于SQL parser后获得的执行计划
Stage：根据是否需要shuffle将Query拆分成不同的subplan，每一个subplan便是一个stage
Fragment：基本等价于Stage，属于在不同阶段的称呼，在本门课程可以认为两者等价
Task：单个Worker节点上的最小资源管理单元:在一个节点上,一个Stage只有一个Task,一个Query可能有多个Task 【Query -> Stage(Fragment) -> Task】
Pipeline：Stage按照LocalExchange切分为若干Operator集合,每个Operator集合定义一个Pipeline
Driver：Pipeline的可执行实体，Pipeline和Driver的关系可类比程序和进程，是最小的执行单元，通过火山迭代模型执行每一个Operator
Split：输入数据描述(数据实体是Page),数量上和Driver一一对应，不仅代表实际数据源split，也代表了不同stage间传输的数据
Operator：最小的物理算子 【Pipeline -> Driver -> Split -> Operator 注：Spark中也提到这个概念】

数据传输相关
Exchange：表示不同Stage间的数据传输，大多数意义下等价于Shuffle
LocalExchange：Stage内的rehash操作，常用于提高并行处理数据的能力(Task在Presto中只是最小的容器，而不是最小的执行单元=Pipeline+Driver)，默认参数16
Q:如何衡量某个任务某个Stage的真实并行度? A:在不同Pipeline下Split(Driver)的数目之和。

2.2 核心组件架构介绍

Presto架构.png 服务发现（Discovery Service）

  1. Worker配置文件配置Discovery Service地址 【D中间部分】
  2. Worker节点启动后会向Discovery Service注册 【W <-> D】
  3. Coordiantor从Discovery Service获取Worker的地址 【C <-> D】

通信机制

  1. Presto Client/JDBC Client与Server间通信 【Http】
  2. Coordinator与Worker间的通信 【Thrift/Http】
  3. Worker与Worker间的通信 【Thrift/Http】

Http1.1与Thrift通信比较： Thrift具有更好的数据编码能力，Http1.1还不支持头部信息的压缩，Thrft具有更好的数据压缩率

节点状态
通信节点有三种状态：ACTIVE（激活）、INACTIVE（非激活）、SHUTDOWN（关闭）
Graceful shutdown(优雅的扩缩容)：我的理解是当我要关闭服务前，告诉连接我的客户端停止向我通信，等我不在接收信息后，再将服务关闭，达到优雅的关闭

3 presto重要机制

3.1 多租户资源管理

Resource Group
类似Yarn多级队列的资源管理方式，基于CPU、MEMORY、SQL执行数进行资源使用量限制【官方例子中：rootGroups下subGroups】
优点：轻量的Query 级别的多级队列资源管理模式
缺点：存在一定滞后性，只会对Group中正在运行的 SQL进行判断

在Presto集群中使用资源组功能，需要在Presto Coordinator节点安装目录/etc下
新建一个文件resource-groups.json，然后将resource-groups.config-file 指向资源组配置文件的路径
1. resource-groups.configuration-manager=file 
2. resource-groups.config-file=etc/resource-groups.json

物理计划生成
物理计划生成.png

  1. Antlr4解析生成AST
  2. 转换成Logical Plan
  3. 按照是否存在Shuffle(Exchange)，切分成不同的Stage(Fragment)
for (PlanOptimizer optimizer : planOptimizers) { // 优化
    root = optimizer.optimize(root, session, symbolAllocator.getTypes(), symbolAllocator, idAllocator, warningCollector);
    requireNonNull(root, format("%s returned a null plan", optimizer.getClass().getName()));
}

3.2 多租户下的任务调度

Stage调度

同时调度（AlIAtOnceExecutionPolicy）：延迟多，会存在任务空跑
分阶段调度（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参与

选择什么样的节点：

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

Split调度

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

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

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

优势:

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

3.3 内存计算

Pipeline化的数据处理 pipeline.png Pipeline(按LocalExchange拆分)： Pipeline的引入更好的实现算子间的并行，语义上保证了每个Task内的数据流式处理

Back Pressure Mechanism反压机制
反压机制：比如在短时负载高峰导致系统接收数据的速率远高于它处理数据的速率，Presto中可以控制split生成流程和控制operator的执行

#定时检查,如果OutputBuffers使用率低于0.5(下游消费较快,需要提高生产速度)，并发度+1
targetConcurrency auto-scale-out 
#写入buffer的大小控制
sink.max-buffer-size 
#读取buffer的大小控制达到最大值时Operator会进入阻塞状态
exchange.max-buffer-size

3.4 多数据源联邦查询

多数据源联邦查询.png 将各个数据源进行统一的抽象，最后由presto server进行统一的物理执行
局限性:

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

4 性能优化实战

对下面的知识做了解

常用性能分析工具
Grafana：埋点、系统指标如CPU、内存、网络等的可视化界面，时序化的数据展示

Java相关指令：
Jstack：查看Java线程栈信息，排查是否有死锁，或者异常线程存在
JMX(Java Management Extensions)：是一个为应用程序植入管理功能的框架，常用来做一些监控指标的统计收集
JMAP& GC日志等等内存分析工具

线上问题排查工具:
Arthas：Watch()、Trace()
Flame Figure/火焰图：用于分析热点代码占用大量CPU，从而导致服务性能下降的情况
Presto UI：Query级别统计信息、Logical plan、Stage/Task信息、Worker状态信息

具体案例分析
一条SQL语句执行时间长，用Flame Figure查到一个函数执行时间过长（逐元素copy，大量的hashmap的rehash操作），对底层数据直接clone代码优化，查询速度变快。

发现某几个节点CPU负载特别高导致SQL执行缓慢，原因是正则表达式不可中断，阻塞了Split的优先级调度。

字节内部优化实战
Multi Coordinator：Coordinator单节点 -> Coordinator多活
History Server：原始的PrestoUI存储在内存中无法长时间报错 -> 功能相同&持久化的数据存储
Support Remote UDF：统一的UDF抽象，适配多引擎多租户的内核与网络隔离
RaptorX的多级缓存：

引用参考

1.【大数据专场 学习资料三】第四届字节跳动青训营
2. OLAP|基础知识梳理
3. Presto资源组快速指南
4. 实时流处理系统反压机制（BackPressure）综述
5. Presto在字节跳动的内部实践与优化

avatar
文章
阅读
粉丝