链接：https://pan.baidu.com/s/1DQVnqO8Wlk3Qv4QB1MpGkw 

提取码：wamm 

 

优先级 上面两个参数都是设置默认的并行度，但是适用的场景不同： spark.sql.shuffle.partitions 是对 sparkSQL 进行 shuffle 操作的时候生效，比如 join 或者 aggregation 等操作的时候，之前有个同学设置了 spark.default.parallelism 这个并行度为 6

7 2000，结果还是产生 200 的 stage，排查了很久才发现，是这个原因。 spark.default.parallelism 这个参数只是针对 rdd 的 shuffle 操作才生效，比如 join，reduceByKey。 具体现象 内存 CPU比例失调 一个 Spark任务消耗 120(executor)*4G = 480G 内存仅仅使用 120 个 core. 几个 SprakSQL 任务就将整个系统资源吃光. 设置超过 40 个 executor,但未指定分区数,导致多数 executor 空闲. 原因分析 SparkSQL 配置时 Core 与内存比例不恰当 没有指定 executor 核心数 未进行其他配置参数优化 解决办法 在配置 SparkSQL 任务时指定 executor 核心数 建议为 4 (同一 executor[进程]内内存共享,当数据倾斜时,使用相同核心数与内存量的两个任 务,executor 总量少的任务不容易 OOM,因为单核心最大可用内存大.但是并非越大越好,因为 单个 exector 最大 core 受服务器剩余 core 数量限制,过大的 core 数量可能导致资源分配不足) 设置 spark.default.parallelism=600 每个 stage 的默认 task 数量 (计算公式为 num-executors * executor-cores 系统默认值分区为 40,这是导致 executor 并行度 上不去的罪魁祸首,之所以这样计算是为了尽量避免计算最慢的 task 决定整个 stage 的时间, 将其设置为总核心的 2-3 倍,让运行快的 task 可以继续领取任务计算直至全部任务计算完毕) 开启 spark.sql.auto.repartition=true 自动重新分区 (每个 stage[阶段]运行时分区并不尽相同,使用此配置可优化计算后分区数,避免分区数过大 导致单个分区数据量过少,每个 task 运算分区数据时时间过短,从而导致 task 频繁调度消耗过 多时间) 设置 spark.sql.shuffle.partitions=400 提高 shuffle 并行度 (shuffle read task 的并行度) 设置 spark.shuffle.service.enabled=true 提升 shuffle 效率 --!并未测试 (Executor 进程除了运行 task 也要进行写 shuffle 数据,当 Executor 进程任务过重时,导致 GC 不能为其他 Executor 提供 shuffle 数据时将会影响效率.此服务开启时代替 Executor 来抓取 shuffle 数据) 1.1、指定并行的 task 数量 spark.default.parallelism 参数说明：该参数用于设置每个 stage 的默认 task 数量。这个参数极为重要，如果不设置可 能会直接影响你的 Spark 作业性能。 参数调优建议：Spark 作业的默认 task 数量为 500~1000 个较为合适。很多同学常犯的一个 错误就是不去设置这个参数，那么此时就会导致 Spark 自己根据底层 HDFS 的 block 数量来 设置 task 的数量，默认是一个 HDFS block 对应一个 task。通常来说，Spark 默认设置的数量 是偏少的（比如就几十个 task），如果 task 数量偏少的话，就会导致你前面设置好的 Executor 的参数都前功尽弃。试想一下，无论你的 Executor 进程有多少个，内存和 CPU 有多大，但 是 task 只有 1 个或者 10 个，那么 90%的 Executor 进程可能根本就没有 task 执行，也就是白 白浪费了资源！因此 Spark 官网建议的设置原则是，设置该参数为 num-executors * executor-cores 的 2~3 倍较为合适，比如 Executor 的总 CPU core 数量为 300 个，那么设置 1000 个 task 是可以的，此时可以充分地利用 Spark 集群的资源。 Spark 性能调优之合理设置并行度 1.Spark 的并行度指的是什么？