1、shuffle分类
spark的shuffle机制可以分为3类，分别是HashShuffleManager、SortShuffleManager、tungsten-sortShuffleManager（钨丝ShuffleManager），下面对着几种shuffle机制进行详细的介绍
2、HashShuffleManager
普通的HashShuffleManager
HashShuffleManager 是早期的Spark版（1.2之前）本中的默认的shuffle的机制，但是这种shuffle机制有很明显的缺陷，下面是hashShuffleManager的原理图
下面图中是有两个executor， 每个executor中有一个cpu core，所以每个executor中的并行度是1，在进行shuffle的过程，，map端shuffle的数据回先写到bucket缓存中（32kb）,当达到一定的大小时，会溢写到磁盘上，每个Map task会为每个reduce task产生一份数据，所以map端一共产生的小文件是就是 map task 数* reduce task数
假设一共有100个map task 和 100 个reduce task， 那么产生的小文件个数时10000个小文件，这么多小文件带来很多问题：
(1)写磁盘的小文件多，IO多
(2)reduce 端读取数据时建立的 连接多
(3)占用内存多，频繁gc,gc时会对外停止工作， 还可能导致oom内存溢出
如果说一台机器是32核 双线程，那么它能够并行的map task的数量是64个，如果有1000个reduce task，那么所占用的内存就会有的64 * 100 * 32kb 是2个多G，非常占用内存
(4)在拉去数据时，可能会跨节点连接，跨节点连接可能会由于网络不稳定，连接中断，很耗时
优化或的HashShuffleManager
优化后HhashShuffleManager（启用consolidation）,对于普通的HashShuffleManager来说，它可以复用缓存和复用文件，
还是聚上面的例子，假设100 个map task 和 100 reduce task， 一共有20 个cup core， 那么并行的task的数量是20个，每执行一批task （20个），他们都会为每个reduce task产生一个 文件，所以一共是 20 * 100= 2000个，在执行下一批时，会复用这些缓存和 文件块，所以一共产生的文件数时20 * 100=2000，相比于普通的HashShuffleManage产生10000个文件来说，这种优化后的大大减少了小文件的个数，优化后的小文件数是
cpu core * reduce task 数,这种优化后的机制产生的文件个数，在很大程度上是由cup core数决定的，如果cup 数太大比如64 个CPU core， 也并没有减少多少，所有上面提到的问题还是存在，所以这也是为什么在spark 1.2之后默认不再使用HashShuffleManager了
3、 SortShuffleManager
1.2之后默认使用的是这种shuffle机制
普通的SortShuffleManager
这种sortShuffleManage在map task进行shuffle时，会把结果先写到内存结构中，内存结构的大小默认是5M，有一个不定期估测机制，根据写的速度它会估测下一次写入的大小是多少，假设它估算下一次的存储的内存时5.6M,那么它会申请给的内存时5.3*2-5=5.6M,那么此时的内存就是10.6M，下一次还是如此，估算的两倍-当前，要不到的时候就会溢写，溢写的过程中默认会进行排序， 然后在分批次写入到内存缓存中，每次每个批次是1万条，再溢写到磁盘文件中， 再进行merger 最后生成两个文件，一个索引文件，一个数据文件，当reduce task 来拉去数据时，会先访问索引文件，然后再访问数据文件。
对于这种sortShuffleManager中的，每个map task产生2个文件，所以如果 有100map task，一共产生的小文件个数是200 ，也就是map task数 * 2，相对于HashShuffleManager来说，大大减少了小文件
bypass SortShuffleManager
这种 bypass SortShuffleManager，通过下面的图，可以很明显的看出和上面不一样的是 没有排序，其他和上面的那个很类似
bypass只是少了排序的过程，其他都是一样的当reduce task的个数小于spark.shuffle.sort.bypassMergeThreshold参数(默认是200)的个数时，默认是使用byPass机制，不进行排序
4、钨丝ShuffleManager
Tungsten-sort优化点主要在三个方面:
直接在serialized binary data上sort而不是java objects，减少了memory的开销和GC的overhead。
提供cache-efficient sorter，使用一个8bytes的指针，把排序转化成了一个指针数组的排序。
spill的merge过程也无需反序列化即可完成
这些优化的实现导致引入了一个新的内存管理模型，类似OS的Page，对应的实际数据结构为MemoryBlock,支持off-heap 以及 in-heap 两种模式。为了能够对Record 在这些MemoryBlock进行定位，引入了Pointer（指针）的概念。