spark算子调优 使用repartition解决Spark SQL降低并行度的性能问题

设置的并行度，在哪些情况下会生效？哪些情况下不会生效？

如果你压根没有使用sparkSQL（DataFrame）,那么你整个spark application默认所偶stage的并行度都是你设置的那个参数，（除非你使用coalesce算子缩减过partition数量）

 

问题来了，用spark sql的那个stage的并行度，你没法自己指定，spark sql自己会默认根据hive表对应的hdfs文件的block,自动设置spark sql查询所在的那个stage的并行度，你自己通过spark.default.parallelism参数指定的并行度，只会在没有spark sql的stage中生效

 

比如你的第一个stage用了spark sql从hive表中查询处理一些数据，然后做了transformation操作，接着做了一个shuffle操作，下一个stage，在shuffle操作之后，做了一些transformation1操作，hive表，对应了一个hdfs文件，有20个block;你自己你的第一个stage的并行度，是不受你的控制的，就只有20个task

 

问题在哪里？

spark SQL默认情况下，它的那个并行度，咱们没法设置。可能导致的问题，也许没有什么问题，也许很有问题，spark sql所在的那个stage中，后面的那些transformation操作会有非常复杂的业务逻辑，甚至说复杂的算法。如果你的Spark SQL默认把task数量设置的很少，20个，每个task要处理很大的数据量，还要执行复杂的算法

这个时候，就会导致你的第一个stage的速度特别慢

 

解决上述spark sql无法设置并行度和task数量的方法？

repartition算子，用spark sql这一步的并行度和task数量，没有办法改变，但是，可以将你用spark sql查询出来的RDD,使用repartition算子去重新进行分区，此时可以分区成多个partition,比如从20个partition，分区成100个partition

然后呢，从repartition以后的RDD,在往后，并行度和task数量，就会按照你预期的来了，就可以避免和spark sql绑定在一个stage中的算子，只能使用少量的task来处理大数据，复杂逻辑