一、Spark on DolphinScheduler的参数传递痛点

很多用DolphinScheduler调度Spark任务的开发者，都遇到过这么个头疼的问题：明明在任务配置里填了指定的Driver内存、Executor数量，甚至连日志级别都改了，结果任务跑起来还是用默认值，要么资源不够报错，要么日志乱堆找不到关键信息，最烦的是这种问题还不好查，参数好像“凭空消失”了一样。 举个真实的小例子：上个月我帮公司的调度团队排查一个Spark SQL任务，任务配置里写了--driver-memory 8g、--executor-cores 4，结果任务跑了半天就内存溢出，查YARN的日志才发现Driver的内存居然是1g，Executor核心数是1，参数完全没生效，折腾了快半天才找到原因，就是部署模式选错了。

二、Client与Cluster模式的核心调度差异

要解决参数丢失的问题，得先搞懂Spark两种部署模式的本质区别，尤其是和DolphinScheduler对接时的差异，这俩模式的核心差异藏在“任务指挥中心”（Driver进程）的位置上，拆开讲有三个关键维度：

2.1 进程角色的分工差异

你可以把Spark任务比作一场演出：Driver就是总导演，负责指挥所有演员（Executor进程）干活，还和外界（DolphinScheduler、YARN）对接。 Client模式下：总导演（Driver）蹲在提交任务的机器上（比如DolphinScheduler的Worker节点），相当于导演就在后台守着，给导演的指令演员能直接收到，中间没有传话的人。 Cluster模式下：总导演（Driver）搬到了演出场地的后台集群（Spark集群的Worker节点），导演不在提交任务的机器，得通过YARN这个“场地方”传话，中间多了一层流转，参数丢了就容易出在这层。

2.2 参数传递的路径差异

这是参数丢失的最核心原因： Client模式的参数路径：DolphinScheduler Worker节点 → 本地启动Driver进程 → Driver把参数传给Executor，全程是点对点直达，只要参数格式对，就能100%生效，不会转错。 Cluster模式的参数路径：DolphinScheduler Worker节点 → YARN ResourceManager（集群管家） → 选中Worker节点上的Driver进程 → Driver传给Executor，相当于绕了个圈，如果中间某一步的解析规则变了，比如参数分隔符写错、DS面板没选对参数类型，参数就会被“管家”漏掉，传不到Driver里。

2.3 日志定位的差异

参数丢了还难查，很大原因是日志找不对： Client模式的日志直接存在提交任务的DolphinScheduler Worker节点上，在哪提交的，去那台机器的日志目录就能找到Driver的日志，一眼就能看到参数加载情况。 Cluster模式的日志，Driver在Worker节点上启动，所以日志存在集群的Worker节点或YARN日志服务器里，得去YARN的Application UI里找对应任务的ID，才能找到Driver的日志，没找对日志根本发现参数没生效。

三、参数丢失的具体示例&排查解决

这里用实际测试环境演示，统一技术栈：Spark 3.3.0 + DolphinScheduler 3.1.5，所有代码和配置都可以直接复现测试。

3.1 错误示例（参数丢失场景）

这个示例是DolphinScheduler里的Shell任务，用来提交Spark的Pi计算任务，部署模式选了Cluster，参数传错地方了：

# 技术栈：Spark 3.3.0 + DolphinScheduler 3.1.5
# DolphinScheduler Shell任务的脚本内容（错误写法）
/opt/spark/bin/spark-submit \
--class org.apache.spark.examples.SparkPi \
--master yarn \
--deploy-mode cluster \ # 错误：部署模式选了Cluster
--driver-memory 4g \ # 此处写的参数，因为是Cluster模式，DS不会直接传给Driver，未生效
--executor-memory 2g \
/opt/spark/examples/jars/spark-examples_2.12-3.3.0.jar 1000

这个任务提交后，查YARN的Application日志，会发现Driver内存是默认的1g，Executor内存也是默认的1g，参数完全没生效，任务因为资源不够，计算到一半就退出了。

