马上注册，结交更多好友，享用更多功能，让你轻松玩转社区。
您需要 登录 才可以下载或查看，没有账号？立即注册
×
起首是未优化过的 hashshuffle的流程：
在Map阶段会根据上游RDD的分区数天生M个task使命；
然后再reduce阶段会根据卑鄙RDD所需的分区数据天生R个task使命
每个R使命会从M个task使命区获取各自分区的数据，终极声场的文件数就是,M 乘以 R
缺点就是会天生大量小文件，会对IO性能带来压力，以及文件管理节点带来严肃压力。
由于大量发作的小文件标题，以是已经弃用为优化的hashshuffle方式了；
因此对hashshuffle举行了文件归并的优化；
优化的点就是在于 将同一个Excutor实验器的task使命产生的文件都 共享同一个输出文件，
如许每个reduce task中就对应了一个输出文件的多个数据块，reduce task实验完后就归并文件了
如许优化之后，明显的淘汰了文件的数据，如果有实验器的数量 乘以 reduce task的数量
但是对于大批量的数据盘算，如许的优化照旧不敷。
因此现在Spark默认方式就是SortShuffle方式，能有效的淘汰小文件的数据量
在map task使命按照分区天生M个文件后，文件会被排序并进入内存缓存区，如果内存缓存不敷就会溢出到磁盘当中
在reduce拉去数据之前，全部的数据都会归并成一个有序的数据文件，和一个对应分区的索引文件
在Reduce task阶段，按照索引去拉去对应数据
如许在shuffle阶段就只天生了M 乘以 2的文件数据量
缺点就是排序会必要肯定的CPU开销
因此优化出来了一个ByPass 的 sortShuffle ,就是会通过参数设置设置一个文件的阈值，默认是200，
|
发表于 2025-10-21 21:41:12