这是我参与「第四届青训营 」笔记创作活动的第7天
6.4 push shuffle
1.为什么要push shuffle
Avg l0 size太小，造成了大量的随机10，严重影响磁盘的吞吐
M * R次读请求，造成大量的网络连接，影响稳定性
2.push shuffle的实现
Facebook:COSCO
LinkedIn: magnet
Uber: Zeus
Alibaba:RSS
Tencent:FireStorm
Bytedance: CSS
Spark3.2:push based shuffle
3.magnet实现原理
Spark driver组件，协调整体的shuffle操作
map任务的shuffle writer过程完成后，增加了一个额外的操作push-merge,将数据复制 份推到远程shuffle服务.上magnet shuffle service是一个强化版的ESS。将隶属于同一个shuffle partition的block,会在远程传输到magnet后被merge到一个文件中
reduce任务从magnet shuffle service接收合并好的shuffle数据
bitmap:存储已merge的mapper id,防止重复merge
position offset:如果本次block没有正常merge,可以恢复到上一个block的位置
currentMapld:标识当前正在append的block,保证不同mapper的block能依次append
4.magnet可能性
如果Map task输出的Block没有成功Push到magnet上，并且反复重试仍然失败，则reduce task直接从ESS上拉取原始block数据
如果magnet上的block因为重复或者冲突等原因，没有正常完成merge的过程，则reduce task直接拉取未完成merge的block
如果reduce拉取已经merge好的block失败，则会直接拉取merge前的原始block
本质上，magnet中维护 了两份shuffe数据的副本
5.cloud shuffle service思想
6.cloud shuffle service架构
Zookeeper Workerl ist [服务发现]
CSS Worker [Partitions / Disk | Hdfs]
Spark Driver [集成启动CSS Master]
CSS Master [Shuffle 规划/统计]
CSS ShuffileClient [Write / Read]
Spark Executor [Mapper + Reducer]
cloud shuffle service写入流程
cloud shuffle service AQE
一个Partition会最终对应到多个Epoch file, 每个EPoch目前设置是512MB
7.实践案例-CSS优化
XX业务小时级任务(1 .2wcores)
混部队列2.5h ->混部队列+CSS 1.3h (50%提升)