3.2 正确示例（解决参数丢失的写法）

Cluster模式下，参数不能直接写在Shell脚本里，得在DolphinScheduler的任务配置面板里选对参数类型，步骤是：1. 任务类型选“Spark Submit”；2. 找到“Spark配置参数”输入框；3. 把参数填进去，格式是--key value，比如：

# 技术栈：Spark 3.3.0 + DolphinScheduler 3.1.5
# DolphinScheduler任务配置里的Spark参数（正确写法，部署模式选Cluster）
# 此处是在DS任务参数面板配置，不是写在脚本里，参数会传给YARN的ResourceManager
--driver-memory=4g
--executor-memory=2g
--deploy-mode=cluster

对应的Spark Submit脚本，DS会自动生成，提交后查YARN日志，Driver内存就是4g，参数生效了，任务能正常完成Pi的高精度计算。

3.3 排查小技巧

要是遇到参数丢了，按这几步快速排查：

  1. 先确认部署模式：测试用Client，生产必须用Cluster，别在生产环境用Client模式，稳定性没保障；
  2. 再看参数位置：Cluster模式下，参数绝对不能写在自定义脚本里，必须在DS的Spark配置面板中填写，DS提交Cluster任务时，不会解析脚本里的参数；
  3. 日志找对位置：Cluster模式的日志去YARN的Application UI里找，输入任务的Application ID，选择“Driver Logs”，就能看到参数是否被正确加载。

四、应用场景、优缺点及注意事项

4.1 应用场景

Client模式适合开发测试阶段：你可以在本地或测试节点提交任务，随时查看日志，修改参数方便，不用折腾集群的日志路径，调试效率高，适合快速验证Spark任务的逻辑和参数效果。 Cluster模式适合生产环境：Driver进程在集群内部，不会因为提交任务的机器宕机导致整个任务失败，生产环境对稳定性要求高，所以生产任务必须用Cluster模式，避免因网络或机器故障导致任务中断。

4.2 技术优缺点

Client模式的优点：参数传递直接，调试方便，配置简单，提交后能直接看到Driver的运行日志，适合快速验证；缺点：提交节点不能宕机，生产环境容易因为网络波动、机器故障导致任务异常，不适合长期运行的生产任务。 Cluster模式的优点：生产稳定性高，任务不会因提交节点故障中断；缺点：参数传递路径长，容易在流转时丢失，日志存储在集群内部，调试和排查难度大，需要额外配置参数的位置，对新手不够友好。

4.3 注意事项

  1. 部署模式别乱选：严格按照测试用Client、生产用Cluster的规则执行，别图省事在生产环境用Client，避免出现任务中断的故障；
  2. 参数位置要正确：Cluster模式下，参数必须在DolphinScheduler的Spark配置面板中填写，不能自定义在脚本里，DS提交Cluster任务时，只会解析面板中的参数；
  3. 版本要兼容：Spark和DolphinScheduler的版本要匹配，比如Spark 3.3.x需对应DS 3.1.x以上版本，版本太老会导致DS的Spark提交器解析参数时出错；
  4. 日志要备份：Cluster模式的任务日志要配置到HDFS等持久化路径，别存在Worker节点的本地磁盘，集群扩容或重启后日志就会丢失，不利于后续排查。

五、总结

Spark on DolphinScheduler的参数丢失问题，本质上是因为两种部署模式的调度路径不同，导致参数传递的容错空间不一样。Client模式的短路径让参数传递更稳定，适合开发调试；Cluster模式的长路径虽然保证了生产稳定性，但容易在流转时丢失参数，适合生产环境。只要记住“模式选对、参数位置放对、日志找对”这三点，就能避开大部分参数丢失的坑，以后再遇到类似问题，不用再盲目排查日志，先确认部署模式和参数位置，大概率能快速解决。在实际使用中，还要根据任务的阶段选择合适的部署模式，平衡调试效率和生产稳定性，才能让Spark on DolphinScheduler的任务调度更顺畅。