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

红豆奶茶少冰半糖
218 阅读6分钟

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

1、 概述

1.1 大数据与OLAP的演变

  • 信息交换：通信和网络宽带的大幅增长

  • 信息存储：计算机存储量的大幅增长

  • 信息处理：整理、转换、分析数据的能力大幅增长 Hadoop：基于廉价机器的存算分离的大规模分布式处理系统

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

  • OLAP vs MapReduce

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

  • OLAP核心概念

    • 维度
    • 度量

  • 常见的OLAP引擎

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

1.2 Presto设计思想

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

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

  • 基于Presto的二次开发

    • Prestodb
    • Trino
    • Openlookeng

1.3 小结

  • 介绍了大数据与OLAP系统的演进
  • 带大家初步认识了Presto，了解Presto相关设计概念

2、 Presto基础原理与概念

2.1 基础概念介绍-服务相关

  • Coordinator
    • 解析SQL语句
    • 生成执行计划
    • 分发执行任务给Worker节点
  • Worker
    • 执行Task处理数据
    • 与其他Worker交互传输数据 image.png

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

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

image.png

2.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：最小的物理算子

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

  • Exchange & LocalExchange
    • Exchange：
      • 表示不同Stage间的数据传输，大多数意义下等价于Shuffle
    • LocalExchange：
      • Stage内的rehash操作，常用于提高并行处理数据的能力，默认数值是16

2.5 多租户下的任务调度-数据传输相关

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

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

2.6 核心组件架构介绍

Presto架构图

image.png

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

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

image.png

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

  • 通信机制

    • Presto Client/JDBC Clinet与Server间通信（Http）
    • Coordinator与Worker间的通信（Thrift/Http）
    • Worker与Worker间的通信（Thrift/Http）

  • Http 1.1 vs Thrift

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

  • 节点状态

    • ACTIVE
    • INACTIVE
    • SHUTDOWN

2.6.3 核心组件架构介绍

  • Graceful Shutdown（优雅的扩缩容）： image.png

2.7 小结

  • 从服务、数据源、Query、数据传输四个角度介绍了Presto相关的基础概念
  • 通过服务发现、通信机制、节点状态三方面介绍了Coordinator与Worker是如何协调和工作的

3、 Presto重要机制

3.1 多租户资源管理

3.1.1 Case介绍

image.png

3.1.2 Resource Group

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

3.2 多租户下的任务调度

  • Stage调度
  • Task调度
  • Split调度

3.2.1 物理计划生成

image.png

3.2.2 Stage调度

  • Stage的调度策略

    • AllAtOnceExecutionPolicy 同时调度：延迟点 会存在任务空泡
    • PhaseExecutionPolicy 分阶段调度（不代表每个stage都分开调度）：有一定延迟、节省部分资源

  • PhasedExecutionPolicy:

    • 不代表每个stage都分开调度

  • 典型的应用场景（join查询）：

    • Build端:右表构建用户join的hashtable
    • Probe端:对用户左表数据进行探查，需要等待build端完成
    • Build端构建hashtable端时，probe端是一直在空跑的

image.png

3.2.3 Task调度

  • Task的数量如何确定

image.png 选择什么样的节点

image.png

3.2.4 Split调度

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

image.png

3.3 内存计算

  • Pipeline化的数据处理
  • Back Pressure Mechanism

3.3.1 Pipeline化数据处理

按LocalExchange拆分：

image.png

3.3.2 Back Pressure Mechanism

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

image.png

3.4 多数据源联邦查询

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

image.png

  • 局限性
    • 元数据管理与映射
    • 谓词下推
    • 数据片分片

3.5 小结

  • 多租户资源管理
  • 多租户任务调度
  • 内存计算
  • 多数据源联邦查询

4、 性能优化实战

4.1 常用性能分析工具

  • Grafana：埋点、系统指标与CPU、内存、网络等的可视化界面，时序化的数据展示
  • Java相关指令

image.png

image.png

  • 线上问题排查工具

  • Arthas
  • Watch
  • Trace

  • 线上问题排查工具：Flame Figure/火焰图

  • Presto UI
  • Query 级别统计信息
  • Logical plan
  • Stage、Task信息
  • Worker状态信息

4.2 具体案例分析

Case 1

image.png

image.png

Case 2

image.png

image.png

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

  • Coordinator单节点稳定性差
  • 单节点会成为集群性能瓶颈
  • 不可用时间从几分钟->3s内
  • coordinator多活

4.4 字节内部优化实践-History Server

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

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

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

4.6 字节内部优化实践

  • Metastore cache by version
  • List file cache
  • Fragament cache
  • Alluxio cache

4.7 总结

  • 介绍了常见的性能优化工具
  • 具体案例分析
  • 字节内部优化实战分享
avatar
文章
阅读
粉丝