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

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

一、概述。

1.大数据与OLAP系统的演进。

什么是大数据？ 大数据=大规模的数据量？

• 根据马丁希尔伯特的总结：大数据其实是在2000年后，因为信息化的快速发展。信息交换、信息存储、信息处理三个方面能力的大幅增长而产生的数据。

Hadoop:基于廉价机器的存算分离的大规模分布式处理系统（廉价机器能做到成本与性能的线性增长，存算分离：cpu性能好的机器用来计算，差的用来存储。）

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

OLAP(OnLine Analytical Processing）：对业务数据执行多维分析，并提供复杂计算，趋势分析和复杂数据建模的能力。是许多商务智能(BI)应用程序背后的技术。（随着演变的过程中OLAP逐渐向大数据靠拢）

OLAP VS MapReduce

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

OLAP核心概念：

• 维度
• 度量 常见的 OLAP 引擎（按功能分类）：
• 预计算引擎:Kylin, Druid
• 批式处理引擎:Hive,Spark
• 流式处理引擎:Flink
• 交互式处理引擎:Presto, Clickhouse, Doris

2.Presto设计思想

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

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

二、Presto基础原理与概念。

1.基础概念的介绍。

基础概念介绍-服务相关

• Coordinator
  • 解析SQL语句
  • 生成执行计划
  • 分发执行任务给Worker节点
• Worker
  • 执行Task处理数据
  • 与其他Worker交互传输数据
  • 最终把计算结果汇总给Connector并展示给用户

基础概念介绍-数据源介绍

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

基础概念介绍-Query相关

• Query： 基于SQL parser 后获得的执行计划
• Stage： 根据是否需要shufle 将 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： 最小的物理算子。

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

Exchange & LocalExchange：

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

LocalExchange 的默认数值是16.

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

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

2.核心组件架构介绍：

Presto架构图

服务发现：

Discovery Service

• Worker 配置文件配置 Discovery Service地址
• Worker 节点启动后会向 Discovery Service 注册
• Coordiantor 从Discovery Service 获取 Worker的地址达到集群管理的作用

通信机制：

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

Http 1.1 VS Thrift：

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

节点状态：

• ACTIVE
• INACTIVE
• SHUTDOWN

SHUTDOWN状态的作用是什么？

节点变成Shutdown的状态后，Client感知到状态，就不会再向Work调度任何Task，会在一个延迟时间内把能处理玩的处理完，超出这个时间后就会强制关闭Work节点。

三、Presto重要机制。

1.多租户资源管理。

Resource Group：

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

优点：

• 轻量的Query 级别的多级队列资源管理模式

缺点：

• 存在一定滞后性，只会对GrOup中正在运行的SQL进行判断

物理计划生成：

• Antir4解析生成AST
• 转换成Logical Plan
• 按照是否存在Shufle (Exchange ),切分成不同的Sage(Franmen)

2.多租户下的任务调度。

Stage 的调度策略：

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

PhasedExecutionPolicy：

不代表每个stage 都分开调度

典型的应用场景(join查询）

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

Stage 的调度策略（优缺点）

• AlIAtOnceExecutionPolicy 延迟低，会存在任务空跑
• PhasedExecutionPolicy 有一定延迟、节省部分资源

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

Split调度：

• Query A大SQL先提交
• Query B小SQL后提交

是否应该等Query A执行完了两执行QueryB ?

• FIFO:顺序执行，绝对公平

• 优先级调度：快速响应

• 按照固定的时间片,轮训Splt 处理数据，处理15,再重新选择一个Splt执行

• Split 间存在优先级

MultilevelSplitQueue：

• 5个优先级level理论上分配的时间占比为16:8:4:2:1(2-based)

优势：

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

3.内存计算。

• Pipeline化的数据处理
  • 优点：
    • Pipeline的引入更好的实现算子间的并行
    • 语义上保证了每个Task内的数据流式处理
• Back Pressure Mechanism（反压机制）
  • 方式：
    • 控制split生成流程
    • 控制operator的执行

①targetConcurrency auto-scale-out

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

②"sink.max- buffer-size"写入bufer的大小控制

"xchange.max buffer-size"读取buffer的大小控制

达到最大值时Operator会进入阻塞状态（最终的相对速度取决于消费端的速度。）

4.多数据源联邦查询。

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

局限性：

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

四、性能优化实战。

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状态信息

2.具体案例分析。

case1：

对底层数据clone，可以减少时间到1s。

case2:

SQL执行缓慢，发现某几个节点CPU 负载特别高 只能看到某些节点cpu负载很高，但是不知道导致的原因是什么，或者如何规避

• 正则表达式是完全由用户输入的，而与正则表达式匹配的实际数据也不可控，结果就是单条记录匹配的时间也可能需要数天时间。
• 正则表达式不可中断，阻塞了Spit的的优先级调度。

Input每增加一个0，耗时就会明显提升。

解决思路：

• 能否实现一个可中断的正则表达式？
• 除了正则表达式外遇到其他类似问题怎么处理？
  • Shutdown，异常发现，紧急处理

3.字节内部优化实践。

Mut Codnator：

• 不可用时间从几分钟>3内
• cordnaor多活

History Server：

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

Support Remote UDF：

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

RaptorX的多级缓存：

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

总结

这次课主要学习了Presto的基础概念和原理，以及Presto的特色和重要机制，Resource Group是Presto用户多租户的隔离手段，还学会了Presto进行Task调度时有三种调度方式，但其中有些始终感觉不是很理解，不知道有没有好的方法可以帮助学习。