大数据--spark生态7--spark的shuffle过程详解

目录

一： 理解shuffle

二： shuffle write

2.1 shuffle write的目标

2.2 shuffle write的位置

2.3 桶（bucket）

2.4 默认分区算法

2.5 bucket数量太多的解决方案

三： shuffle read

3.1 在什么时候fetch

3.2 边fetch边处理还是一次性fetch完再处理？

3.3 fetch来的数据存放在哪？

3.4 如何获得要fetch的数据的存放位置？

3.5 reduce端的shuffle

---

一： 理解shuffle

        如果我们将map端划分数据，持久化数据的过程称为shuffle write，而将reduce端读入数据，aggregate数据的过程称为shuffle read，那么在spark中，问题就变成怎么在job的逻辑或者物理执行中图中加入shuffle write和shuffle read的处理逻辑？以及两个处理逻辑如何高效实现。

二： shuffle write

2.1 shuffle write的目标

由于不要求数据有序，shuffle write的任务很简单，将数据partition好，并持久化，需要持久化的原因，一方面是要减少内存存储空间压力，另外一方面是为了容错考虑。

2.2 shuffle write的位置

将shuffle write的处理逻辑加入到shuffleMapStage（shuffleMapTask所在的stage）的最后，该stage的最后的rdd每输出一个record就将其分区（partition）并且持久化。如图所示：

        上图有 4 个 ShuffleMapTask 要在同一个 worker node 上运行，CPU core 数为 2，可以同时运行两个 task。每个task的执行结果（该stage的finalRDD中某个partition包含的records）被逐一写到本地磁盘上。每一个Map任务会根据Reduce任务的数量创建出相应的桶（bucket），因此桶的数量是m*r,其中m是map任务个数，r是reduce任务的个数。

2.3 桶（bucket）

        bucket是一个抽象的概念，代表shufflemap task输出结果经过partition后要存放的地方。从这个角度来看，bu