【spark系列12】spark remote shuffle service(RSS)杂谈

背景

对于spark remote shuffle service（以下简称RSS）,在社区其实早就有探讨SPARK-25299,只不过一直没有达成一致，且目前的内置的shuffle service 也能满足大部分的场景，也就被搁置了，但是由于kubernetes的越来越火热,spark
社区也慢慢的集成了spark on k8s，当然k8s社区也集成了spark,具体区别见spark on k8s 与 spark on k8s operator的对比.
但是就目前的spark on k8s来说shuffle还是存在问题的：

• shuffle的磁盘问题,挂本地磁盘还是网络磁盘，挂多大, 磁盘的隔离和权限等
• shuffle的效率问题,磁盘的读写效率低下

对于进一步的原因可以参考为什么企业都会去优化Spark Shuffle Service

所以各个公司就提出了spark shuffle的解决方案，如趣头条和阿里的RSS ,facebook的cosco, LinkedIn的Magnet，以及Facebook的Riffle方案

其中Magnet和Riffle方案都是先将shuffle文件传到本地，然后再进行merge或者upload到远程的服务上
趣头条和阿里的RSS以及cosco实现的更好

spark shuffle的诟病

我们知道一旦进行了shuffle操作以后，很大概率会进行spill，也就是写磁盘的过程。

1. 对于磁盘的读写是非常耗时间的，而读写磁盘的时间涉及到：

• 寻道时间
• 磁盘服务时间

而寻道时间跟文件的读取方式有关，磁盘服务时间跟磁盘的类型有关。
我们能做的就是让文件进行顺序读写，以及减少文件的数量，因为每读一个文件就得重新寻道
2. spark shuffle的过程中会涉及三次写磁盘

• map端的排序以及spill
• 合并分区到一个文件
• reduce端的sort以及spill

而这三次磁盘的写操作无疑给shuffle的效率减少了不少。

RSS

所以一个好的RSS的方案必然从：

1. 减少shuffle文件数量
2. 减少读写磁盘的次数
   这两方面来优化。

其实，RSS的优点还是很多的：

1. 存储和计算分离
   使计算节点和存储节点能够各司其职，而不是交汇在一起。现在的spark和yarn的架构其实还没有达到存储和计算分离的
2. 动态资源分配
   使用了RSS以后，任务完成以后，可以直接释放所占用的资源，而不是一直占用，直到shuffle文件不需要，这样能大大提高集群的资源利用率
3. 能够很好的集成资源调度组件，如kubernetes
   以后如果出现新的资源调度组件能够很方便的集成，代码级别几乎不需要修改