使用repartition解决Spark SQL低并行度的性能问题

最新推荐文章于 2024-07-03 07:15:00 发布

matao_jack

最新推荐文章于 2024-07-03 07:15:00 发布

阅读量412

点赞数

分类专栏： spark

本文链接：https://blog.csdn.net/Piratesa/article/details/100999571

版权

本文探讨了在Spark SQL中遇到低并行度导致性能问题的场景，指出Spark SQL默认根据Hive表的block自动设置并行度，这可能在处理复杂业务逻辑时造成效率低下。解决方案是利用repartition算子重新分区，从而提高后续操作的并行度和任务数量，提升整体执行速度。

摘要由CSDN通过智能技术生成

并行度：并行度是自己可以调节，或者说是设置的。

1、spark.default.parallelism
2、textFile()，传入第二个参数，指定partition数量（比较少用）

实际上，在生产环境中，是最好自己设置一下的。官网有推荐的设置方式，你的spark-submit脚本中，会指定你的application总共要启动多少个executor，100个；每个executor多少个cpu core，2~3个；总共application，有cpu core，200个。

官方推荐，根据你的application的总cpu core数量（在spark-submit中可以指定，200个），自己手动设置spark.default.parallelism参数，指定为cpu core总数的2_3倍。400600个并行度。600。

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

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

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