简述一下Spark中的hashShuffle和Sortshuffle两中shauffle的流程

首先是未优化过的 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，