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

serendipity__
102 阅读5分钟

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

Presto 架构原理与优化介绍

一、概述

1、大数据与OLAP的演进

  1. 什么是大数据

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

  1. 什么是OLAP

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

2、Presto设计思想

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

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

  • 多数据源联邦查询

  • 支持内存化计算

  • pipeline式数据处理

二、Presto基础原理与概念

2.1.1 Presto 基础概念-服务相关

image.png

  • Coordinator（负责调度）：
    • 解析SQL语句
    • ⽣成执⾏计划
    • 分发执⾏任务给Worker节点执⾏
  • Worker
    • 执行Task处理数据
    • 与其他Worker交互传输数据

2.1.2 Presto基础概念-数据源相关

image.png

  • Connector

Presto通过Connector来支持多数据源，一个Connector代表一种数据源，如Hive Connector代表了对Hive数据源的支持。可以认为Connector是由Presto提供的适配多数据源的统一接口

  • Catalog

针对不同的数据源，Connector和Catalog是一一对应的关系，Catalog包含了schema和data source的映射关系。

2.1.3 Presto基础概念-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

最小的物理算子

2.1.4 Presto基础概念-数据传输部分

  • Exchange

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

  • LocalExchange

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

2.2 核心组件架构介绍

Presto架构图

image.png

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

  • Http 1.1 vs Thrift

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

  • Presto Worker的不同节点状态
    1. Active
    2. InActive
    3. Shutdown

三、Presto重要机制

3.1 多租户资源管理-Resource Group

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

3.2 所租户下的任务调度

3.2.1. Stage调度策略

  • AllAtOnceExecutionPolicy （同时调度）：延迟点，会存在任务空跑
  • PhasedExecutionPolicy （分阶段调度）：有一定延迟，节省部分资源

3.2.2. Task的节点选择策略

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

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

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

3.2.3. Split调度策略

优势：

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

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

Back Pressure Mechanism

  • 控制split生成流程
  • 控制operator的执行

  1. targetConcurrency auto scale out 定时检查，如果OutputBuffers使用率低于0.5 (下游消费较快需要提高生产速度)，并发度+1

  2. "sink.max-buffer- size"写入buffer的大小控制 " exchange.max- buffer- size" 读取buffer的大小控制 达到最大值时Operator会进入阻塞状态

3.4 多数据源联邦查询

将各个数据源进行统一的抽象，最后由presto server进行统一的物理执行 image.png 局限性：

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

四、性能优化实战

4.1 常用性能分析工具

  1. Grafana：埋点、系统指标如CPU、内存】网络等的可视化界面，时序化的数据展示
  2. Arthas
  3. Flame Figure（火焰图）：用于分析热点代码占用大量CPU，从而导致服务性能下降的情况。如下图，自底向上为调用关系，上层宽度越宽表示当前函数CPU耗时越久，我们关注最宽的函数调用。

image.png 4. java指令：jstack等指令

4.2 字节内部优化实践-Multi Coordinator

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

image.png

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

image.png

4.3 字节内部优化实践- Support Remote UDF

  • 统一的UDF抽象，适配多引擎
  • 多租户的内核于网络隔离

image.png

4.4 字节内部优化实践——RaptorX的多级缓存

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

image.png

avatar
文章
阅读
粉丝