Spark on YARN配置怎么做，配置参数怎么设置？

Spark on YARN 的配置直接决定了大数据计算任务的吞吐量、稳定性与资源利用率。核心上文小编总结在于：精准的资源配置必须基于 YARN 的容器模型，通过平衡 Executor 内存与堆外内存、合理规划 CPU 虚拟核心以及启用动态分配，才能在避免 OOM（内存溢出）的同时最大化集群并行计算能力。 以下将从部署架构、内存精细化管理、CPU 并行度优化以及实战案例四个维度展开深度解析。

部署模式与架构选择

在 Spark on YARN 的环境中，首要任务是明确 Driver 程序的运行位置，这直接决定了任务的提交方式与日志获取的便捷性。YARN Client 模式适用于开发调试与交互式查询，Driver 运行在本地客户端，便于通过控制台实时查看 Log；而 YARN Cluster 模式则是生产环境的首选，Driver 运行在 ApplicationMaster（AM）容器中，即使客户端断开，任务依然在集群内持续运行，极大地提升了高可用性。

在配置 spark-submit 时，必须严格区分 --driver-memory 与 --executor-memory，Driver 端主要负责调度与 DAG 构建，内存需求通常较小；而 Executor 端负责繁重的数据处理，是资源调优的重中之重，对于超大规模集群，建议开启 spark.yarn.am.waitTime 优化 AM 启动超时机制，防止因资源排队导致的任务假死。

内存资源精细化配置

内存配置是 Spark on YARN 最容易出现问题的环节，核心在于理解 YARN 的 Container 内存模型。YARN 分配给每个 Executor 的内存总量并非全部用于 Spark 堆内内存，而是由堆内内存、堆外内存（Off-Heap Memory）以及用于安全缓冲的 Memory Overhead 组成。

配置公式为：Container Memory = spark.executor.memory + spark.yarn.executor.memoryOverhead。

许多初学者往往忽略了 spark.yarn.executor.memoryOverhead，默认值仅为 executor 内存的 10%，最大通常为 384MB，在处理大量 Shuffle 数据或使用堆外缓存时，默认 Overhead 极易导致 Container 被 YARN NodeManager 杀死。专业建议是将 Overhead 设置为 executor 内存的 15% 至 20%，或者显式设置 spark.memory.offHeap.enabled 为 true 并调整 spark.memory.offHeap.size，以利用堆外内存存储 Shuffle 数据，减少 GC 压力。

JVM 的垃圾回收机制也至关重要，建议在 spark.executor.extraJavaOptions 中配置使用 G1 垃圾收集器（-XX:+UseG1GC），并限制单次 GC 的停顿时间（-XX:MaxGCPauseMillis=200），这能显著提升大规模数据集处理时的性能表现。

CPU 核心与并行度调优

CPU 资源的配置直接影响任务的并行度。每个 Executor 拥有的核心数（spark.executor.cores）决定了该 Executor 内部可以同时运行的 Task 数量。 在生产环境中，建议将 spark.executor.cores 设置为 5 或 6，过高的核心数（如接近物理核数）会导致严重的 HDFS I/O 争抢和 GC 瓶颈，而过低则无法充分利用 CPU 的计算能力。

必须关注 spark.task.cpus，默认每个 Task 占用 1 核心，如果任务包含密集的计算逻辑（如复杂的正则匹配或加密解密），可适当增加该值。并行度的黄金法则是确保 spark.default.parallelism（默认并行度）至少设置为集群总 Executor 核心数的 2 到 3 倍，如果并行度设置过低，会导致部分 CPU 核心闲置；设置过高则会产生过多的调度开销，对于 Shuffle 阶段，spark.sql.shuffle.partitions 也应遵循同样的原则，通常建议设置为总核心数的 2 到 4 倍，以避免产生大量小文件。

动态资源分配策略

为了应对业务流量的波峰波谷,启用 Spark 的动态资源分配（Dynamic Resource Allocation）是提升集群整体利用率的关键手段。 通过设置 spark.dynamicAllocation.enabled 为 true，Spark 可以根据 pending tasks 的数量动态向 YARN 申请或释放 Executor。

