【大数据学习 | Spark-Core】详解Spark的Shuffle阶段

发布于:2024-11-28 ⋅ 阅读:(25) ⋅ 点赞:(0)

1. shuffle前言

对spark任务划分阶段,遇到宽依赖会断开,所以在stage 与 stage 之间会产生shuffle,大多数Spark作业的性能主要就是消耗在了shuffle环节,因为该环节包含了大量的磁盘IO、序列化、网络数据传输等操作。

负责shuffle过程的执行、计算和处理的组件主要就是ShuffleManager,也即shuffle管理器。而随着Spark的版本的发展,ShuffleManager也在不断迭代。

ShuffleManager 大概有两个: HashShuffleManager 和 SortShuffleManager。

历史:

在spark 1.2以前,默认的shuffle计算引擎是HashShuffleManager;

在spark 1.2以后的版本中,默认的ShuffleManager改成了SortShuffleManager;

在spark 2.0以后,抛弃了 HashShuffleManager。

2. HashShuffleManager

上游 stage 有 2个 Executor,每个Executor 有 2 个 task。

下游 stage 有 3个task。

shuffle write阶段:

将相当于mapreduce的shuffle write, 上游的mapTask任务的数据按照key的hash 分桶,写出中间文件(个数为下游reduceTask的任务,即下游RDD分区的个数)。

写出中间文件个数 = maptask的个数 * reducetask的个数。

shuffle read 阶段:

就相当于mapreduce 的 shuffle read, 每个reducetask 拉取自己的数据。

由于shuffle write的过程中,task给下游stage的每个task都创建了一个磁盘文件,因此shuffle read的过程中,每个reducetask只要从上游stage的所有maptask所在节点上,拉取属于自己的那一个磁盘文件即可。

弊端:

shuffle write阶段占用大量的内存空间,会导致频繁的GC,容易导致OOM(out of memory);也会产生大量的小文件,写入过程中会产生大量的磁盘IO,性能受到影响。适合小数据集的处理。

3. HashShuffleManager 优化

开启consolidate机制。

设置参数:spark.shuffle.consolidateFiles。该参数默认值为false,将其设置为true即可开启优化机制。

shuffle write阶段

我们知道,如果executor的个数为5个,一个executor上的核心是1个,有10个分区的数据要处理,即一个核心要处理2个任务。

开启consolidate机制后,上游的每个mapTask任务的数据仍然按照key的hashCode值分桶,但每个任务并不会形成很多个中间小文件,而是对于每个executor的每个核来说,只会产生下游reduceTask个数的文件。优化后,HashShuffleManager允许上游的交给由一个executor的一个core处理的多个maptask任务的数据以追加形式写入文件组,这样就可以有效将多个task的磁盘文件进行一定程度上的合并,从而大幅度减少磁盘文件的数量,进而提升shuffle write的性能。

写出中间文件个数 = 上游的CPU核数 * 下游task的个数

shuffle read 阶段

就相当于mapreduce 的 shuffle read, 每个reducetask 拉取自己的数据。

由每个reducetask只要从上游stage的所在节点上,拉取属于自己的那一个磁盘文件即可。

弊端:

优化后的HashShuffleManager,虽然比优化前减少了很多小文件,但在处理大量数据时,还是会产生很多的小文件。

4. SortShuffleManager

Spark在引入Sort-Based Shuffle以前,比较适用于中小规模的大数据处理。为了让Spark在更大规模的集群上更高性能处理更大规模的数据,于是就引入了SortShuffleManager。

shuffle write阶段:

shuffle操作之前,数据会被划分为多个分区。每个分区被发往不同的executor进行计算。在map阶段,每个executor会根据key的hashCode值将数据进行分桶产生小文件。每个桶对应的一个下游分区。在每个桶中,数据会被按照key进行局部排序(这个操作不是必须的),排序后这些小文件会写入到内存中的一个大的shuffle文件。在写入shuffle文件的同时,会生成一个index索引文件。索引文件可以快速定位和读取所需要的键值对数据,而不需要扫描整个文件。

SortShuffleManager不会为每个Reducer中的Task生成一个单独的文件,相反,会把上游中每个mapTask所有的输出数据Data只写到一个文件中并使用了Index文件存储具体 mapTask 输出数据在该文件的位置。

因此 上游 中的每一个mapTask中产生两个文件:Data文件 和 Index 文件,其中Data文件是存储当前Task的Shuffle输出的,而Index文件中存储了data文件中的数据通过partitioner的分类索引。

写出文件数 = maptask的个数 * 2 (index 和 data )

可见,SortShuffle 的产生的中间文件的多少与 上个stage 的 maptask 数量有关

shuffle read 阶段:

下游的Stage中的Task就是根据这个Index文件获取自己所要抓取的上游Stage中产生的数据。

在sortShuffleManager中,我们可以启动byPass机制,不排序的机制。开关的值默认是mapTask的个数是200.
  
触发bypass机制的条件:

shuffle map task的数量小于spark.shuffle.sort.bypassMergeThreshold参数的值(默认200)或者不是聚合类的shuffle算子(比如groupByKey)

5. 总结

回顾整个Shuffle的历史,Shuffle产生的临时文件的数量的变化以此为:

Hash Shuffle:M*R;

Consolidate 方式的Hash Shuffle:C*R;

Sort Shuffle:2*M;

其中:M:上游stage的task数量,R:下游stage的task数量,C:上游stage运行task的CPU核数