Spark Client与Cluster模式本质区别及生产选型指南

1. 为什么必须搞懂Client和Cluster模式——一个被低估的生产级决策点

Spark应用上线前，我见过太多团队在提交命令时随手敲下--deploy-mode client，等集群跑起来才发现Driver进程卡在开发机上，内存爆了、网络断了、日志全丢了。也见过另一些人死守cluster模式，结果调试阶段连个println都看不到，改一行代码要重新打包、上传、提交、等调度，半小时过去还没看到输出。这两种模式不是“选哪个更酷”，而是一次部署方式的选择，直接决定了你的开发效率、运维负担、资源隔离强度和故障定位成本。核心关键词：Spark Client模式、Spark Cluster模式、Driver进程位置、任务调度流程、生产环境部署策略。它解决的不是“能不能跑”的问题，而是“能不能稳、能不能调、能不能扩、能不能查”的系统性问题。适合正在搭建数据平台的工程师、负责ETL作业上线的数据开发、需要做性能压测的测试人员，以及所有不满足于“跑通就行”、追求可维护可追溯可监控的实战派。这不是理论考题，是每天都在发生的线上事故源头——某次YARN队列资源争抢，就是因为三个Client模式作业同时把Driver塞进同一台边缘节点，把那台机器的JVM堆撑到98%，连带影响了同节点上的HDFS DataNode心跳上报。

2. 模式本质：Driver进程的物理归属决定一切

2.1 Client模式——Driver长在你本地，像遥控器一样指挥全局

Client模式最直白的理解就是：Driver进程启动在你提交作业的这台机器上。无论你是从笔记本、跳板机还是CI服务器上执行spark-submit，那个承载着DAGScheduler、TaskScheduler、ShuffleManager、BlockManager的JVM进程，就实实在在地运行在你当前这台设备的内存里。它不经过资源管理器（YARN/Mesos/K8s）调度，不申请容器，不走排队流程，属于“自带干粮、说走就走”。整个工作流是这样的：你敲下命令 → 本地JVM启动Driver → Driver向YARN ResourceManager申请ApplicationMaster（AM）容器 → AM启动后，反向注册回Driver → Driver开始解析代码、构建DAG、划分Stage、生成TaskSet → 再通过AM向NodeManager申请Executor容器 → Executor启动后，向Driver反向注册 → Driver分发Task、监控状态、聚合结果。关键在于，所有调度决策、血缘追踪、失败重试逻辑，都由你本地这台机器上的Driver实时完成。这就带来一个天然优势：开发调试极其友好。你可以用IDE远程调试Driver端代码，打断点看Shuffle读写路径，用jstack抓线程快照，甚至直接在本地System.out.println()打印中间RDD分区数。但代价也很真实：本地机器成了单点瓶颈。我曾在一个金融客户现场遇到过，他们用MacBook Pro提交一个处理TB级日志的作业，Driver本身要缓存大量广播变量和累加器，加上GC频繁，本地JVM内存直接飙到16G，风扇狂转，键盘发烫，而集群其他节点空闲率超70%。更致命的是，一旦你本地网络抖动或机器休眠，Driver与AM、Executor的连接就会中断，整个Application被YARN标记为FAILED，所有已计算的Stage全部作废重来。

2.2 Cluster模式——Driver被“请进”集群，成为受管资源的一部分

Cluster模式的核心动作只有一个：Driver进程不再由你本地启动，而是由资源管理器统一调度，放进集群某个NodeManager管理的Container里运行。你提交命令后，spark-submit只是个轻量级客户端，它把jar包、配置、主类信息打包成Application Submission Context，扔给YARN ResourceManager。RM分配第一个Container给ApplicationMaster，这个AM一启动，立刻就地拉起Driver JVM——注意，这个Driver此刻已经脱离你的控制范围，它运行在集群内部某台Worker节点上，和其他Executor一样，受YARN的内存/核数配额约束、受NodeManager的健康检查监管、受ResourceManager的生命周期管理。整个流程变成：你敲命令 → spark-submit发送请求 → RM分配AM Container → AM启动并立即fork出Driver → Driver初始化、解析代码、构建DAG → Driver向RM申请Executor Container → Executor启动并注册到Driver → 后续调度与Client模式完全一致。区别只在起点：Driver从“外部遥控器”变成了“内部指挥官”。这意味着什么？第一，资源隔离彻底。Driver的内存、CPU、磁盘IO全部纳入集群统一调度，不会拖垮你的开发机，也不会因本地故障导致作业中断。第二，高可用基础具备。YARN支持AM重启，当Driver所在Container因节点宕机挂掉，RM可以自动在另一台机器上拉起新的AM+Driver，只要Checkpoint配置得当，作业可以从失败点恢复。第三，网络拓扑最优。Driver和Executor大概率在同一机架甚至同一物理机，Shuffle数据走内网，延迟低、带宽高。但硬币另一面是调试门槛陡增。你无法直接ps aux | grep Driver，不能用IDE attach，println日志默认输出到AM的日志文件里，得靠yarn logs -applicationId <id>去扒，而且日志分散在不同节点，聚合分析成本高。某次我们排查一个Shuffle fetch超时问题，光是定位Driver日志就花了40分钟——因为AM被调度到了一个平时几乎不用的冷节点，而那个节点的log目录权限还被运维误配成了700。

