在早期版本的Spark中,shuffle过程没有磁盘读写操作,是纯内存操作,后来发现效率较低,且极易引发OOME,较新版本的Shuffle操作都加入了磁盘读写进行了改进。
1、未经优化的HashShuffleManager:上一个stage中每一个task会对下一个stage的每一个task写一份数据文件,假定上一个stage有N个task,下一个stage有M个task,此时由上到下形成N个1对M的映射关系,总共产生【N M】个文件。这种方式的优点是思路简单,数据文件的逻辑隔离性更强。缺点是在磁盘上产生的文件个数太多,每个文件的读写都需要建立管道等操作,过多的文件势必增加额外的开销,效率较低。【同将多个小文件打包为一个大文件再拷贝,比直接拷贝多个小文件更快,一个道理】
2、优化过的HashShuffleManager:上一个stage中每一个task共同写下一个stage的每一个task独有的数据文件,假定上一个stage有N个task,下一个stage有M个task,此时由上到下形成M个N对1的映射关系,总共产生M个文件(文件数量只取决于下一个stage的task数量)。由于文件数量的减少,性能得到了一定的提升。
**
3、SortShuffleManager:这是当前版本中使用的方式,进一步减少数据文件个数,阶段之间只通过2个文件来传递数据【索引文件、数据文件】。在上一个阶段中,每个task都将数据在内存中进行排序生成文件(如果内存不够用就溢写到磁盘),将多个排序后的文件合并到同一个数据文件中,配合索引文件,下游task就能高效的完成读取操作。
由于排序操作是一个相对低效的操作,所以在小数据量时可以使用Hash算法来达到快速定位的目的。此时就轮到bypass机制,其内容是当shuffle-map-task数量小于bypassMergeThreshold(默认200个)时或者不是聚合类shuffle,就不采用排序而换为Hash操作。
|
|