YARN配置Spark参数怎么写？提交任务内存如何分配

高效配置 Spark on Yarn 的核心在于精确计算 Executor 资源总量、合理设置堆外内存比例，并启用动态分配机制以应对业务波动，从而在保证作业不 OOM（内存溢出）的前提下最大化集群吞吐量，这不仅仅是简单的参数调整，而是对计算资源、网络带宽与 I/O 吞吐的综合平衡艺术。

核心资源配置：计算与分配的艺术

在 Spark on Yarn 的架构中，资源配置的基石在于 Executor 的数量、每个 Executor 的核心数以及内存大小，这三者的组合直接决定了作业的并行度和资源利用率。

每个 Executor 的核心数（spark.executor.cores）建议设置为 5 或 6，这是一个经过大量实践验证的“黄金值”，如果设置过低（如 1 或 2），虽然并行度高，但会导致大量的 JVM 进程启动，增加 Hadoop RPC 的通信压力和 GC（垃圾回收）的开销；如果设置过高（如 16 或 32），虽然减少了 JVM 数量，但容易受限于单节点的网络带宽和磁盘 I/O，导致 HDFS 读写成为瓶颈，同时也增加了 GC 的停顿时间。

Executor 内存（spark.executor.memory）的计算必须预留堆外内存，许多初学者容易犯的错误是将 Yarn 容器的内存等同于 Spark 的堆内存，Yarn 分配的内存 = Spark 堆内存 + 堆外内存，堆外内存用于用户数据结构、内部元数据以及 Shuffle 过程中的数据传输。经验公式建议堆外内存设置为堆内存的 10% 到 20%，且最大不超过 1GB，如果申请 4GB 的堆内存，Yarn 容器内存应至少设置为 5GB（spark.yarn.executor.memoryOverhead 设置为 1GB）。严禁将 Executor 内存设置得接近或超过节点的物理内存上限，必须为操作系统和其他系统进程预留至少 10-15% 的内存，否则极易引发节点崩溃。

内存管理深度剖析：规避 OOM 陷阱

在解决了资源总量问题后,内部内存的管理是决定作业稳定性的关键，Spark 1.6 之后引入了统一内存管理机制，我们需要精细调整 spark.memory.fraction 和 spark.memory.storageFraction。

核心原则是平衡执行内存与存储内存的竞争，执行内存用于 Shuffle、Join、Aggregation 等操作，存储内存用于缓存数据，如果作业主要是计算密集型且涉及大量 Shuffle，应适当降低 spark.memory.storageFraction（默认 0.5），确保执行内存充足，避免频繁的磁盘溢出；反之，如果作业需要大量缓存 RDD 进行迭代计算，则应提高该比例。

开启堆外内存优化（spark.memory.offHeap.enabled）是处理大数据量 Shuffle 的利器，堆外内存不受 JVM GC 管理，能够显著减少 Full GC 的频率和停顿时间，特别是在处理 TB 级数据排序时，开启此选项并设置合理的 spark.memory.offHeap.size 往往能带来 20% 以上的性能提升。

动态资源分配：应对业务波动的利器

静态资源配置往往面临两难：配置少了，作业跑不完；配置多了，资源浪费。Spark 的动态资源分配（Dynamic Resource Allocation）是解决这一矛盾的专业方案。

通过设置 spark.dynamicAllocation.enabled 为 true，Spark 可以根据任务队列的积压情况动态增减 Executor 数量。关键在于合理配置 spark.dynamicAllocation.minExecutors 和 spark.dynamicAllocation.maxExecutors，最小值应保证作业能够启动，最大值则受限于集群剩余资源，为了配合动态分配，必须配置 spark.shuffle.service.enabled，确保 Executor 被移除后，Shuffle 文件仍能被其他 Executor 读取，这一步在 Yarn 环境下至关重要。

酷番云实战案例：电商大促日志分析优化

在某知名电商客户的大促日志分析项目中,我们曾遇到典型的资源瓶颈，该作业每日处理 PB 级原始日志，集群规模为 100 台节点，初期配置采用了“大 Executor”策略（每个 Executor 16 核、64GB 内存），导致频繁 Full GC，且节点经常因内存超限被 Yarn Kill。

酷番云技术团队介入后，实施了以下优化方案：

1. 调整核心架构：将 Executor 调整为 5 核、20GB 堆内存 + 4GB 堆外内存。
2. 启用堆外内存：开启 Off-heap 内存，优化 Shuffle 性能。
3. 结合酷番云高性能计算实例：利用酷番云云服务器的高吞吐网络特性，我们将 spark.executor.instances 初始值设为 200，并开启动态分配，最大扩展至 500 个 Executor。

优化结果令人瞩目：作业完成时间缩短了 45%，GC 时间占比从 15% 降至 2% 以下，且在大促高峰期通过动态伸缩，成功应对了 3 倍的数据洪峰，集群资源利用率提升了 40%，这一案例证明，在云原生环境下，合理的参数配合弹性计算资源，能最大程度释放 Spark 的性能潜力。

相关问答

Q1：在 Spark on Yarn 中，经常遇到 “Container killed by YARN for exceeding memory limits” 错误，除了增加内存外，还有哪些排查方向？
A1：这是一个常见但容易被误解的问题，除了增加内存，首先应检查 spark.yarn.executor.memoryOverhead 是否设置过小，如果任务涉及大量广播变量或 UDF 使用了复杂的第三方库，堆外内存消耗可能远超默认值，排查是否存在数据倾斜，单个 Task 处理的数据量过大导致内存暴涨，解决思路包括：提高堆外内存上限、对倾斜 Key 进行加盐处理、或者优化代码减少对象创建。

Q2：如何判断 Executor 的数量设置是否合理？
A2：判断标准主要看两点：一是 CPU 利用率，通过监控发现 CPU 长期处于 100% 且任务等待队列过长，说明 Executor 或 Core 不足；二是 GC 日志，如果频繁出现 Full GC 且 GC 停顿时间占任务总时间的比例超过 10%，说明 Executor 内存过大或数量过多导致 JVM 压力过大，合理的配置应追求 CPU 高负载但不过载，且 GC 时间占比控制在 5% 以内。

您在实际的 Spark 任务调优中，是否遇到过因数据倾斜导致的资源分配难题？欢迎在评论区分享您的应对策略，我们将共同探讨更高效的解决方案。