2.3 两种模式的底层差异不是“配置开关”，而是架构角色的根本切换

很多人以为--deploy-mode client和--deploy-mode cluster只是spark-submit的一个参数，改一下就能切换。这是巨大误解。这两个参数触发的是两套完全不同的进程启动链和生命周期管理模型。Client模式下，spark-submit脚本本身会启动一个Client类（org.apache.spark.deploy.yarn.Client），这个类负责创建YARN客户端、申请AM、等待AM注册、然后才启动真正的Driver主线程。而Cluster模式下，spark-submit只做一次RPC调用，把Application描述发给RM就退出了；后续所有事，包括AM的启动、Driver的fork、Executor的拉起，全部由YARN框架内部完成，spark-submit进程早已结束。这就解释了为什么Client模式能拿到Driver的SparkContext对象引用，而Cluster模式下你在提交脚本里根本拿不到——因为Driver根本不是你这个进程spawn出来的。更深层的影响在容错机制。Client模式的Driver崩溃，等同于整个Application崩溃，YARN只会清理掉AM和Executor，不会重建Driver；而Cluster模式下，如果启用了yarn.resourcemanager.am.max-attempts（默认2次），AM+Driver组合是可以被YARN自动重试的。另外，网络通信模型也不同：Client模式中，Driver与Executor之间是“跨公网/跨VPC”的长连接，容易受防火墙、NAT、TCP保活时间影响；Cluster模式中，Driver与Executor同属集群内网，走的是YARN分配的短生命周期Container IP，连接更稳定。我实测过，在千兆内网环境下，Cluster模式下Executor向Driver汇报心跳的平均延迟是8ms，而Client模式下，当Driver在办公网段提交，Executor在IDC集群，这个延迟飙升到217ms，直接触发了spark.network.timeout默认120s的超时阈值，导致部分Task被误判为丢失。

3. 实操细节：从命令行到配置项，每个参数都在说话

3.1 提交命令的“形似神异”——表面一样，内里乾坤

先看两个看似相同的提交命令：

# Client模式典型命令 spark-submit \ --master yarn \ --deploy-mode client \ --driver-memory 4g \ --executor-memory 8g \ --num-executors 10 \ --class com.example.WordCount \ hdfs://namenode:8020/jars/wordcount.jar \ hdfs://namenode:8020/input \ hdfs://namenode:8020/output # Cluster模式典型命令 spark-submit \ --master yarn \ --deploy-mode cluster \ --driver-memory 4g \ --executor-memory 8g \ --num-executors 10 \ --class com.example.WordCount \ hdfs://namenode:8020/jars/wordcount.jar \ hdfs://namenode:8020/input \ hdfs://namenode:8020/output

表面上只有--deploy-mode一个参数不同，但背后执行逻辑天差地别。Client模式下，--driver-memory 4g这个参数，是告诉本地JVM启动时分配4G堆内存；而Cluster模式下，这个参数是告诉YARN：请为Driver所在的AM Container分配4G内存。注意，YARN实际分配的Container内存会略大于此值，因为要预留JVM元空间、代码缓存、GC开销等，通常按1.2倍系数上浮。所以如果你设--driver-memory 4g，YARN最终申请的Container内存可能是4800MB。更重要的是，Client模式下，--driver-java-options可以直接生效，比如-XX:+UseG1GC -XX:MaxGCPauseMillis=200，这些JVM参数直接作用于你本地的Driver进程；而Cluster模式下，这些参数必须通过--conf spark.driver.extraJavaOptions="..."来传递，因为Driver是在远端Container里启动的，spark-submit本地进程无法直接干预其JVM参数。我踩过一个坑：在Client模式下用-Dlog4j.configurationFile=file:///path/to/log4j2.xml指定日志配置，一切正常；切到Cluster模式后，这个路径在远端节点根本不存在，导致Driver日志全丢，最后改成--conf spark.driver.extraJavaOptions="-Dlog4j.configurationFile=local:log4j2.xml"，并把log4j2.xml打包进jar的resources目录才解决。

