Spark YARN配置怎么写？核心参数详解有哪些？

Spark on YARN 的配置核心在于资源分配与并行度的精准平衡，要实现高性能的大数据处理，必须摒弃默认配置的粗放管理，转而根据集群硬件拓扑和作业特性进行精细化调优，核心上文小编总结是：通过合理规划 Executor 的内存与 CPU 比例、启用动态资源分配、优化 Shuffle 机制以及利用堆外内存，可以在避免 OOM（内存溢出）的同时最大化集群的吞吐量和资源利用率。

资源分配的核心参数调优

在 Spark on YARN 架构中，资源分配是性能的基石，最关键的三个参数是 spark.executor.instances（Executor 数量）、spark.executor.memory（Executor 内存）和 spark.executor.cores（每个 Executor 的 CPU 核心数）。切忌将 Executor 内存设置得过大，因为这会导致垃圾回收（GC）的时间过长，反而拖慢任务进度，通常建议单个 Executor 的内存控制在 64GB 以内，对于 CPU 核心数，建议设置为 5 或 6，这样既能保留一个核心供系统任务使用，又能为每个 Executor 提供足够的并行度。

Driver 端的内存配置常被忽视，对于收集大量数据的作业，spark.driver.memory 必须适当调大，否则 Driver 端会成为瓶颈。spark.yarn.am.memory（Application Master 内存）也应根据集群规模进行调整，确保 YARN 侧的资源申请不会因为 AM 内存不足而失败，在 YARN 容器层面，必须精确计算 spark.yarn.executor.memoryOverhead，这是堆外内存的开销，用于存储网络缓冲区、Shuffle 文件等，设置过小极易导致 Container 被 YARN Kill 掉。

内存管理与垃圾回收优化

内存调优不仅仅是设置堆内存大小,更在于内存区域的划分，Spark 内存分为 Storage 内存（用于缓存）和 Execution 内存（用于 Shuffle、Join 等），通过调整 spark.memory.fraction 和 spark.memory.storageFraction，可以决定两者在堆内存中的占比，如果作业 Shuffle 量大，应适当调高 Execution 内存的比例；如果作业缓存多，则应向 Storage 倾斜。

为了进一步减轻 GC 压力，强烈建议启用堆外内存，即设置 spark.memory.offHeap.enabled 为 true，并配置 spark.memory.offHeap.size，堆外内存不受 GC 管理，既能减少停顿时间，又能避免 JVM 在处理大对象时的性能损耗，根据 JDK 版本选择合适的 GC 算法至关重要，对于大内存场景，G1GC 通常是优于 ParallelGC 的选择，需要配置 -XX:+UseG1GC 相关参数。

并行度与数据本地性策略

并行度直接决定了集群资源的利用效率,如果并行度过低，CPU 空转；过高，则会产生大量的任务调度开销。最佳实践是将并行度设置为集群总 CPU 核心数的 2 到 3 倍，这可以通过 spark.default.parallelism 和 spark.sql.shuffle.partitions 来控制，需要注意的是，这两个参数分别针对 RDD 和 DataFrame/Dataset API，需要分别配置。

数据本地性对性能影响显著,Spark 会尽量将任务分配到数据所在的节点，如果配置不当，大量的数据会通过网络传输，可以通过调整 spark.locality.wait 系列参数来控制 Spark 等待数据本地化的超时时间，在延迟敏感型场景中，可以适当缩短等待时间，放弃过高的本地性级别（如 NODE_LOCAL），以换取更快的任务启动速度。

Shuffle 机制与数据倾斜处理

Shuffle 是 Spark 作业中最耗时的环节，在 Spark 2.x 及以后版本，默认使用 SortShuffleManager，这是目前最优的选择，为了优化 Shuffle 性能，可以开启 Shuffle 文件合并，即设置 spark.shuffle.consolidateFiles（在特定版本中有效）或利用 Tungsten-Sort 机制。开启 Shuffle Service（spark.shuffle.service.enabled）是必须的，它允许 Executor 即使在运行结束后也能保留 Shuffle 文件供其他 Executor 拉取，这对于动态资源分配和大规模作业至关重要。

数据倾斜是 Shuffle 阶段的头号杀手，专业的解决方案包括：使用 Salting（加盐）技术将倾斜的 Key 分散到多个 Task 中处理；或者利用 Spark 3.x 引入的 AQE（自适应查询执行） 中的 spark.sql.adaptive.skewJoin.enabled 参数，让引擎自动检测并优化倾斜 Join。

酷番云实战案例：TB级日志分析性能优化

在某电商客户的 TB 级日志分析项目中，我们基于酷番云的高性能计算集群进行了深度调优，该客户初始配置使用了大内存 Executor（128GB），导致频繁 Full GC，作业经常超时，我们的优化团队首先将 Executor 拆分为多个小内存实例（每个 48GB，6 Core），并启用了酷番云对象存储作为中间 Shuffle 数据的溢写盘，缓解了本地磁盘 I/O 压力。

针对数据倾斜问题,我们利用酷番云提供的定制化 Spark 镜像，开启了 AQE 动态并发度调整，并自动检测倾斜分区进行拆分，通过调整 spark.executor.memoryOverhead 占比至 20%，彻底解决了 YARN 容器被杀的问题。该客户的 ETL 作业耗时从 6 小时降低至 1.5 小时，资源利用率提升了 40%，这一案例证明，结合云厂商的底层存储优势与合理的 Spark 参数配置，能产生显著的性能红利。

相关问答

Q1：在 Spark on YARN 中，如何判断 Executor 的 CPU 核心数设置是否合理？
A1：判断 CPU 核心数是否合理，主要看集群的总 CPU 利用率和任务的吞吐量，如果每个 Executor 只设置 1 个核心，会导致无法利用 HDFS 的数据本地性并发读取，且无法在 Executor 内部进行 Shuffle 操作的聚合，通常建议设置为 5-6 个核心，如果在监控界面发现 CPU 利用率长期低于 60%，或者每个 Task 处理时间过长，说明核心数可能偏少或并行度不足；反之，如果频繁出现上下文切换或 GC 时间过长，则可能核心数过多导致线程竞争激烈。

Q2：开启动态资源分配后，作业为什么一直不结束？
A2：这通常是因为 spark.dynamicAllocation.shuffleTracking.enabled 未正确配置或 Shuffle Service 未正常工作，动态资源分配需要依据 Shuffle 文件的存在来判断是否可以移除 Executor，Spark 无法追踪哪些 Executor 保留了 Shuffle 数据，它就会为了安全起见保留所有 Executor，确保 spark.shuffle.service.enabled 为 true，YARN 的 AuxiliaryService 已正确启动，同时检查 spark.dynamicAllocation.executorIdleTimeout 和 spark.dynamicAllocation.cachedExecutorIdleTimeout 设置是否过短或过长。

通过以上配置策略与实战经验的结合,您可以构建一个高效、稳定的 Spark on YARN 运行环境，如果您在配置过程中遇到特定的性能瓶颈，欢迎在评论区分享您的参数配置和错误日志，我们将为您提供专业的诊断建议。