我和spark有个约会（2）-spark 的shuffle过程

shuffle被称为是神奇发生的地方，分为三个部分了解下shuffle的过程：
概览，spark write，spark read

为什么需要 shuffle write

按照stage划分后的rdd：

详细的任务执行的流程：

从图上可以看出，有依赖的stage之间的数据互通，是通过上个stage的shufflemaptask write 之后，将源数据同步，再由下一个stage的shufflemaptask 读取源数据在read获取到。
spark shuffle的进化史：

• Spark 0.8及以前 Hash Based Shuffle

• Spark 0.8.1 为Hash Based Shuffle引入File Consolidation机制

• Spark 0.9 引入ExternalAppendOnlyMap

• Spark 1.1 引入Sort Based Shuffle，但默认仍为Hash Based Shuffle

• Spark 1.2 默认的Shuffle方式改为Sort Based Shuffle

• Spark 1.4 引入Tungsten-Sort Based Shuffle

• Spark 1.6 Tungsten-sort并入Sort Based Shuffle

• Spark 2.0 Hash Based Shuffle退出历史舞台

Hash Based Shuffle， 这时候每一个Mapper会根据Reducer的数量创建出相应的bucket，bucket的数量是M R ，其中M是Map的个数，R是Reduce的个数。这样会产生大量的小文件，对文件系统压力很大，而且也不利于IO吞吐量。后面忍不了了就做了优化，把在统一core上运行的多个Mapper 输出的合并到同一个文件，这样文件数目就变成了 cores R 个了
例如：
3个maptask 3个reducetask 这样的话就会产生9个小文件：

优化之后：

4个maptask 4个redueetask 如果不使用 Consolidation机制，会产生16个小文件。
优化之后，4个map运行在2个core上，这样只会产生8个小文件。
在同一个 core 上先后运行的两个 map task的输出， 对应同一个文件的不同的 segment上， 称为一个 FileSegment， 形成一个 ShuffleBlockFile。
后面就引入了 Sort Based Shuffle， map端的任务会按照Partition id以及key对记录进行排序。同时将全部结果写到一个数据文件中，同时生成一个索引文件， 再后面就就引入了 Tungsten-Sort Based Shuffle， 这个是直接使用堆外内存和新的内存管理模型，节省了内存空间和大量的gc， 是为了提升性能。
现在2.1 分为三种writer， 分为 BypassMergeSortShuffleWriter， SortShuffleWriter 和 UnsafeShuffleWriter，顾名思义，大家应该可以对应上， Hash Based Shuffle 已经退出历史舞台了，我就不讲了。

三种shuffle write的分类：

上面是使用哪种 writer 的判断依据， 是否开启 mapSideCombine 这个判断，是因为有些算子会在 map 端先进行一次 combine， 减少传输数据。 因为 BypassMergeSortShuffleWriter 会临时输出Reducer个（分区数目）小文件，所以分区数必须要小于一个阀值，默认是小于200。

UnsafeShuffleWriter需要Serializer支持relocation，Serializer支持relocation：原始数据首先被序列化处理，并且再也不需要反序列，在其对应的元数据被排序后，需要Serializer支持relocation，在指定位置读取对应数据。

分别分析下三种write方式：

BypassMergeSortShuffleWriter 实现细节

BypassMergeSortShuffleWriter和Hash Shuffle中的HashShuffleWriter实现基本一致， 唯一的区别在于，map端的多个输出文件会被汇总为一个文件。 所有分区的数据会合并为同一个文件，会生成一个索引文件，是为了索引到每个分区的起始地址，可以随机 access 某个partition的所有数据。

但是需要注意的是，这种方式不宜有太多分区，因为过程中会并发打开所有分区对应的临时文件，会对文件系统造成很大的压力。

具体实现就是给每个分区分配一个临时文件，对每个 record的key 使用分区器（模式是hash，如果用户自定义就使用自定义的分区器）找到对应分区的输出文件句柄，直接写入文件，没有在内存中使用 buffer。 最后copyStream方法把所有的临时分区文件拷贝到最终的输出文件中，并且记录每个分区的文件起始写入位置，把这些位置数据写入索引文件中。

SortShuffleWriter 实现细节

我们可以先考虑一个问题，假如我有 100亿条数据，但是我们的内存只有1M，但是我们磁盘很大， 我们现在要对这100亿条数据进行排序，是没法把所有的数据一次性的load进行内存进行排序的，这就涉及到一个外部排序的问题，我们的1M内存只能装进1亿条数据，每次都只能对这 1亿条数据进行排序，排好序后输出到磁盘，总共输出100个文件，最后怎么把这100个文件进行merge成一个全局有序的大文件。我们可以每个文件（有序的）都取一部分头部数据最为一个 buffer， 并且把这 100个 buffer放在一个堆里面，进行堆排序，比较方式就是对所有堆元素（buffer）的head元素进行比较大小， 然后不断的把每个堆顶的 buffer 的head 元素 pop 出来输出到最终文件中， 然后继续堆排序，继续输出。如果哪个buffer 空了，就去对应的文件中继续补充一部分数据。最终就得到一个全局有序的大文件。

如果你能想通我上面举的例子，就差不多搞清楚sortshufflewirter的实现原理了，因为解决的是同一个问题。
SortShuffleWriter 中的处理步骤就是:

• 使用PartitionedAppendOnlyMap或PartitionedPairBuffer在内存中进行排序,排序的K是（partitionId， hash（key））这样一个元组

• 如果超过内存limit,会spill到一个文件中,这个文件中元素也是有序的,首先是按照partitionId的排序,如果partitionId相同,再根据 hash（key）进行比较排序

• 如果需要输出全局有序的文件的时候，就需要对之前所有的输出文件 和 当前内存中的数据结构中的数据进行 merge sort， 进行全局排序