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

张鱼哥z
76 阅读6分钟

这是我参与「第四届青训营」笔记创作活动的的第7天，以下是我的课堂笔记。 本次课程主要分为四个大板块：
1. 概述
2. Presto基础原理和概念
3. Presto重要机制
4. 性能优化实战

1. 概述

1.1大数据与OLAP的演进

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

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

1.2 Presto设计思想

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

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

1.3 小结

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

2. Presto基础原理与概念

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

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

image.png

2.2 基础概念介绍-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.3 基础概念介绍-数据传输相关

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

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

Q:如何衡量某个任务某个Stage的真实并行度?
A:在不同Pipeline 下 Split (Driver)的数目之和。

image.png

image.png

2.5 核心组件架构介绍

Presto 架构图:

image.png

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

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

3. Presto重要机制

3.1多租户资源管理-Case介绍

假设某个用户提交一个sql:
提交方式:Presto-cli提交用户:zhangyanbing
提交SQL: select customer_type, avg(cost) as afrom test table group by customer_type order bya limit 10;

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

3.1多租户下的任务调度–物理计划生成

1.Antlr4解析生成AST
2.转换成 Logical Plan
3.按照是否存在Shuffle (Exchange)，切分成不同的Stage (Fragment)
提交SQL:
select customer type, avg(cost) as a from
test table group by customer_type order by a limit 10;

image.png

3.2多租户下的任务调度

  • Stage 调度

  • Task 调度

  • Split 调度

  • Stage的调度策略

  • AllAtOnceExecutionPolicy
    同时调度

  • PhasedExecutionPolicy
    分阶段调度

3.3 多租户下的任务调度一Stage 调度

  • PhasedExecutionPolicy:
    不代表每个stage都分开调度
    典型的应用场景(join查询) √ Build端:右表构建用户join的hashtable
    √ Probe端:对用户左表数据进行探查，需要等待build端完成√Build端构建hashtable端时，probe端是一直在空跑的

  • stage的调度策略: √ AlIAtOnceExecutionPolicy
    延迟点，会存在任务空跑

  • PhasedExecutionPolicy
    有一定延迟、节省部分资源

3.4 内存计算

  • 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.5 多数据源联邦查询

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

3.6 小结

展开介绍了如下的Presto重要机制:
1．多租户资源管理
2. 多租户任务调度
3. 内存计算
4．多数据源联邦查询

4. 性能优化实战

4.1常用性能分析工具

  • Grafana:埋点、系统指标如CPU、内存、网络等的可视化界面，时序化的数据展示

image.png

  • Grafana:埋点、系统指标如CPU、内存、网络等的可视化界面，时序化的数据展示

image.png Java相关指令:

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

image.png

image.png 线上问题排查工具:

  • Arthas
  • Watch
  • Trace 线上问题排查工具:Flame Figure/火焰图
  • 用于分析热点代码占用大量CPU ,从而导致服务性能下降的情况。如下图，自底向上为调用关系。上层宽度越宽表示当前函数CPU耗 时越久，我们关注最宽的函数调用。

image.png Presto ul

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

image.png

avatar
文章
阅读
粉丝