spark的sortshuffle和hashshuffle

一，hashshuffle

最早引入的shuffle机制，spark2.0已经被弃用。

运行时步骤：
1，spark根据key将结果hash到不同buffer；
2，map完成后buffer溢写到磁盘文件，一个buffer一个文件；
3，task拉取小文件；

问题：
1，使用大量小文件，io频繁；
2，使用大量buffer内存，易出现oom。

优化后的hashshuffle：Consolidate机制

同一个task相同的hash共用一个buffer，减少了小文件的数量，但还是会占用大量内存，由此催生出了sortshuffle。

二，sortshuffle

sortshuffle的流程可以总结为三步：spill、排序、合并。

一个task只有一个buffer内存，写入内存时没有hash。

步骤：
1，task的map将结果数据写入到缓存(Map(PartitionedAppendOnlyMap)或者数组PartitionedPairBuffer)，默认大小时5M;
2，过程中定时器不定期估算缓存的大小，内存结构超过一定比例时，会申请新的内存，申请大小为：（2*当前大小 - 5）M；
3，如果申请新内存失败，则会将当前数据写入磁盘文件，按批写入，每批10000条；
4，写入文件之前会按照分区和key进行排序；
5，task完成后将所有小文件进行归并合并，合并生成一个磁盘文件，一个索引文件；
6，reduce根据索引从map拉取数据

问题：

1，需要排序，影响性能；
2，中间有很多小文件，io导致性能降低；
3，排序能不能省：不能省，因为在写入缓存和落盘的过程中没有根据reduce任务分区，不排序的话无法在合并时将相同分区合并在一起（使用了归并排序）。

优化：bypass机制

bypass机制运行条件：

• shuffle map task数量小于spark.shuffle.sort.bypassMergeThreshold参数的值。不宜有太多分区因为过程中会并发打开所有分区对应的临时文件，会对文件系统造成很大的压力。
  bypass之后类似于hashshuffle，多了溢写操作，不容易出现oom。
• 不是聚合类的shuffle算子（比如reduceByKey），聚合类算子会大幅降低数据量，排序所需资源也很少。一个key只有少量数据，这样的话还要一个文件存储，反而降低效率。

仔细看bypass的流程，基本就是hash based shuffle，区别在于最后会合并为一个文件。

和未优化前的区别：

• 1，写入缓存时会根据key进行hash，写入到不同缓存；
• 2，不需要排序，直接将内存中的数据写入磁盘文件；

相同点：

• 都会溢写、合并

主要优化:

• 省去了排序

sortshuffle相当于hashshuffle的优化

• 1,hashshuffle是先把所有数据写入缓存，然后一次性写入磁盘文件
• 2,hashushuffle的磁盘文件不会合并，导致有很多小文件

https://www.aboutyun.com/thread-27330-1-1.html

彻底搞懂spark的shuffle过程（shuffle write)