Spark-Submit等待状态(TaskSchedulerImpl:初始作业未接受)排查求助

从你提供的集群配置和问题描述来看，已经排除了网络连通性和Worker状态的问题，那我们可以从以下几个核心方向深入排查：

1. 优先检查Worker资源与Executor请求的匹配性 #

这很可能是导致作业卡住的关键原因：

• 你的Worker节点是m5.2xlarge（30GB内存），但从Worker进程的ps aux输出看，Worker JVM的堆内存仅设置了-Xmx1g，而你提交作业时请求的--executor-memory 2G已经超过了Worker的可用内存上限。
• Spark Worker默认会使用机器的大部分内存，但如果没有在spark-env.sh中配置SPARK_WORKER_MEMORY，同时启动Worker时手动指定了-Xmx1g，Worker能分配给Executor的内存会严重不足，导致Master无法调度任务到Worker。

解决步骤：

• 在Worker节点的spark-env.sh中添加：

  export SPARK_WORKER_MEMORY=28G  # 预留2GB给系统和Worker进程本身
  

• 重启Worker进程，然后调整提交命令中的Executor参数，比如：

  --executor-memory 4G --executor-cores 4
  

  确保单个Executor的内存请求不超过Worker可用内存的合理范围，同时充分利用Worker的48核资源。

2. 查看Master和Worker的详细日志 #

Spark Web UI的信息比较有限，需要查看节点本地的日志文件来获取更细节的错误提示：

• Master节点日志路径：$SPARK_HOME/logs/spark-<用户名>-org.apache.spark.deploy.master.Master-*.out
• Worker节点日志路径：$SPARK_HOME/logs/spark-<用户名>-org.apache.spark.deploy.worker.Worker-*.out
• 重点查找包含resource、allocate、reject等关键词的日志行，通常会明确提示资源不足或调度失败的原因。

3. 验证S3相关配置的完整性 #

虽然作业还没到执行阶段，但如果S3的认证或配置有问题，也可能导致任务初始化失败：

• 你已经配置了spark.hadoop.fs.s3a.impl，但如果没有使用IAM角色，还需要在spark-defaults.conf中添加：

  spark.hadoop.fs.s3a.access.key=你的AWS访问密钥
  spark.hadoop.fs.s3a.secret.key=你的AWS秘密密钥
  

• 如果使用IAM角色，确保Worker节点的实例角色拥有访问目标S3桶的权限（s3:GetObject、s3:PutObject等）。

4. 检查Spark版本与依赖的兼容性 #

你使用的Spark 2.2.1搭配hadoop-aws-2.7.3和aws-java-sdk-1.7.4是兼容的（Spark 2.2.x对应Hadoop 2.7.x生态），但可以确认提交命令中的依赖jar包是否重复或缺失：

• 提交命令中列出的jar包都是Spark自带的，理论上不需要手动指定（Spark会自动加载依赖），可以尝试去掉--jars参数，看是否能正常提交。

5. 确认动态资源分配配置（如果启用） #

如果你的集群开启了动态资源分配（spark.dynamicAllocation.enabled=true），需要确保相关配置正确：

• 检查spark-defaults.conf中是否配置了spark.shuffle.service.enabled=true（动态分配的前提），并且Worker节点上的Shuffle服务已经启动。

按照以上步骤逐一排查，应该能定位到作业等待的原因。

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