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

面包小狗
156 阅读7分钟

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

本节课程目录：

  1. 概述
  2. Presto 基础原理和概念
  3. Presto 重要机制
  4. 性能优化实战

1. 概述

1.1 大数据与 OLAP 的演进

什么是大数据

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

image.png

Hadoop

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

  • 谷歌在2003、2004年发布 Google File System 论文，MapReduce 论文。
  • 2008年，Hadoop 成为 apache 顶级项目。

OLAP

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

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

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

  • OLAP 核心概念：

    • 纬度
    • 度量

image-2.png

  • 常见的 OLAP 引擎：
    • 预计算引擎：Kylin，Druid
    • 批式处理引擎：Hive，Spark
    • 流式处理引擎：Flink
    • 交互式处理引擎：Presto，Clickhouse，Doris

1.2 Presto 设计思想

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

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

image-3.png

2. Presto 基础原理和概念

2.1 基础概念介绍

2.1.1 服务相关概念

  • Coordinator

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

  • Worker

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

image-4.png

2.1.2 数据源相关概念

  • Connector

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

  • Catalog

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

2.1.3 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

最小的物理算子

image-5.png

2.1.4 数据传输相关概念

  • Exchange & LocalExchange
    • Exchange：
      • 表示不同 Stage 间的数据传输，大多数意义下等价于Shuffle
    • LocalExchange：（默认数值是16）
      • Stage 内的 rehash 操作，常用于提高并行处理数据的能力（Task 在 prest 中只是最小的容器，而不是最小的执行单元）

image-6.png

  • 如何衡量某个任务某个 Stage 的真实并行度？

在不同 Pipeline 下 Split（Driver）的数目之和

2.2 核心组件架构介绍

Presto 架构图

image-7.png

服务发现

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

image-8.png

通信机制

  • Presto Client / JDBC Client 与 Server 间通信
    • Http
  • Coordinator 与 Worker 间的通信
    • Thrift / Http
  • Worker 与 Worker 间的通信
    • Thrift / Http
  • Http 1.1 VS Thrift
    • Thrift 具有更好的数据编码能力，Http 1.1 还不支持头部信息的压缩，Thrift具有更好的数据压缩率

节点状态

Presto Worker的不同状态

  • Active
  • InActive
  • Shutdown

3. Presto 重要机制

3.1 多租户资源管理

Presto 通过 Resource Group 对不同的用户创建不同 Group 从而实现不同租户不同场景的资源管理

Resource Group

  • 类似 Yarn 多级队列的资源管理方式
  • 基于 CPU、MEMORY、SQL 执行数进行资源使用量限制

image-9.png

  • 优点
    • 轻量的 Query 级别的多级队列资源管理模式
    • 支持通配符的形式，对不同租户不同提交场景下的用户进行限制
  • 缺点
    • 存在一定滞后性，只会对 Group 中正在运行的 SQL 进行判断
    • 资源的管理和判断是以当前用户正在运行的SQL资源使用量为基准，对于低频大SQL场景不太适用

物理计划生成

  1. Antlr4 解析生成 AST
  2. 转换成 Logical Plan
  3. 按照是否存在 Shuffle（Exchange），切分成不同的 Stage（Fragment）

image-10.png

3.2 多租户下的任务调度

  • Stage调度策略
    • AllAtOnceExecutionPollcy 同时调度
      • 延迟低，会存在任务空跑
    • PhasedExecutionPollcy 分阶段调度
      • 有一定延迟，节省部分资源

image.jpeg

  • 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

image-11.png

  • Split 调度策略
    • FIFO：顺序执行
    • 优先级调度：快速响应
      • 按照固定的时间片，轮训 Split 处理数据，处理 1s，再重新选择一个 Split 执行
      • Split 间存在优先级
    • MultilevelSplitQueue
      • 5个优先级 level 理论上分配的时间占比为 16:8:4:2:1
    • 优势：
      • 优先保证小 Query 快速执行
      • 保障大 Query 存在固定比例的时间片

3.3 内存计算

Pipeline 化数据处理

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

image-12.png

Back Pressure Mechanism 反压机制

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

3.4 多数据源联邦查询

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

image-13.png

局限性：

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

4. 性能优化实战

4.1 常用性能分析工具

  1. Grafana
  2. Arthas（Watch，Trace）
  3. Flame Figure（火焰图）
  4. java指令：jstack等指令

image-14.png

4.2 具体案例分析

Case 1

image-15.png 逐元素 copy，大量的 hashmap 的 rehash 操作

image-16.png 对底层数据直接 clone

时间从 3-4s 减少到 1s 左右

Case 2

SQL 执行缓慢，发现某几个节点 CPU 负载特别高

image-17.png

  • 正则表达式是完全由用户输入的，而与正则表达式匹配的实际数据也不可控，结果就是单条记录匹配的时间也可能需要数天时间
  • 正则表达式不可中断，阻塞了 Split 的优先级调度 Input每增加一个0，耗时就会明显提升

4.3 Multi Coordinator

  1. Coordinator 单字节稳定性差
  2. 单节点会成为集群性能瓶颈

image-18.png 不可用时间从几分钟到3s内｜coordinator 多活

4.4 History Server

  1. 原始的 Presto UI 存储在内存中，无法长时间报错
  2. History Server 提供与 Presto UI 相同体验 & 持久化的数据存储

image-19.png

4.5 Support Remote UDF

  1. 统一的 UDF 抽象，适配多引擎
  2. 多租户的内核与网络隔离

image-20.png

4.6 RaptorX 的多级缓存

  1. Metastore cache by version
  2. List file cache
  3. Fragament cache
  4. Alluxio cache

image-21.png

avatar
文章
阅读
粉丝