Spark参数场景配置
| 参数类型 | 参数 | 参数说明 | 平台默认值 | 场景与建议 |
|---|---|---|---|---|
| 资源申请 | spark.executor.memory | Executor Java进程的堆内存大小 即Executor Java进程的Xmx值 | 2g | 默认设置,或者同时等比例增大,最高不超过默认值的3倍,超过的单独拿出来看下 (注意作业是否数据倾斜） 可根据单个文件大小进行预估 若是orc格式，需乘以2-3倍 |
| 资源申请 | spark.yarn.executor.memoryOverhead | Executor Java进程的off-heap内存，包括JVM overhead，sort,shuffle以及Netty的堆外内存等 | 1g | 保持默认值，建议值1-3g 特殊问题单独拿出来讨论 executor的内存大小限制： spark.executor.memory + spark.yarn.executor.memoryOverhead <= 16G (YARN container最大内存限制) |
| 资源申请 | spark.executor.cores | Executor中同时可以执行的task数目 共享整个excutor内存，cores越多,平均下来单个task占用的资源就越少 | 1 | 建议值1-3 再多需单独拿出来讨论 建议spark.executor.cores * spark.dynamicAllocation.maxExecutors < 5000 (cu, 队列总配额为14000) |
| 资源申请 | spark.dynamicAllocation.maxExecutors | 开启动态资源分配后，同一时刻，最多可申请的executor个数 | 1000 | 流量以及数据量在30亿以上的作业 可提高至2000个（不建议再提高） 其他情况保持默认 当在Spark UI中观察到task较多时，可适当调大此参数，缩短作业执行时间。 一般保持shuffle.partitions / (maxExecutors*executor.cores)=2 |
| 资源申请 | spark.dynamicAllocation.minExecutors | executor的最小个数。平台默认设置为3，即在任何时刻，作业都会保持至少有3个及以上的executor存活 | 3 | 保持默认即可 |
| 资源申请 | spark.memory.fraction | 存储+执行内存占节点总内存的大小，社区版是0.6。平台为了方便的把hive任务迁移到spark任务，把该区域的内存比例调小至0.3 | 0.3 | 没有udf或者udf不会消耗太多内存的任务可以调整到0.5甚至社区版默认的0.6，减少spill的次数，提升性能。HBO参数修改方案v2 |
| 资源申请 | spark.driver.memory | driver使用内存大小 | 10G | 1. 一般不需要更改此设置。 2. 确实需要有大表广播的，可以考虑增加这个数值 |
| 资源申请 | spark.yarn.driver.memoryOverhead | driver进程的off-heap内存 | spark.driver.memory * 0.1，并且不小于384m | 1. 保持默认值即可 |
| 资源申请 | spark.sql.autoBroadcastJoinThreshold | 当执行join时，小表被广播的阈值 当被设置为-1，则禁用广播 该参数设置的过大会对driver和executor都产生压力。 | 26214400 （25M） | 1. 由于我们的表大部分为ORC压缩格式，解压后的数据量达到3-5倍甚至10倍 所以调大该参数需要注意 2. 建议值广播不超过128m |
| 文件合并 | spark.hadoop.hive.exec.orc.split.strategy | 参数控制在读取ORC表时生成split的策略: BI策略以文件为粒度进行split划分； ETL策略会将文件进行切分，多个stripe组成一个split； HYBRID策略当文件的平均大小大于hadoop最大split值（默认256M）时使用ETL策略，否则使用BI策略 | BI模式 | 1. 由于读orc文件时默认按文件划分task(BI模式), 有数据倾斜的表（这里的数据倾斜指大量stripe存储于少数文件中）的情况并发可能不够, 影响执行效率. 可以改成ETL模式 2. 对于一些较大的ORC表，可能其footer较大，ETL策略可能会导致其从hdfs拉取大量的数据来切分split，甚至会导致driver端OOM，因此这类表的读取建议使用BI策略。 3. 流量数据建议采用默认策略，因其存在大量文件和大量小文件 其他情况若发现有处理倾斜，请查看文件大小是否均匀 |
| 文件合并 | spark.hadoop.mapreduce.input.fileinputformat.split.minsize | 计算Split划分时的minSize | 保持默认 | |
| 文件合并 | spark.hadoop.mapreduce.input.fileinputformat.split.maxsize | 控制在ORC切分时stripe的合并处理。具体逻辑是，当几个stripe的大小小于spark.hadoop.mapreduce.input.fileinputformat.split.maxsize时，会合并到一个task中处理。可以适当调小该值，如set spark.hadoop.mapreduce.input.fileinputformat.split.maxsize=134217728。以此增大读ORC表的并发 | 建议值不超过128m | |
| 文件合并 | spark.hadoopRDD.targetBytesInPartition | 读取输入文件时&最终合并小文件时，每个task读取的数据量 | 33554432 （32M） | 1：非grouping set情况 建议67108864, 如果发现读取文件的task较多，可以适当增大该值到128m。 2:grouping set 情况 建议调下该值 降低该值 详见case ----详见作业最后一个阶段遇到shuffle慢节点 |
| 文件合并 | spark.sql.adaptive.shuffle.targetPostShuffleInputSize | 开启spark.sql.adaptive.enabled后，最后一个stage在进行动态合并partition时，会根据shuffle read的数据量除以该参数设置的值来计算合并后的partition数量。所以增大该参数值会减少partition数量，反之会增加partition数量 | 67108864 （64M） | 256m, 可以适当增大或减小 |
| 文件合并 | spark.sql.mergeSmallFileSize | 写入hdfs后小文件合并的阈值。如果生成的文件平均大小低于该参数配置，则额外启动一轮stage进行小文件的合并。 当任务中添加task：Listing leaf files and directorioes for 55 paths | 128000000 | 1. 建议40m，如果最终文件数仍然较多，可适当调大.。 2. 如果输入数据量量大，但是最终结果数据量较少时，可以在最后加一个同时结合distribute by操作。如果最终结果数据量本来就较大，没必要加distribute by。 3. 效率上面建议使用此参数 数据量大时不建议使用distribute by |
| shuffle相关 | spark.sql.shuffle.partitions | reduce阶段(shuffle read)的数据分区，分区数越多，启动的task越多，同时生成的文件数也会越多。 | 2000 | 1. 建议一个partition保持在256mb左右的大小就好。当作业数据较多时，适当调大该值，当作业数据较少时，适当调小以节省资源 2. spark.sql.shuffle.partitions设置过大可能会导致很多reducer同时向一个mapper拉取数据。该mapper由于请求压力过大挂掉或响应缓慢，从而导致fetch failed |
| shuffle相关 | spark.sql.adaptive.shuffle.targetPostShuffleInputSize | 最后一个stage在进行动态合并partition时，会根据shuffle read的数据量除以该参数设置的值来计算合并后的partition数量。所以增大该参数值会减少partition数量，反之会增加partition数量。 | 67108864 （64M） | 1. 建议128m, 可以适当增大或减小 |
| shuffle相关 | spark.sql.statistics.fallBackToHdfs | 当表的文件大小元数据信息不可能用时回退到hdfs计算表的文件大小，从而决定是否使用map join. 分区表如果读入数据较少也不会优化为BroadcastJoin, 可以通过添加该参数优化: | false | 1:建议保持默认 2：如果mapjoin的值不生效 建议设置为true |
| 推测执行 | spark.speculation | spark推测执行的开关，作用同hive的推测执行 | true | 1. 保持默认值即可 |
| 推测执行 | spark.speculation.interval | 开启推测执行后，每隔多久通过checkSpeculatableTasks方法检测是否有需要推测式执行的tasks | 1000ms | 1. 保持默认值即可 |
| 推测执行 | spark.speculation.quantile | 当成功的Task数超过总Task数的spark.speculation.quantile时(社区版默认75%，公司默认99%)，再统计所有成功的Tasks的运行时间，得到一个中位数，用这个中位数乘以spark.speculation.multiplier（社区版默认1.5，公司默认3）得到运行时间门限，如果在运行的Tasks的运行时间超过这个门限，则对它启用推测。 | 0.99 | 1： 如果资源充足，可以适当减小 spark.speculation.quantile和spark.speculation.multiplier的值 2：目前不建议调整 |