在Spark 0.6和0.7时，Shuffle的结果都需要先存储到内存中（有可能要写入磁盘），因此对于大数据量的情况下，发生GC和OOM的概率非常大。因此在Spark 0.8的时候，Shuffle的每个record都会直接写入磁盘，并且为下游的每个Task都生成一个单独的文件。这样解决了Shuffle解决都需要存入内存的问题，但是又引入了另外一个问题：生成的小文件过多，尤其在每个文件的数据量不大而文件特别多的时候，大量的随机读会非常影响性能。Spark 0.8.1为了解决0.8中引入的问题，引入了FileConsolidation机制，在一定程度上解决了这个问题。由此可见，Hash Based Shuffle在Scalability方面的确有局限性。而Spark1.0中引入的Shuffle Pluggable Framework，为加入新的Shuffle机制和引入第三方的Shuffle机制奠定了基础。在Spark1.1的时候，引入了Sort Based Shuffle；并且在Spark1.2.0时，Sort Based Shuffle已经成为Shuffle的默认选项。但是，随着内存成本的不断下降和容量的不断上升，Spark Core会在未来重新将Shuffle的过程全部是in memory的吗？我认为这个不太可能也没太大必要，如果用户对于性能有比较苛刻的要求而Shuffle的过程的确是性能优化的重点，那么可以尝试以下实现方式：
1) Worker的节点采用固态硬盘
2) Woker的Shuffle结果保存到RAMDisk上
3) 根据自己的应用场景，实现自己的Shuffle机制