3.2 驱动端配置的“隐形战场”——那些不写在文档里的关键项

Driver配置远不止内存和JVM参数。有三个常被忽略但影响巨大的配置项：

第一，spark.driver.host和spark.driver.port。Client模式下，Driver默认绑定0.0.0.0，监听随机端口，让Executor能连上来；但如果你的开发机在NAT后面（比如公司内网），Executor可能根本连不上这个地址。必须显式设置--conf spark.driver.host=your.public.ip --conf spark.driver.port=7077，并确保防火墙放行。而Cluster模式下，这两个配置完全无效——Driver的host/port由YARN动态分配并注入到Executor的环境变量里，你根本不需要、也不应该手动设置。某次我们一个作业在Client模式下总报Connection refused，排查半天发现是运维把跳板机的/etc/hosts里127.0.0.1映射到了一个错误的主机名，导致Driver绑定到了localhost而非真实IP。

第二，spark.driver.bindAddress。这是Client模式的救命稻草。当你本地有多块网卡（比如同时连着办公网和IDC专线），Driver可能随机绑定到错误网卡。必须强制指定--conf spark.driver.bindAddress=10.10.10.5（IDC网段IP），否则Executor会尝试连192.168.1.100这个办公网IP，自然失败。Cluster模式下此配置无意义，Driver绑定地址由YARN根据节点网络配置决定。

第三，spark.network.timeout和spark.rpc.askTimeout。Client模式下，由于网络链路长、不稳定，这两个超时值必须调大。我们生产环境Client模式作业统一设为--conf spark.network.timeout=600s --conf spark.rpc.askTimeout=300s；而Cluster模式下，内网环境设为120s和60s就足够，设太大反而会掩盖真实的网络故障。有个经典案例：某次IDC交换机故障，导致Client模式作业的spark.network.timeout默认120s被频繁触发，Task不断重试，集群负载飙升；而同一时间Cluster模式作业因超时值小，快速失败并告警，反而更快定位了网络问题。

3.3 资源申请的“精打细算”——为什么Executor数量在两种模式下表现不同

--num-executors这个参数，在Client和Cluster模式下的语义其实微妙不同。Client模式下，它纯粹是向YARN申请Executor的数量，Driver不占YARN资源配额；而Cluster模式下，--num-executors申请的Executor数量，是在Driver Container之外额外申请的。也就是说，整个Application占用的YARN Container总数 = 1（Driver+AM） +--num-executors。这直接影响资源规划。假设YARN队列最大内存为100G，你设--driver-memory 4g --executor-memory 8g --num-executors 10，Client模式下总内存消耗≈4 + 10×8 = 84G；Cluster模式下，总内存消耗≈4（Driver） + 10×8（Executors） = 84G，看起来一样？错！YARN为每个Container分配内存时，会向上取整到yarn.scheduler.minimum-allocation-mb（通常1024MB），所以Driver的4G实际占4096MB，10个Executor各占8192MB，总计4096 + 10×8192 = 86016MB，即84G，没问题。但如果--num-executors设为12，Client模式：4 + 12×8 = 100G；Cluster模式：4096 + 12×8192 = 102400MB = 100G，刚好卡死。但如果你再加一个Executor，Client模式超限失败，Cluster模式却可能成功——因为YARN的AM Container内存配额有时会单独计算，不严格计入队列总限额。我们线上就发生过，Client模式申请15个Executor被YARN拒绝，换成Cluster模式后，15个Executor+Driver居然跑起来了，原因是YARN把AM Container的内存算在了“系统保留资源”里。所以，资源规划时，Cluster模式要预留更多buffer，Client模式则要严防本地机器资源耗尽。

4. 场景化决策树：什么情况下必须选Client，什么情况下必须选Cluster

4.1 坚决选择Client模式的四大铁律场景

第一，交互式开发与快速验证。当你在Jupyter或Zeppelin里写Spark SQL，或者用spark-shell跑Ad-hoc查询，Client模式是唯一选择。原因很简单：Driver必须和你的REPL进程同生共死，sc.parallelize(...).count()的结果要实时返回到你的终端。如果用Cluster模式，每次执行都要提交一个Application，等AM启动、Driver初始化、执行、返回结果，光调度延迟就30秒起步，交互体验彻底崩坏。某数据科学团队曾强行在Zeppelin里配置Cluster模式，结果分析师抱怨“写完一行SQL，泡杯咖啡回来还没出结果”，最后全部切回Client。

