在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机制
时间: 2024-11-03 05:29:30