学习的最大理由是想摆脱平庸,早一天就多一份人生的精彩;迟一天就多一天平庸的困扰。
热爱写作,愿意让自己成为更好的人…
…

| 铭记于心 | ||
|---|---|---|
| 🎉✨🎉我唯一知道的,便是我一无所知🎉✨🎉 |
为什么需要Push Shuffle,因为一般shuffle过程存在不可避免的问题:
数据存储在本地磁盘,没有备份
IO 并发:大量 RPC 请求(M*R)
IO 吞吐:随机读、写放大(3X)
GC 频繁,影响 NodeManager
为了优化该问题,有很多公司都做了思路相近的优化,push shuffle
Spark driver组件,协调整体的shuffle操作
map任务的shuffle writer过程完成后,增加了一个额外的操作push-merge,将数据复制份推到远程shuffle服务上
magnet shuffle service是一个强化版的ESS。将隶属于同一个shuffle partition的block,会在远程传输到magnet后被merge到一个文件中
reduce任务Amagnet shuffle service 接收合并好的shuffle数据

bitmap: 存储Emerge的mapper id, 防止重复merge
position offset: 如果本次block没有正常merge,可以恢复到上一个block的位置
currentMapld: 标识当前正在append的block,保证不同mapper 的block能依次append

主要为边写边push的模式,在原有的shuffle基础上尝试push聚合数据,但并不强制完成,读取时优先读取push聚合的结果,对于没有来得及完成聚合或者聚合失败的情况,则fallback到原模式
如果Map task输出的Block没有成功Push到magnet上,并且反复重试仍然失败,则reducetask直接从ESS上拉取原始block数据
如果magnet上的block因为重复或者冲突等原因,没有正常完成merge的过程,则reducetask直接拉取未完成merge的block
如果reduce拉取已经merge好的block失败,则会直接拉取merge前的原始block
本质上, magnet中维护了两份shuffle数据的副本
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-82JnEti8-1661440964552)(image/image_vN88KGZRLN.png)]


读取

Cloud Shuffle Service 支持AQE

一个Partition会最终对应到多个Epoch file, 每个EPoch 目前设置是512MB
Shuffle 概述:
数据shuffle的概念,其存在的意义以及基本流程
Shuffle为什么对性能影响很重要
Shuffle算子
常见的Shuffle算子
理解宽依赖与窄依赖,ShuffleDependency及其相关组件
shuffle过程
Spark中shuffle实现的历史
Spark中主流版本的shuffle写入和读取过程
Push shuffle
Magnet Push Shuffle的设计思路
Cloud Shuffle Service 的设计实现思路
自己构造一个会产生shuffle 的spark作业,修改shuffle相关的参数,对比一下不同参数对作业运行的影响
在spark中shuffle实现的发展过程中,每一次变化都优化了之前哪些缺点,又带来了哪些问题?
Push Shuffle相对比Fetch Shuffle最大的挑战是什么?
🌹写在最后💖:
路漫漫其修远兮,吾将上下而求索!伙伴们,再见!🌹🌹🌹