EMR集群晚提交的相同Spark作业执行耗时更长的原因排查

在EMR集群中提交50个相同的Spark作业（首次与末次提交间隔约3分钟），期望所有作业并行执行且耗时相近，但实际前20个作业耗时约2.5分钟，后30个作业耗时6-10分钟。

作业提交命令：

spark-submit --master yarn --deploy-mode client \ 
--num-executors=4 --executor-cores=5 --executor-memory 8g --driver-memory 8g --conf spark.dynamicAllocation.enabled=true

此前运行30个作业时，最后10个耗时超1小时，调整核心节点从m5.2xlarge改为m5.24xlarge，扩缩容规则的扩容调整量从2改为6、冷却时间从300秒改为120秒后，最后10个作业耗时降至约9分钟，但晚提交作业耗时仍更长，未实现完全并行。附作业运行时长截图（作业时长分布截图）

原因排查 #

• YARN资源调度限制：YARN队列的资源容量配置可能存在上限，导致晚提交的作业无法立即获取足够资源，只能等待集群扩容或前置作业释放资源。
• 动态分配的启动延迟：即使调整了扩容参数，从资源请求到新节点完成启动、注册并可用仍存在时间差。晚提交的作业提交时，集群还在为前一批作业扩容，资源缺口导致作业等待。
• Client模式的本地资源瓶颈：deploy-mode client下，Driver运行在提交机器上，大量Driver进程同时运行会占用提交机器的CPU、内存资源，拖慢晚启动作业的初始化速度。
• 集群资源碎片化：前20个作业占用节点部分资源后，剩余资源无法满足后续作业的Executor完整资源需求（如单个Executor需5核8G），导致后续作业需等待资源释放或新节点上线。
• ECS实例扩容限制：AWS账号下m5.24xlarge实例可能存在配额限制，或实例创建存在网络/流程延迟，导致集群扩容速度跟不上作业提交节奏。

解决思路 #

• 调整YARN队列配置：检查并修改目标队列的capacity和maximum-capacity参数，确保队列能使用集群全部可用资源，消除队列资源上限对作业并行的限制。
• 切换至Cluster部署模式：将--deploy-mode改为cluster，让Driver运行在集群节点上，避免提交机器的资源瓶颈影响作业启动效率。
• 优化动态分配参数：
  • 设置spark.dynamicAllocation.initialExecutors等于num-executors，确保作业启动时直接申请足够的Executor，减少等待时间。
  • 开启spark.shuffle.service.enabled=true，保留shuffle数据，提升Executor资源复用率，避免因Executor释放导致的重复计算。
• 预扩容集群节点：根据总资源需求提前手动扩容集群（50个作业×4 Executors×5核=1000核，m5.24xlarge单节点24核，需至少42个节点），规避动态扩容的延迟问题。
• 确认ECS实例配额：检查AWS账号中m5.24xlarge实例的配额，若不足及时提交配额申请，确保扩容时能快速创建所需实例。
• 批量提交作业：缩短作业提交间隔，或使用批量提交工具一次性提交所有作业，让YARN统一调度资源，避免分批提交导致的资源分配不均。
• 适配节点资源调整Executor配置：将executor-cores调整为6（适配m5.24xlarge的24核，单节点可运行4个Executor），减少资源碎片，提升集群资源利用率。

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