这是我参与「第四届青训营 」笔记创作活动的第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、字节内部优化实战分享