Shuffle原理剖析

如下图：

首先是假设有个节点，上面运行了4个shuffleMaptask,然后呢，节点上只有两个cpu core，同时假设有另外一个节点，上面也运行了4个ResultTask，等着要去获取shufflemaptask的输出数据，来完成比如reducebykey等操作。这时候，每个shufflemaptask，都会为每个resulttask创建一份bucket缓存，以及对应的shuffleBlockFile磁盘文件，shuffemaptask的输出会作为mapstatus，发送到DAGScheduler的MapOutputTrackerMaster中，MapStatus包含了每个ResultTask要拉取的数据的大小，可以从上图中看到每个shufflemaptask先将数据缓存到了bucket内存里，紧接着又存到了shuffleblockFile内存磁盘文件中（bucket：内存里的缓存。shuffleBlockFile：磁盘上的缓存文件。bucket会一点点的刷新到shuffleBlockFile中。），并且可以看到正常的shuffle过程中，shuffleMaptask会为每个resulttask准备一份自己的文件（符合正常逻辑：每个resulttask可能都会拉取自己的key，肯定要去每个计算结果中查找要拉取的key）。这样就是4*4=16份文件。在这当中，每个resulttask会用BlockstoreshuffleFetcher去mapoutputtrackermaster获取自己的要啦去的文件的信息，然后底层通过blockmanager将数据拉取过来。其实上图可以对shuffle来说，就是从mappartitionsRDD-->ShuffleRDD-->mappartitionsRDD的一个转换过程。首先是map端的最开始的数据就是一个mappatitionsRDD,之后就是每个resulttask拉取过来的数据，其实就会组成一个内部的RDD，叫做shuffleedRDD，优先放入内存，其次内存如果不够，就写入磁盘，最后就是每个shuffleTask针对数据进行聚合，最后生成MapPartitionsRDD，就是我们执行的reducebykey等操作希望获得的那个mappartitionsRDD。
这种普通的shuffle，如果shufflemaptask有100个，resulttask也有100个那就是10000个文件，IO过多。

shuffle有两个特点：第一点，在spark早起版本中，bucket缓存是非常重要的，因为要将一个shufflemaptask所有的数据都写入内存缓存之后，才会刷新到磁盘。。但是这就有一个问题，如果mapside的数据过多，那么很容易造成OOM，所以在spark的新版本中，又花了，默认那个内存缓存是100KB,然后，写入一点数据达到了刷新到那个磁盘的阈值之后，就会将数据一点点的刷新到磁盘中。第二点，与MR完全不一样的是，MR它必须将所有的数据都写入本地磁盘文件以后，才能启动reduce操作，来拉取数据。为什么？因为mr要实现默认的根据Key的排序！所以要排序肯定得写完所有数据，才能排序，然后reduce来拉取。但是spark不需要，spark默认情况下，是不会对数据进行排序的。因此shufflemaptask每写入一点数据，resulttask就可以拉取一点数据，然后再本地执行我们定义的聚合函数和算子，进行计算。spark这种机制的好处在于速度比mr快多了，但是也有一个问题，mr提供的reduce时候可以处理me给key对应的value的，很方便。但是spark中，由于这种事实拉取的机制，一次提供不了直接处理key对应的valur的算子，只能通过reducebykey，先shuffle,有一个maptartitionsRDD，然后用map算子，来处理每个key对应的values。就没有MR计算模型那么方便。
此为最原始的shuffle流程，截止目前为止其实spark已经进行了很多版本的不断优化与提升，后面我会整理，具体请见我的其他博客：https://blog.csdn.net/yrsg666/article/details/100098642