Foundry作业Profile配置与AWS Glue Worker类型的等价映射关系

基础前提 #

两类平台的Spark作业都遵循容器化资源调度逻辑，映射核心是对齐单节点vCPU、可用堆内存配比，同时预留系统、Spark非堆内存占用，不能直接按硬件标称值硬套参数。
Foundry侧可配置的核心资源参数作用：

• num_executors：作业申请的Executor实例总数，默认不包含Driver节点配额
• executor_memory：单个Executor进程分配的JVM/PySpark堆内存大小
• driver_memory：Driver进程分配的堆内存大小
• 配套隐式参数：spark.executor.cores（单Executor绑定的vCPU数）、spark.driver.cores（Driver绑定的vCPU数），是映射CPU规格的核心参数

AWS Glue G系列Worker实际可用资源 #

Glue的G系列Worker为单节点跑单Executor的部署模式，标称硬件资源会扣除OS守护进程、Spark堆外内存、元空间、IO缓存占用后，才会分配给Spark作业进程，实际可用规格如下：

• G.1X Worker
  • 标称资源：4 vCPU、16GB RAM
  • 作业可用资源：4 vCPU，单Executor堆内存10GB
• G.2X Worker
  • 标称资源：8 vCPU、32GB RAM
  • 作业可用资源：8 vCPU，单Executor堆内存20GB
    注：Glue默认会从配置的Worker总数里拿1台跑Driver，剩余节点全部作为Executor节点，Driver默认和Worker同规格。

精确映射规则 #

1. 单Executor规格对齐
   • 对齐G.1X Worker：配置executor_memory=10g，同时设置spark.executor.cores=4
   • 对齐G.2X Worker：配置executor_memory=20g，同时设置spark.executor.cores=8

   不要直接把标称的16GB/32GB全配给executor_memory，否则会因为非堆内存不足触发容器OOM被kill，稳定性表现和Glue侧不一致。

2. 节点数量对齐
   Foundry的num_executors值 = Glue配置的Worker总数 - 1，差值对应Glue占用1台Worker跑Driver的规则。如果你的Foundry作业Driver节点单独占配额不占用Executor资源池，直接按这个公式换算即可。
3. Driver规格对齐
   对齐Glue默认的Driver与Worker同规格逻辑：
   • 用G.1X规格集群时：配置driver_memory=10g，spark.driver.cores=4
   • 用G.2X规格集群时：配置driver_memory=20g，spark.driver.cores=8

配置换算示例 #

• 场景1：Glue侧作业配置为G.1X Worker，总Worker数10
  对应Foundry Profile配置：

  num_executors = 9
  executor_memory = 10g
  spark.executor.cores = 4
  driver_memory = 10g
  spark.driver.cores = 4
  

• 场景2：Glue侧作业配置为G.2X Worker，总Worker数20
  对应Foundry Profile配置：

  num_executors = 19
  executor_memory = 20g
  spark.executor.cores = 8
  driver_memory = 20g
  spark.driver.cores = 8
  

如果你的Foundry平台修改了spark.executor.cores的全局默认值，需要先把该参数调整为对应规格的vCPU数，否则CPU/内存配比和Glue侧不匹配，会出现资源浪费或算力不足的问题。

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