关键配置参数包括：

• spark.dynamicAllocation.initialExecutors：初始 Executor 数量，避免任务启动时资源申请过慢。
• spark.dynamicAllocation.minExecutors 与 maxExecutors：设定资源波动的上下限，防止占用过多资源或资源不足。
• spark.dynamicAllocation.schedulerBacklogTimeout：当有任务等待超过该时间（秒）时触发扩容。

配合 YARN 的 spark.shuffle.service.enabled 启用外部 Shuffle 服务，可以确保在 Executor 被移除时，Shuffle 文件依然可被其他 Executor 访问，这是动态分配生效的前提条件。

酷番云实战经验案例

在酷番云提供的企业级大数据托管服务中,曾协助一家电商客户解决其每日离线数仓任务频繁超时的问题。现象是：在处理大促期间产生的 TB 级交易日志时，Spark 任务频繁因 Container Killed by YARN 失败。

诊断与解决方案：
经过深入分析，我们发现客户采用了默认的内存 Overhead 配置，且开启了大量的广播变量，在 Shuffle 阶段，堆外内存急剧膨胀，突破了 YARN Container 的物理限制。
基于酷番云对底层硬件的深度调优经验，我们制定了针对性的配置方案：

1. 调整内存模型：将 spark.executor.memory 调整为 12GB，同时显式将 spark.yarn.executor.memoryOverhead 提升至 3GB，确保 Container 总内存达到 15GB，留足系统缓冲。
2. 启用堆外优化：开启 spark.memory.offHeap.enabled 并分配 2GB 空间，用于 Tungsten 内存管理，减少 Java 对象开销。
3. CPU 绑定优化：利用酷番云云主机的 CPU 亲和性特性，将 spark.executor.cores 锁定为 5，避免 NUMA 架构下的跨插槽内存访问延迟。

最终效果：通过上述调整，任务 OOM 率降至 0%，整体作业运行时间缩短了 40%，且在业务低峰期通过动态分配自动释放了 30% 的计算资源，显著降低了云资源成本。

序列化与 Shuffle 传输优化

除了资源参数,数据传输效率同样不可忽视。默认的 Java 序列化机制效率较低且体积较大，强烈建议切换为 Kryo 序列化。 配置 spark.serializer 为 org.apache.spark.serializer.KryoSerializer，并注册自定义类以获得最佳性能。

在 Shuffle 传输过程中，开启压缩可以大幅减少网络 I/O 和磁盘占用，推荐配置 spark.shuffle.compress 和 spark.rdd.compress 为 true，并使用 lz4 或 snappy 算法，它们在压缩比与解压速度之间取得了良好的平衡，对于 Spark SQL 应用，调整 spark.sql.inMemoryColumnarStorage.compressed 也能优化内存缓存的存储效率。

相关问答

Q1：Spark on YARN 中，Executor 数量越多，任务执行速度一定越快吗？
A： 不一定，Executor 数量增加确实能提高并行度，但受限于集群总资源、网络带宽 Shuffle 瓶颈以及 HDFS NameNode 压力，过多的 Executor 会导致大量的 Shuffle Write 和 Read 操作，引发网络拥塞和磁盘 I/O 竞争，反而降低性能，最佳实践是根据数据量和集群资源，通过压测找到最优的 Executor 数量和每个 Executor 的 Core 数。

Q2：如何判断 Spark 任务是内存不足还是 CPU 瓶颈？
A： 可以通过 Spark UI 进行判断，Task 的 GC Time 占比很高（超过 10% 甚至 20%），且频繁出现 Full GC，通常是内存不足或内存分配不合理，Task 的 Input Size 很小但 Duration 很长，或者 Scheduler Delay 较高，说明 CPU 计算能力不足或并行度设置过低，导致任务在队列中长时间等待执行。

希望以上配置方案能帮助您构建高效稳定的 Spark on YARN 环境，如果您在配置过程中遇到特定的性能瓶颈，欢迎在评论区分享您的具体场景，我们将为您提供更进一步的诊断建议。