spark中RSS工具简介

一、Spark Shuffle

对于 spark shuffle 这一过程，网络上有非常多的文章进行说明，这里简单描述介绍下。

Spark 包含三种 shuffle writer，上图展示的是 BypassMergeSortShuffleWriter （有兴趣的用户可以自行阅读社区源码），以此为例简单介绍 spark shuffle。

Shuffle Writer 会将每个 shuffle write task 的数据，按照一定的规则进行划分，比如说 hash（具体什么规则是通过 rdd 之间的 transform 进行设定的，也可以用户自行设定 rdd 的 Partitioner），并对应的写到临时文件中。在所有数据写完之后，会将这些临时文件合并成一个文件，并生成 index 文件用于索引每个 reduce task 数据所对应的部分。

当所有的 shuffle write task 完成后，会进入到 shuffle read stage，并启动 shuffle read task。

shuffle read task，会读取之前所有 shuffle write task 所产生的 shuffle 数据中对应为自己的某一部分。如上图右边所示，每个 task 内的数据来源与左边的 task 颜色一致。

（为了简单理解，可能部分并不准确，准确的理解可以直接查看社区源码）

二、RSS 是什么

spark shuffle 的问题

上面简单介绍完之后，我们可以发现，对于一次 shuffle read，需要读取前面 m 个 shuffle write task 所产生的对应自己的那一部分，所以一个 shuffle read task 需要读取 m 个 task，如果一次 shuffle read 包含 r 个 task，那么就需要读取 m * r 个 block。

我们假设一次 shuffle 的数据量是 100 GB，m 和 r 都是 1000，那么平均来说，一个 block 的大小是 100 GB / (1000 * 1000) = 104 kb。总共需要 100w 次网络请求，每次需要读取 104 kb。

这个会带来大量的随机读，随机读小块数据，也会带来极低的 shuffle read 性能，更糟糕的是，如果 shuffle read 性能过低，很有可能触发 FetchFailedException，从而导致 shuffle write task 的重算，进一步增大了 shuffle 的时长。

简单介绍 RSS

remote shuffle service 是一个只负责写不负责读的 shuffle service，京东自主开发。但市面上也会有其它类型的 shuffle service，比如 Facebook 所做的 Cosco，Linkedkin 做的 Magnet，Uber 做的 Zeus。

简单来说，我们把上面所述的 spark shuffle 过程进行改写：

shuffle write 的时候，我们会直接写到 remote shuffle service 上而不落盘；相同的 reduce partition 会被写到相同的 shuffle service 上，以此进行一个聚合，并写到 hdfs 上的文件中。

shuffle read 的时候，会直接读取 hdfs。

通过 hdfs 上的 shuffle 数据备份，以此来消除 FetchFailedException 的产生，避免 shuffle write task 的重算，也避免了小块数据的频繁读取。