背景
对于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，也就是写磁盘的过程。
- 对于磁盘的读写是非常耗时间的，而读写磁盘的时间涉及到：
而寻道时间跟文件的读取方式有关，磁盘服务时间跟磁盘的类型有关。
我们能做的就是让文件进行顺序读写，以及减少文件的数量，因为每读一个文件就得重新寻道
2. spark shuffle的过程中会涉及三次写磁盘
- map端的排序以及spill
- 合并分区到一个文件
- reduce端的sort以及spill
而这三次磁盘的写操作无疑给shuffle的效率减少了不少。
RSS
所以一个好的RSS的方案必然从：
- 减少shuffle文件数量
- 减少读写磁盘的次数
这两方面来优化。
其实，RSS的优点还是很多的：
- 存储和计算分离
使计算节点和存储节点能够各司其职，而不是交汇在一起。现在的spark和yarn的架构其实还没有达到存储和计算分离的
- 动态资源分配
使用了RSS以后，任务完成以后，可以直接释放所占用的资源，而不是一直占用，直到shuffle文件不需要，这样能大大提高集群的资源利用率
- 能够很好的集成资源调度组件，如kubernetes
以后如果出现新的资源调度组件能够很方便的集成，代码级别几乎不需要修改
