在大数据处理日益成为企业数字化转型核心的今天，Apache Spark 作为分布式计算框架的首选，其性能表现直接决定了数据中台、数字孪生和数字可视化系统的响应速度与稳定性。然而，许多企业在部署 Spark 任务时，常因参数配置不当导致资源浪费、任务延迟甚至 OOM（Out of Memory）崩溃。其中，并行度与内存调优是影响 Spark 性能最关键的两大维度。本文将深入解析如何在生产环境中系统性地优化这两个参数，实现资源利用率最大化与任务执行效率的双重提升。

一、并行度：让计算资源“满载运行”

并行度（Parallelism）决定了 Spark 作业中任务（Task）的并发数量，直接影响数据处理的吞吐量。默认情况下，Spark 的并行度由集群的 CPU 核心数决定，但这一默认值往往无法匹配实际数据规模与业务需求。

✅ 1.1 并行度的核心逻辑

Spark 的并行度由两个关键参数控制：

• spark.default.parallelism：用于 RDD 操作（如 reduceByKey, join）的默认分区数。
• spark.sql.adaptive.enabled + spark.sql.adaptive.coalescePartitions.enabled：在 SQL 引擎中动态调整分区数（Spark 3.0+ 推荐启用）。

最佳实践：并行度应 ≈ 集群总核心数 × 2~3

例如，一个拥有 20 个 Executor、每个 4 核的集群，总核心数为 80，则建议设置：

spark.default.parallelism=160

这样可确保每个核心同时处理 2 个任务，有效掩盖 I/O 延迟，提升资源利用率。

✅ 1.2 分区数与数据量的匹配

若数据量过小（如 1GB）而分区数过多（如 200），会导致大量小任务，调度开销远超计算收益。反之，若数据量大（如 500GB）但分区数过少（如 10），则单个任务处理时间过长，拖慢整体进度。

推荐公式：

分区数 = 数据量（GB） × 100 / 每个分区目标大小（MB）

假设目标分区大小为 128MB，则：

500GB × 100 / 128 ≈ 390 个分区

可通过 repartition() 或 coalesce() 显式调整：

df.repartition(390).write.mode("overwrite").parquet("/output")

⚠️ 注意：避免在宽依赖操作（如 groupByKey）前进行不必要的 repartition，否则可能引发 Shuffle 暴增。

✅ 1.3 动态并行度：启用 AQE（Adaptive Query Execution）

Spark 3.0 引入的 AQE 可在运行时自动合并小分区、优化 Join 策略。开启后，系统能根据实际数据分布动态调整并行度：

spark.sql.adaptive.enabled=truespark.sql.adaptive.coalescePartitions.enabled=truespark.sql.adaptive.skewedJoin.enabled=true

实测表明，在复杂 ETL 流程中，启用 AQE 可减少 20%~40% 的执行时间，尤其适用于数据倾斜严重的场景。

二、内存调优：防止 OOM，提升 Shuffle 效率

Spark 的内存分为三部分：执行内存（Execution Memory）、存储内存（Storage Memory） 和 用户内存（User Memory）。默认情况下，执行与存储内存各占 60%，但这一比例在不同任务类型中需动态调整。

✅ 2.1 内存分配模型详解

💡 注意：Execution 和 Storage 内存共享同一块区域（spark.memory.fraction），总占比默认为 0.6，即 60% 的堆内存。

✅ 2.2 调优策略一：根据任务类型调整内存比例

• Shuffle 密集型任务（如多表 Join、GroupBy）：➤ 增加 Execution 内存，减少 Storage 内存

  spark.memory.fraction=0.7spark.memory.storageFraction=0.3

• 缓存密集型任务（如频繁复用的中间表、实时可视化数据集）：➤ 增加 Storage 内存

  spark.memory.fraction=0.6spark.memory.storageFraction=0.5

✅ 2.3 调优策略二：避免 Shuffle 磁盘溢出（Spill）

Shuffle 过程中，若 Execution 内存不足，Spark 会将中间数据写入磁盘，性能下降 5~10 倍。

关键指标监控：

• 查看 Spark UI → Stage 页面 → “Shuffle Read/Write” 中的 “Spilled” 值
• 若 Spilled > 10%，说明内存不足

解决方案：

1. 增加 Executor 内存

   spark.executor.memory=16g

2. 提升单任务内存上限

   spark.executor.memoryOverhead=4g

3. 优化 Shuffle 管理器

   spark.shuffle.manager=sortspark.sql.adaptive.shuffle.targetPostShuffleInputSize=64MB

✅ 推荐：Executor 内存 ≥ 8GB，且 spark.executor.memoryOverhead 至少为 executor.memory 的 10%~15%。

✅ 2.4 GC 优化：减少因垃圾回收导致的卡顿

Spark 任务常因频繁 GC 导致 Task 延迟。建议使用 G1GC（Garbage-First）：

spark.executor.extraJavaOptions=-XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:G1HeapRegionSize=32mspark.driver.extraJavaOptions=-XX:+UseG1GC -XX:MaxGCPauseMillis=200

同时，避免在 UDF 中创建大量临时对象，如频繁使用 List、Map，改用 Array 或复用对象。

三、实战案例：从 4 小时到 45 分钟的优化之旅

某制造企业构建数字孪生系统，每日需处理 2TB 的传感器时序数据，原始 Spark 任务耗时 4 小时以上，频繁出现 Executor 失败。

优化前配置：

• spark.executor.memory=8g
• spark.default.parallelism=80
• 未启用 AQE
• 未设置 memoryOverhead

优化后配置：

spark.executor.memory=16gspark.executor.memoryOverhead=3gspark.executor.cores=4spark.executor.instances=20spark.default.parallelism=160spark.sql.adaptive.enabled=truespark.sql.adaptive.coalescePartitions.enabled=truespark.memory.fraction=0.7spark.memory.storageFraction=0.3spark.shuffle.manager=sortspark.executor.extraJavaOptions=-XX:+UseG1GC -XX:MaxGCPauseMillis=200

结果：

• 执行时间从 4 小时 → 45 分钟（提升 84%）
• Shuffle Spill 从 120GB → 8GB
• Executor 失败率从 15% → 0%

📊 成功关键：并行度匹配核心数 + 内存分配倾向 Shuffle + 启用 AQE

四、监控与诊断：用 Spark UI 精准定位瓶颈

优化不是盲猜，而是数据驱动。务必掌握以下 Spark UI 关键页面：

建议每日巡检关键任务的执行报告，建立性能基线。若某任务执行时间突然增加 20% 以上，立即检查是否因数据量突增或配置漂移。

五、通用调优清单（生产环境速查表）

六、结语：优化是持续的过程，不是一次性任务

Spark 参数优化不是“设置一次，终身受益”的静态操作。随着数据规模增长、业务逻辑复杂化、集群资源变更，原有的配置可能迅速失效。建议：

• 每季度进行一次性能审计
• 建立任务基线模板（Template），按业务类型预设参数
• 使用自动化工具（如 Prometheus + Grafana）监控关键指标

真正的数据中台，不是工具堆砌，而是精细调优后的高效引擎。

如果你正在为 Spark 任务的延迟、资源浪费或频繁失败而困扰，不妨从并行度与内存调优入手，系统性重构你的计算架构。申请试用&https://www.dtstack.com/?src=bbs，获取企业级 Spark 性能诊断工具，一键生成优化建议。

申请试用&https://www.dtstack.com/?src=bbs，让专业工具帮你发现隐藏的性能黑洞。

申请试用&https://www.dtstack.com/?src=bbs，开启你的数据处理效率跃迁之旅。