首先是未优化过的 hashshuffle的流程：
在Map阶段会根据上游RDD的分区数生成M个task任务；
然后再reduce阶段会根据下游RDD所需的分区数据生成R个task任务
每个R任务会从M个task任务区获取各自分区的数据，最终声场的文件数就是,M 乘以 R
缺点就是会生成大量小文件，会对IO性能带来压力，以及文件管理节点带来严重压力。
因为大量爆发的小文件问题，所以已经弃用为优化的hashshuffle方式了；
因此对hashshuffle进行了文件合并的优化；
优化的点就是在于 将同一个Excutor执行器的task任务产生的文件都 共享同一个输出文件，
这样每个reduce task中就对应了一个输出文件的多个数据块，reduce task执行完后就合并文件了
这样优化之后，显著的减少了文件的数据，如果有执行器的数量 乘以 reduce task的数量
但是对于大批量的数据计算，这样的优化还是不够。
因此现在Spark默认方式就是SortShuffle方式，能有效的减少小文件的数据量
在map task任务按照分区生成M个文件后，文件会被排序并进入内存缓存区，如果内存缓存不足就会溢出到磁盘当中
在reduce拉去数据之前，所有的数据都会合并成一个有序的数据文件，和一个对应分区的索引文件
在Reduce task阶段，按照索引去拉去对应数据
这样在shuffle阶段就只生成了M 乘以 2的文件数据量
缺点就是排序会需要一定的CPU开销
因此优化出来了一个ByPass 的 sortShuffle ,就是会通过参数设置设置一个文件的阈值，默认是200，
)
