Apache Spark Driver与Executor配置术语解析及常见问题答疑

核心配置项基础定义 #

• spark.driver.cores：仅集群部署模式下生效，指定Driver进程占用的CPU核心数
• spark.driver.memory：为Driver进程分配的JVM堆内存容量
• spark.executor.cores：单个Executor进程可使用的CPU核心数
• spark.executor.memory：为单个Executor进程分配的JVM堆内存容量
• spark.task.cpus：单个计算任务执行时分配的CPU核心数

参考测试场景：3台物理机C1、C2、C3，单台硬件配置为4核Intel i5处理器、16GB内存、1TB本地存储，基于YARN搭建Spark集群，C1为Master节点，C2、C3为Worker/Executor节点，测试作业为读取云存储上1GB CSV文件，最终在Driver控制台打印文件首行。

常见问题解答 #

1. 核心资源配置项对计算流程的实际影响 #

配置的本质是给Spark运行时的各个进程划资源边界，直接决定作业的并行度、稳定性和运行效率，结合测试场景具体说明：

• Driver侧配置影响
  • spark.driver.cores：Driver负责作业DAG切分、任务调度、元数据存储、计算结果收集，这个值决定Driver本身的处理吞吐量。比如测试场景要拉取CSV首行回传打印，如果只配1核，任务分发、结果拉取的调度延迟会更高；配2核就能明显提升调度效率。注意client模式下该配置不生效，Driver直接占用提交作业的客户端节点的CPU资源。
  • spark.driver.memory：决定Driver能承载的结果数据量，配太小会触发OOM导致作业直接失败。测试场景只需要打印首行，配1GB足够；如果要把全量1GB CSV拉取到Driver做本地计算，至少要配2GB以上预留JVM开销冗余。
• Executor侧配置影响
  • spark.executor.cores：决定单个Executor的并行任务承载能力，单Executor可同时运行的task数 = spark.executor.cores / spark.task.cpus。注意不能把节点核数全部分给Executor，要留1-2核给操作系统、YARN NodeManager等系统进程，比如测试场景的Worker节点是4核，单节点给Executor分3核是比较合理的配置。如果spark.task.cpus设为1，单Executor就能同时跑3个task。
  • spark.executor.memory：决定Executor能缓存的计算数据量、GC频率，配太小会频繁GC甚至OOM，配太大会导致GC停顿时间过长、资源浪费。测试场景处理1GB CSV，单Executor配4GB内存完全足够；如果是TB级数据处理场景，单Executor配8-16GB内存的综合性价比最高。
    举个直观的效果对比：如果给C2、C3各启动1个Executor，每个Executor配3核、4GB内存，spark.task.cpus=1，整个集群并行度是6，1GB CSV默认按128MB切分约8个分区，两轮就能跑完所有计算任务；如果把spark.executor.cores降到1，单Executor同时只能跑1个task，8个任务需要跑4轮，总耗时会提升2-3倍。

2. 配置中提到的与CPU绑定的「进程」具体指什么 #

不是笼统的“Spark程序进程”，Spark运行时是一组独立的JVM进程集合，都是操作系统级别的进程，有独立的PID、独立的内存空间：

• Driver是独立JVM进程：集群模式下运行在YARN选出来的节点上，client模式下运行在提交作业的客户端节点，在节点上执行jps命令能看到对应进程（YARN集群模式下进程名为ApplicationMaster）。
• 每个Executor是独立JVM进程：运行在Worker节点上，和Driver通过RPC网络通信，不共享内存，jps命令看到的CoarseGrainedExecutorBackend进程就是Executor。
  这些进程都是YARN在作业提交后按需拉起的，作业运行结束就会被自动回收，不是常驻系统进程。你写的Spark业务代码会被序列化后分发到Driver和各个Executor的JVM中执行，本身不对应单独的运行进程。

3. Spark中的「task（任务）」是不是Spark派生的子进程 #

不是。Task是Executor进程内部的工作线程，运行在Executor的JVM进程内，不会单独创建操作系统级别的子进程。
每个Task对应一个数据分区的计算逻辑，Executor维护线程池来调度这些Task并行执行，这也是Spark调度开销小、启动速度快的核心原因——不需要每次跑任务都拉起新进程，直接复用现有JVM的线程资源即可。在Executor运行时打印线程栈，就能看到大量命名为Executor task launch worker for task的工作线程，这些线程没有独立的进程ID。

4. 云计算场景的vCPU是否对应单个CPU核心 #

没有严格的一一对应关系。vCPU是云厂商通过虚拟化技术抽象出来的计算单元，绝大多数公有云默认开启CPU超线程，1个物理CPU核心会被虚拟成2个vCPU，此时1个vCPU对应1个硬件超线程，不是完整的物理核心。
少数专属云、裸金属实例会把vCPU和物理核一一绑定，不做超线程，但这种场景占比很低。实际配置Spark的时候不需要做额外换算，直接按云实例标注的vCPU总数规划资源即可，留1-2个vCPU给系统和其他服务，剩下的分配给Driver和Executor就可以正常运行。 #

内容的提问来源于stack exchange，提问作者gopi_i