第二，依赖本地文件系统的作业。比如你的作业需要读取本地/data/config.properties来获取数据库密码，或者用new File("/tmp/cache")做临时存储。Client模式下，Driver进程能直接访问本地文件；Cluster模式下，Driver在远端Container里，/tmp是那个节点的临时目录，/data/config.properties根本不存在。除非你把所有本地依赖打包进jar或上传到HDFS，否则必报FileNotFoundException。我们一个风控模型特征工程作业，因依赖本地Python UDF脚本，只能用Client模式，后来通过--files参数把脚本分发到所有Executor才勉强支持Cluster，但Driver端逻辑仍需Client。

第三，需要精细控制Driver JVM行为的场景。比如你用G1 GC做了深度调优，设置了-XX:G1HeapRegionSize=4M -XX:MaxGCPauseMillis=50，这些参数在Client模式下可直接生效；Cluster模式下，虽然能用extraJavaOptions传，但YARN Container的cgroup限制可能和JVM参数冲突，导致GC反而更差。某次我们一个实时流作业，Client模式下GC停顿稳定在30ms内，切Cluster后，因YARN对Container内存的硬限制（-Xmx）和G1的-XX:MaxGCPauseMillis目标冲突，GC停顿飙升到800ms，触发了Flink的背压机制。

第四，调试复杂Shuffle或序列化问题。当遇到java.io.NotSerializableException或FetchFailedException，Client模式下你能直接在IDE里debug Driver的闭包序列化过程，看哪个匿名内部类没实现Serializable；或者用jmap -histo看Driver堆里到底缓存了多少未释放的RDD。Cluster模式下，你只能靠日志猜，效率极低。我们曾为一个Broadcast变量反序列化失败的问题，Client模式下2小时定位到第三方库的静态字段，Cluster模式下折腾了3天。

4.2 必须拥抱Cluster模式的五大生死线场景

第一，生产环境正式作业上线。这是铁律。Client模式把Driver放在不可控的开发机上，违背了“基础设施即代码”和“环境一致性”原则。运维无法监控Driver JVM指标，无法做资源配额管理，无法做滚动升级，更无法保证高可用。某电商大促期间，一个关键订单统计作业用Client模式部署在DBA的笔记本上，结果DBA中午合盖睡觉，Driver进程被系统挂起，作业停滞2小时，损失数百万GMV。从此他们立下规矩：所有生产作业，--deploy-mode cluster写死在CI脚本里，不通过审核不许合并。

第二，Driver内存需求超过本地机器承载能力。当你的作业需要--driver-memory 16g以上，而开发机只有16G内存，还要跑IDE、浏览器、微信，根本不够。Client模式下，Driver OOM是常态。Cluster模式下，你可以申请一台32G内存的专用Driver节点，或者让YARN调度到内存富裕的Worker上。我们一个图计算作业，Driver要加载全量用户关系图谱到内存，需要24G，只能Cluster。

第三，多作业并发提交的资源竞争。当一个团队几十人同时用Client模式向YARN提交作业，所有Driver都挤在几台跳板机上，这些机器的CPU、网络、文件句柄瞬间打满，导致YARN AM注册超时、Executor连接失败。Cluster模式下，Driver资源由YARN统一分配，压力分散到整个集群。我们曾监控到，Client模式高峰期，跳板机CPU持续95%，而集群平均CPU才30%；切Cluster后，跳板机CPU降到15%，集群CPU均衡到40%。

第四，需要与Kerberos认证深度集成。Client模式下，Driver的Kerberos TGT（Ticket Granting Ticket）需要在本地机器上kinit获取，并且TGT有有效期（通常10小时）。一旦过期，Driver与HDFS/HBase的连接就会认证失败。而Cluster模式下，YARN的AM可以配置yarn.nodemanager.keytab和yarn.nodemanager.principal，自动完成TGT续期，Driver进程全程无感。某金融客户因Client模式TGT过期导致每日凌晨2点定时作业批量失败，切Cluster后问题消失。

