大数据-复习笔记-7 | 青训营笔记

能鸽善鹉
145 阅读8分钟

Presto 架构原理与优化介绍 - 复习笔记

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

1. 概述

1.1 大数据与 OLAP 的演进

1.1.1 什么是大数据？
大数据=大规模的数据量？ 关于大数据这里我们参考马丁希尔伯特的总结：大数据其实是在2000年后，因为信息化的快速发展。信息交换、信息存储、信息处理三个方面能力的大幅增长而产生的数据。

image.png

1.1.2 Hadoop：基于廉价机器的存算分离的大规模分布式处理系统
1.谷歌在2003、2004年发布Google File System论文、MapReduce论文。
2.2008年，Hadoop成为apache顶级项目

**1.1.3 OLAP **

  • OLAP（OnLine Analytical Processing）对业务数据执行多维分析，并提供复杂计算，趋势分析和复杂数据建模的能力。是许多商务智能（Bl）应用程序背后的技术
  • OLAP VS MapReduce
    1.MapReduce 代表了抽象的物理执行模型，使用门槛较高
    2.与 Mapreduce Job 相比，OLAP 引擎常通过 SQL 的形式，为数据分析、数据开发人员提供统一的逻辑描述语言，实际的物理执行由具体的引擎进行转换和优化。
  • OLAP 核心概念：
    • 维度
    • 度量
  • 常见的OLAP引擎：
    • 预计算引擎：Kylin，Druid
    • 批式处理引擎：Hive，Spark
    • 流式处理引擎：Flink
    • 交互式处理引擎：Presto，Clickhouse，Doris

1.2 Presto 设计思想

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

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

2. Presto 基础原理和概念

2.1 基础概念介绍

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

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

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

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

image.png

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
    最小的物理算子。

2.1.4 基础概念介绍-数据传输相关
Exchange&LocalExchange：

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

LocalExchange的默认数值是16。

2.2 核心组件架构介绍

Presto 架构图

image.png

2.2.1 核心组件架构介绍-服务发现 Discovery Service：

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

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

  • 通信机制
  1. Presto Client/JDBC Client与Server 间通信
    • Http
  2. Coordinator与Worker 间的通信
    • Thrift/Http
  3. Worker与Worker间的通信
    • Thrift/Http

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

  • 节点状态：

    • ACTIVE
    • INACTIVE
    • SHUTDOWN

3. Presto 重要机制

3.1 多租户资源管理

3.1.1 多租户资源管理-Case介绍
假设某个用户提交一个sql：
提交方式：Presto-cli
提交用户：zhangyanbing
提交SQL:
select customer_type，avg（cost）
as a from test_table group by
customer_type order by a limit 10；

3.1.2 多租户资源管理-Resource Group

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

3.1.3 多租户资源管理-物理计划生成

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

image.png

3.2 多租户下的任务调度

3.2.1 多租户下的任务调度-Stage 调度

  • Stage 的调度策略

    • AllAtOnceExecutionPolicy
      同时调度
    • PhasedExecutionPolicy
      分阶段调度

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

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

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

  • Stage的调度策略：

    • AllAtOnceExecutionPolicy
      延迟点，会存在任务空跑
    • PhasedExecution Policy
      有一定延迟、节省部分资源

3.2.2 多租户下的任务调度-Task 调度

  • Task 调度
    • Task的数量如何确定
    • 选择什么样的节点（调度方式有那些）
  • Task的数量如何确定：
    • Source：根据数据meta决定分配多少个节点
    • Fixed:hash partition count 确定，如集群节点数量
    • Sink：汇聚结果，一台机器
    • Scaled：无分区限制，可拓展，如write数据
    • Coordinator_Only.只需要coordinator参与
  • 选择什么样的节点
    • HARD_AFFINITY：计算、存储Local 模式，保障计算与存储在同一个节点，减少数据传输
    • SOFT AFFINITY：基于某些特定算法，如一致性HASH函数，常用于缓存场景，保证相似的Task调度到同一个Worker
    • NOPREFERENCE：随机选取，常用于普通的纯计算 Task

3.2.3 多租户下的任务调度-Split调度
Query A大SQL 先提交
Query B小SQL后提交
是否应该等 Query A执行完了再执行Query B？

  • FIFO：顺序执行，绝对公平
  • 优先级调度：快速响应
  1. 按照固定的时间片，轮训Split 处理数据，处理1s，再重新选择一个Split执行
  2. Split 间存在优先级\
  • MultilevelSplitQueue
    5个优先级level理论上分配的时间占比为16：8：4：2：1（2-based）
  • 优势：
    1.优先保证小Query快速执行
    2.保障大Query存在固定比例的时间片，不会被完全饿死

3.3 内存计算

3.3.1 内存计算-Pipeline 化数据处理

  • Pipeline（按LocalExchange 拆分）：
    • Pipeline的引入更好的实现算子间的并行
    • 语义上保证了每个Task内的数据流式处理

3.3.2 内存计算

  • 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. 性能优化实战

4.1 常用性能分析工具

  • Grafana：
    埋点、系统指标如CPU、内存、网络等的可视化界面，时序化的数据展示
  • Java 相关指令
    • Jstack 查看Java线程栈信息，排查是否有死锁，或者异常线程存在
    • JMX（Java Management Extensions）是一个为应用程序植入管理功能的框架，常用来做一些监控指标的统计收集
    • JMAP&GC日志等等内存分析工具

线上问题排查工具：

  • Arthas
    Watch
    Trace
  • Flame Figure/火焰图
    用于分析热点代码占用大量CPU，从而导致服务性能下降的情况。如下图，自底向上为调用关系。上层宽度越宽表示当前函数CPU耗时越久，我们关注最宽的函数调用。
  • Presto UI
    • Query 级别统计信息
    • Logical plan
    • Stage、Task 信息
    • Worker 状态信息

4.2 具体案例分析

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

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

1659541413664.png

Multi Coordinator 1.不可用时间从几分钟->3s内2.coordinator多活

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

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

image.png

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

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

1659541546988.png

4.6 字节内部优化实践-RaptorX的多级缓存

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

1659541612497.png

avatar
文章
阅读
粉丝