👉引言💎
学习的最大理由是想摆脱平庸，早一天就多一份人生的精彩；迟一天就多一天平庸的困扰。 热爱写作，愿意让自己成为更好的人............
| 铭记于心 | ||
| 🎉✨🎉我唯一知道的，便是我一无所知🎉✨🎉 |
四、Push Shuffle
0 概述
- 为什么需要Push Shuffle，因为一般shuffle过程存在不可避免的问题：
- 数据存储在本地磁盘，没有备份
- IO 并发：大量 RPC 请求（M*R）
- IO 吞吐：随机读、写放大（3X）
- GC 频繁，影响 NodeManager
- 为了优化该问题，有很多公司都做了思路相近的优化，push shuffle
- Facebook： cosco
- LinkedIn：magnet
- Uber：Zeus
- Alibaba： RSS
- Tencent： FireStorm
- Bytedance： Cloud Shuffle Service
- Spark3.2： push based shuffle
1 Magnet主要流程
- Spark driver组件,协调整体的shuffle操作
- map任务的shuffle writer过程完成后,增加了一个额外的操作push-merge,将数据复制份推到远程shuffle服务上
- magnet shuffle service是一个强化版的ESS。将隶属于同一个shuffle partition的block,会在远程传输到magnet后被merge到一个文件中
- reduce任务Amagnet shuffle service 接收合并好的shuffle数据
2 实现原理：
- bitmap: 存储Emerge的mapper id, 防止重复merge
- position offset: 如果本次block没有正常merge,可以恢复到上一个block的位置
- currentMapld: 标识当前正在append的block,保证不同mapper 的block能依次append
主要为边写边push的模式，在原有的shuffle基础上尝试push聚合数据，但并不强制完成，读取时优先读取push聚合的结果，对于没有来得及完成聚合或者聚合失败的情况，则fallback到原模式
3 Magnet 可靠性
- 如果Map task输出的Block没有成功Push到magnet上,并且反复重试仍然失败,则reducetask直接从ESS上拉取原始block数据
- 如果magnet上的block因为重复或者冲突等原因,没有正常完成merge的过程,则reducetask直接拉取未完成merge的block
- 如果reduce拉取已经merge好的block失败,则会直接拉取merge前的原始block
- 本质上, magnet中维护了两份shuffle数据的副本
4 Cloud Shuffle Service 思想
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-82JnEti8-1661440964552)(image/image_vN88KGZRLN.png)]
5 Cloud Shuffle Service架构
6 Cloud Shuffle Service 读写流程
- 写入
- 读取
- 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最大的挑战是什么？
🌹写在最后💖： 路漫漫其修远兮，吾将上下而求索！伙伴们，再见！🌹🌹🌹
