Spark[四]——Spark并行度

Posted 2023-04-11

参考技术A

        Spark并行度指在Spark作业中，各个Stage中task的数量，也就代表了Spark作业在各个阶段的并行度。
合理设置并行度可以从以下几个方面考虑 ：

    1.官方推荐：task数量，设置成Spark Application总CPU core数量的2~3倍，同时尽量提升Spark运行效率和速度；
    2.spark.default.paralleism默认是没有值的，如果设置了值，比如10，是在Shuffle中才会起作用。如：val rdd1 = rdd2.reduceByKey(_ + )，rdd2的分区数为10，rdd1的分区数不受这个参数影响；
    3.如果读取的数据在HDFS上，增加block数，默认情况下split与block是一对一的，而split又与RDD中的Partition对应，所以增加了block数，也就提高了并行度；
    4.reduceByKey的算子指定Partition的数量；如val rdd2 = rdd1.reduceByKey( + _, 10)；
    5.val rdd3 = rdd1.join(rdd2)，rdd3里Partition的数量由父rdd中最多的Partition数量决定，因此使用join算子时，应增加父rdd中的Partition数量；
    6.设置 spark.sql.shuffle.partition ，配置Spark SQL中shuffle过程中Partition的数量。

重要 | Spark分区并行度决定机制

最近经常有小伙伴在本公众号留言，核心问题都比较类似，就是虽然接触Spark有一段时间了，但是搞不明白一个问题，为什么我从HDFS上加载不同的文件时，打印的分区数不一样，并且好像spark.default.parallelism这个参数时不是一直起作用？其实笔者之前的文章已有相关介绍，想知道为什么，就必须了解Spark在加载不同的数据源时分区决定机制以及调用不用算子时并行度决定机制以及分区划分。

其实之前的文章《Spark的分区》、《通过spark.default.parallelism谈Spark并行度》已有所介绍，笔者今天再做一次详细的补充，建议大家在对Spark有一定了解的基础上，三篇文章结合一起看。

大家都知道Spark job中最小执行单位为task，合理设置Spark job每个stage的task数是决定性能好坏的重要因素之一，但是Spark自己确定最佳并行度的能力有限，这就要求我们在了解其中内在机制的前提下，去各种测试、计算等来最终确定最佳参数配比。

Spark任务在执行时会将RDD划分为不同的stage，一个stage中task的数量跟最后一个RDD的分区数量相同。之前已经介绍过，stage划分的关键是宽依赖，而宽依赖往往伴随着shuffle操作。对于一个stage接收另一个stage的输入，这种操作通常都会有一个参数numPartitions来显示指定分区数。最典型的就是一些ByKey算子，比如groupByKey(numPartitions: Int)，但是这个分区数需要多次测试来确定合适的值。首先确定父RDD中的分区数（通过rdd.partitions().size()可以确定RDD的分区数），然后在此基础上增加分区数，多次调试直至在确定的资源任务能够平稳、安全的运行。

对于没有父RDD的RDD，比如通过加载HDFS上的数据生成的RDD，它的分区数由InputFormat切分机制决定。通常就是一个HDFS block块对应一个分区，对于不可切分文件则一个文件对应一个分区。

对于通过SparkContext的parallelize方法或者makeRDD生成的RDD分区数可以直接在方法中指定，如果未指定，则参考spark.default.parallelism的参数配置。下面是默认情况下确定defaultParallelism的源码：

override def defaultParallelism(): Int = {
    conf.getInt("spark.default.parallelism", math.max(totalCoreCount.get(), 2))
}

通常，RDD的分区数与其所依赖的RDD的分区数相同，除非shuffle。但有几个特殊的算子：

1. coalesce和repartition算子

笔者先放两张关于该coalesce算子分别在RDD和DataSet中的源码图：（DataSet是Spark SQL中的分布式数据集，后边说到Spark时再细讲）

通过coalesce源码分析，无论是在RDD中还是DataSet，默认情况下coalesce不会产生shuffle，此时通过coalesce创建的RDD分区数小于等于父RDD的分区数。 

笔者这里就不放repartition算子的源码了，分析起来也比较简单，图中我有所提示。但笔者建议，如下两种情况，请使用repartition算子：

1）增加分区数repartition触发shuffle，shuffle的情况下可以增加分区数。

coalesce默认不触发shuffle，即使调用该算子增加分区数，实际情况是分区数仍然是当前的分区数。

2）极端情况减少分区数，比如将分区数减少为1调整分区数为1，此时数据处理上游stage并行度降，很影响性能。此时repartition的优势即不改变原来stage的并行度就体现出来了，在大数据量下，更为明显。但需要注意，因为repartition会触发shuffle，而要衡量好shuffle产生的代价和因为用repartition增加并行度带来的效益。

 

2. union算子

还是直接看源码：

 

通过分析源码，RDD在调用union算子时，最终生成的RDD分区数分两种情况：1）union的RDD分区器已定义并且它们的分区器相同

多个父RDD具有相同的分区器，union后产生的RDD的分区器与父RDD相同且分区数也相同。比如，n个RDD的分区器相同且是defined，分区数是m个。那么这n个RDD最终union生成的一个RDD的分区数仍是m，分区器也是相同的

2）不满足第一种情况，则通过union生成的RDD的分区数为父RDD的分区数之和4.cartesian算子

通过上述coalesce、repartition、union算子介绍和源码分析，很容易分析cartesian算子的源码。通过cartesian得到RDD分区数是其父RDD分区数的乘积。

在Spark SQL中，任务并行度参数则要参考spark.sql.shuffle.partitions，笔者这里先放一张图，详细的后面讲到Spark SQL时再细说：

看下图在Spark流式计算中，通常将SparkStreaming和Kafka整合，这里又分两种情况：

1. Receiver方式生成的微批RDD即BlockRDD，分区数就是block数

2. Direct方式生成的微批RDD即kafkaRDD，分区数和kafka分区数一一对应
等说到Spark流式处理时再详细阐述。

---

关注微信公众号：大数据学习与分享，获取更对技术干货