第五，要求作业日志集中化、结构化管理。Client模式下，Driver日志散落在各开发机，格式不一，无法接入ELK做统一分析。Cluster模式下，所有日志（包括Driver）都由YARN的Log Aggregation服务收集到HDFS，路径统一为/app-logs/<user>/logs/<application_id>，可直接用Spark SQL分析日志中的GC次数、Shuffle spill量、Task失败率。我们一个运维平台，就是靠解析Cluster模式下的Driver日志，构建了作业健康度评分模型。

4.3 灰度地带：那些看似模糊，实则有明确答案的中间场景

有些场景看起来模棱两可，但深入分析就有清晰答案。比如“需要访问本地MySQL数据库的ETL作业”。直觉可能觉得要用Client模式，因为Driver要连本地DB。错！正确做法是：用Cluster模式，但在spark.sql("set spark.sql.adaptive.enabled=true")之后，用spark.read.jdbc()时，把MySQL连接串里的localhost换成内网DNS名，确保Driver Container能解析；同时配置--driver-class-path /path/to/mysql-connector.jar把驱动包带上。这样既享受Cluster的稳定性，又解决连接问题。

再比如“使用Spark Streaming消费Kafka”。很多人担心Client模式下Driver挂了Streaming就停。其实Spark Streaming本身有WAL（Write Ahead Log）和Checkpoint机制，Client模式也能做到至少一次语义。但生产环境仍推荐Cluster，因为Kafka Consumer Group的offset提交、StreamingContext的Checkpoint目录（通常在HDFS）的读写，都要求Driver有稳定的网络和存储访问能力，Client模式下这些都不可靠。

还有一个经典误区：“Interactive SQL on Spark Thrift Server”。Thrift Server本身就是一个长期运行的Driver服务，它必须用Cluster模式部署在集群里，接受来自Beeline、Tableau等客户端的JDBC连接。把它跑在Client模式，等于把整个SQL服务架在开发机上，是重大架构错误。

5. 故障排查实战：从日志碎片到根因定位的完整链条

5.1 Client模式典型故障与秒级定位法

故障现象：提交作业后，spark-submit命令卡住，长时间无响应，最后报Application submission failed

这不是网络问题，而是Driver与YARN AM注册超时。Client模式下，spark-submit启动Driver后，会阻塞等待AM向Driver注册。如果AM启动慢（比如YARN队列积压），或者Driver绑定的IP/Port无法被AM访问，就会卡在这里。秒级定位法：立刻在提交机器上执行netstat -tuln | grep :7077（Driver默认端口），看端口是否LISTEN；再执行telnet <am-host> <am-port>，看能否连通AM。如果端口没起来，检查spark.driver.host是否设错；如果能连AM但卡住，大概率是spark.network.timeout太小，加--conf spark.network.timeout=600s重试。

故障现象：作业运行中，Executor频繁报Connection to *.*.*.*:7077 refused

这是Executor连不上Driver。Client模式下，Driver绑定的IP一定是开发机对外网段的IP，而不是127.0.0.1。用ifconfig确认开发机在IDC网段的IP（比如10.10.10.5），然后--conf spark.driver.host=10.10.10.5 --conf spark.driver.bindAddress=10.10.10.5强制绑定。千万别信hostname -i，它经常返回127.0.0.1。

故障现象：Driver日志里大量WARN BlockManager: Putting block rdd_1_0 failed due to exception，作业变慢

这是Driver内存不足，BlockManager无法缓存中间RDD。Client模式下，--driver-memory设小了。看jstat -gc <driver-pid>，如果OU（Old Gen Used）持续95%以上，就是内存瓶颈。解决方案不是简单加内存，而是检查代码：是否用了collect()把大数据集拉到Driver？是否broadcast了不该广播的大变量？优化代码比加内存更治本。

5.2 Cluster模式典型故障与日志穿透术

故障现象：yarn application -list能看到Application，但yarn logs -applicationId <id>返回Log aggregation has not completed or is not enabled.

这是YARN Log Aggregation没开启或延迟。检查yarn-site.xml里yarn.log-aggregation-enable是否为true，yarn.log-aggregation.retain-seconds是否足够长（建议设为2592000，30天）。如果已开启，等5-10分钟再查，因为Aggregation是异步的。紧急情况下，登录AM所在节点，找$YARN_LOG_DIR/userlogs/application_<id>/container_e<id>_01_000001/stderr，那里有Driver启动时的原始错误。

故障现象：作业一直显示ACCEPTED，迟迟不变成RUNNING

