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

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

01 概述

1.1 大数据与OLAP的演进

什么是大数据？

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

Hadoop：基于廉价机器的存算分离的大规模分布式处理系统

1、谷歌在2003、2004年发布Google File System论文、MapReduce论文

2、2008年，Hadoop成为apache顶级项目

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

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式数据处理

很多公司也基于Presto进行了二次开发：

√ Prestodb：github.com/prestodb/pr…

√ Trino：github.com/trinodb/tri…

√ openlookeng：github.com/openlookeng…

小结

1、介绍了大数据与OLAP系统的演进

2、带大家初步认识了Presto，了解Presto相关设计理念

02 Presto基础原理和概念

基础概念介绍-服务相关

• Coordinator

  • 解析SQL语句
  • 生成执行计划
  • 分发执行任务给Worker节点

• Worker

  • 执行Task处理数据
  • 与其他Worker交互传输数据

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

Connector：

一个Connector代表一种数据源，可以认为Connector是由Presto提供的适配多数据源的统一接口

Catalog：

管理元信息与实际数据的映射关系

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

最小的物理算子

数据传输相关

Exchange & localExchange：

√ Exchange：

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

√ LoclExchange：

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

LocalExchange的默认数值是16

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

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

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

2.2 核心组件架构介绍

Presto

服务发现

Discovery Service：

1、Wworker配置文件配置Discovery Service地址

2、Worker节点启动后会向Discovery Service注册

3、Coordinator从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

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

节点状态

• ACTIVE
• INACTIVE
• SHUTDOWN

Shutdown状态的作用是什么？

Graceful Shutdown（优雅的扩缩容）：

小结

1、从服务、数据源、Query、数据传输四个角度，介绍了Presto相关的基础概念

• 服务、数据源、Query、数据传输包含的基本概念

• 衡量一个任务的并行度（Task并不是最小的执行单元）

2、通过服务发现、通信机制、节点状态三方面介绍了Coordinator与Worker是如何协调和工作的

03 Presto重要机制

假设某个用户提交一个sql：

提交方式：Presto-ci

提交用户：zhangyanbing

提交SQL：

select customer_type,avg(cost)
as a 
from test_table
group by customer_type
order by a limit 10;

3.1 多租户资源管理 - Resource Group

Resource Group

• 类似Yarn多级队列的资源管理方式

• 基于CPU、MEMORY、SQL执行数进行资源使用量的限制

优点：

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

缺点：

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

物理计划生成

1、Antlr4解析生成AST

2、转换成Logical Plan

3、按照是否存在Shuffle（Exchange），切分成不同的Stage（Fragment）

√ Stage调度

Stage的调度策略

√ AllAtOnceExecutionPolicy

同时调度

延迟点，会存在任务空跑

√ PhasedExecutionpolicy

分阶段调度

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

PhasedExecutionPolicy：

不代表每个stage都分开调度

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

√ Build端：右表构建用户join的hashtable

√ Probe端：对用户左表数据进行探查，需要等待build端完成

√ Build端构建hashtable端时，probe端时一直在空跑的

Task调度

• 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执行完了再执行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 内存计算

Pipeline化数据处理

Pipeline（按LocalExchange拆分）：

√ Pipeline的引入更好的实现算子间的并行

√ 语义上保证了每个Task内的数据流式处理

• 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 sever进行统一的物理执行

局限性：

1、元数据管理与映射（每个connector管理一套元数据服务）

2、谓词下推

3、数据源分片

小结

展开介绍了如下的Presto重要机制

1、多租户资源管理

2、多租户任务调度

3、内存计算

4、多数据源联邦查询

04 性能优化实战

4.1 常用性能分析工具

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

Java相关指令

• Jstack查看Java线程栈信息，排查是否有死锁，或者异常线程存在

• JMX（Java Management Extensions）是一个为应用程序植入管理功能的框架，常用来做一些监控指标的统计收集

• JMAP & GC日志等等内存分析工具

线上问题排查工具：

Arthas

• Watch
• Trance
• ...

线上问题排查工具：Flame Figure火焰圈

√ 用于分析热点代码占用大量CPU，从而导致服务性能下降的情况，如下图，自底向上为调用关系，上层宽度越宽表示当前函数CPU耗时越久，我们关注最宽的函数调用

Presto UI

√ Query级别统计信息

√ Logical plan

√ Stage、Task信息

√ Worker状态信息

4.2 具体案例分析

Case 1： github.com/prestodb/pr…

Data；tpcds 1T

Table：store_returns(about 2000 partitions)

Sql：select count(*) from store_returnsQuery

execution time:about 3-4s

为什么不符合预期

count(*)只需要读取parquet的footer信息，为什么需要3-4s才需要完成一条sql

逐元素copy，大量的hashmap的rehash操作

对底层数据直接clone

时间从3-4s减少到了1s左右

Case 2：

SQL执行缓慢，发现某几个节点CPU负载特别高

只能看到某些节点cpu负载很高，但不知道导致的原因是什么，或者如何规避

√ 1、正则表达式是完全由用户输入的，而与正则表达式匹配的实际数据也不可控，结果就是单条记录匹配的时间也可能需要数天时间

√ 2、正则表达式不可中断，阻塞的Split的优先级调度

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

4.3 字节内部优化时间 - Multi Coordinator

1、Coordinator单节点稳定性差

2、单节点会成为集群性能瓶颈

Multi Coordinator

1、不可用时间从几分钟 -> 3s内

2、coordinator多活

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

√ 原始的Presto UI存储在内存中，无法长时间报错

√ History Server提供与Preto UI相同体验&持久化的数据存储

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

1、统一的UDF抽象，适配多引擎

2、多租户的内核与网络隔离

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

1、Metastore cache by version

2、List file cache

3、Fragament cache

4、Alluxio cache

小结

1、介绍了常见的性能优化工具

• Grafana
• Java指令
• Arthas
• Flame Figure

2、具体案例分析

3、字节内部优化实战分享