问题一：Facebook Riffle采用了什么方法来改进Shuffle性能？
Facebook Riffle采用了什么方法来改进Shuffle性能？
参考回答：
Facebook Riffle在2018年采用了在Mapper端Merge的方法，通过物理节点上部署的Riffle服务，将节点上的Shuffle数据按照PartitionId做Merge，从而一定程度上将小粒度的随机读合并成较大粒度的读操作。
关于本问题的更多问答可点击原文查看：
https://developer.aliyun.com/ask/670713
问题二：Cosco在RSS标准架构上做了哪些定义，但性能上为何没有显著提升？
Cosco在RSS标准架构上做了哪些定义，但性能上为何没有显著提升？
参考回答：
Cosco在2019年采用了Sailfish的方法并进行了重设计，保留了Push Shuffle + Partition数据聚合的核心方法，但使用了独立服务。服务端采用Master-Worker架构，使用内存两副本，并用DFS做持久化。Cosco基本上定义了RSS的标准架构，但由于受到DFS的拖累，性能上并没有显著提升。
关于本问题的更多问答可点击原文查看：
https://developer.aliyun.com/ask/670716
问题三：Uber Zeus在Shuffle处理上有哪些独特之处？
Uber Zeus在Shuffle处理上有哪些独特之处？
参考回答：
Uber Zeus在2020年同样采用了去中心化的服务架构，但没有类似etcd的角色来维护Worker状态，因此难以做状态管理。Zeus通过Client双推的方式实现多副本，并采用本地存储。
关于本问题的更多问答可点击原文查看：
https://developer.aliyun.com/ask/670717
问题四：Intel RPMP是如何利用新硬件来加速Shuffle的？
Intel RPMP是如何利用新硬件来加速Shuffle的？
参考回答：
Intel RPMP在2020年依靠RDMA和PMEM等新硬件来加速Shuffle，但它并没有做数据聚合。
关于本问题的更多问答可点击原文查看：
https://developer.aliyun.com/ask/670719
问题五：LinkedIn Magnet的设计哲学是什么？它有哪些局限？
LinkedIn Magnet的设计哲学是什么？它有哪些局限？
参考回答：
LinkedIn Magnet在2021年融合了本地Shuffle+Push Shuffle，其设计哲学是“尽力而为”。Mapper的Output写完本地后，Push线程会将数据推给远端的ESS做聚合，但不保证所有数据都会聚合。Magnet受益于本地Shuffle，在容错和AE支持上表现更好，但依赖本地盘，不支持存算分离；数据合并依赖ESS，对NodeManager造成额外压力；Shuffle Write同时写本地和远端，性能达不到最优。
关于本问题的更多问答可点击原文查看：
https://developer.aliyun.com/ask/670720