这是YARN资源不足，AM Container申请不到。用yarn queue -status <queue-name>看队列资源使用率；用yarn application -status <id>看Application的Final-State是否为UNDEFINED；最关键的是看yarn application -appStates ALL -list | grep <id>，如果State是ACCEPTED但Tracking-URL为空，说明AM根本没启动。此时去YARN ResourceManager UI，看Applications页签，找这个Application，点进去看Diagnostics，通常会写Queue 'default' is full或Requested resource <memory:4096, vCores:1> is not available。

故障现象：Driver日志里出现ERROR YarnClusterScheduler: Lost executor <id> on <host>: ...，但Executor日志显示INFO CoarseGrainedExecutorBackend: Got assigned task <task-id>

这是典型的网络分区。Driver认为Executor死了，但Executor还在干活。原因往往是spark.network.timeout设得太小，而集群网络偶尔抖动。看Driver日志里Lost executor的时间点，再去对应Executor日志里搜那个时间点前后的Registered signal handlers for和Starting executor，如果Executor日志在那个时间点后还有心跳记录，就证实是网络抖动。解决方案：调大spark.network.timeout，并启用spark.speculation（推测执行）来掩盖单点故障。

5.3 跨模式通用故障：那些你以为是模式问题，其实是配置陷阱

故障现象：两种模式下，作业都报java.lang.OutOfMemoryError: GC overhead limit exceeded

这不是模式问题，是spark.sql.adaptive.enabled和spark.sql.adaptive.coalescePartitions.enabled的锅。自适应查询执行（AQE）在Shuffle后会动态合并小分区，但如果合并逻辑有bug，可能导致Driver内存暴涨。关掉AQE：--conf spark.sql.adaptive.enabled=false，问题立解。这是Spark 3.2.x的一个已知Bug，和部署模式无关。

故障现象：Client模式能跑，Cluster模式报ClassNotFoundException: com.mysql.cj.jdbc.Driver

你以为是ClassPath问题，其实是--driver-class-path和--jars的区别。Client模式下，--jars mysql-connector-java-8.0.28.jar能把jar加到Driver ClassPath；Cluster模式下，--jars只作用于Executor，Driver ClassPath还得靠--driver-class-path。必须同时加：--jars mysql-connector-java-8.0.28.jar --driver-class-path mysql-connector-java-8.0.28.jar。

故障现象：两种模式下，spark.sql("select * from hive_table")都报Table not found

这是Hive Metastore连接问题。Client模式下，Driver读取本地hive-site.xml；Cluster模式下，Driver读取YARN节点上的hive-site.xml。检查YARN节点的$HADOOP_CONF_DIR下是否有正确的hive-site.xml，特别是hive.metastore.uris配置。用hadoop classpath确认Hive JAR包是否在ClassPath里。

6. 终极决策清单：一份可直接打印贴在显示器边上的检查表

提示：没有“永远正确”的模式，只有“当前场景下风险收益比最优”的选择。我见过最聪明的做法是：开发阶段用Client模式快速迭代，上线前用自动化脚本将--deploy-mode client替换为--deploy-mode cluster，并同步校验所有--driver-*参数是否适配集群环境。一套代码，两种模式，平滑过渡。

注意：永远不要在Client模式下设置--driver-memory超过本地机器物理内存的70%。我亲眼见过一个同事设了--driver-memory 30g，而他的Linux服务器只有32G内存，结果Driver GC把Swap区打满，整个系统卡死，SSH都连不上，最后只能物理重启。

实操心得：Cluster模式下，务必开启YARN Log Aggregation，并把yarn.log-aggregation.retain-seconds设为至少7天。我们曾靠3天前的Driver日志，定位到一个偶发的java.lang.IllegalStateException: unread block data异常，根源是Executor的JDK版本和Driver不一致，这个Bug在Client模式下根本复现不了，因为本地JDK版本固定。

我个人在实际操作中的体会是：Client和Cluster不是非此即彼的选择题，而是同一枚硬币的两面。Client模式是你的“开发加速器”，让你以最快的速度验证想法、调试逻辑；Cluster模式是你的“生产稳定器”，确保作业在无人值守的情况下，7x24小时可靠运行。真正成熟的Spark工程师，不是死守某一种模式，而是像老司机换挡一样，在开发、测试、预发、生产各个环境，根据实时的资源、安全、监控、协作需求，无缝切换部署模式。我见过最高效的团队，他们的CI/CD流水线里，spark-submit命令是模板化的，--deploy-mode参数由环境变量DEPLOY_MODE控制，开发环境自动填client，生产环境强制为cluster，中间环节还有灰度环境做双模式并行验证。这种工程化思维，比纠结“哪个模式更好”重要得多。