Apache Spark作业间延迟问题：4个作业总运行20.2秒但总时长超1分钟

碰到过好几次类似的场景：Spark作业本身运行时间很短，但作业衔接时卡很久，尤其是涉及HBase BulkLoad的情况。结合你的描述，咱们来拆解下问题和解决思路：

核心问题分析 #

你的作业1是通过SparkHadoopMapReduceWriter的runJob写入HFiles并批量上传到HBase，这里的关键是：HFile写入HBase的BulkLoad操作，表面上runJob完成了，但背后可能还有元数据同步、Region分配等异步/耗时操作没完成，这会导致作业2启动后，访问HBase时需要等待这些操作结束，看起来就成了作业间的延迟。

具体排查与解决步骤 #

1. 确认BulkLoad是否真正完成 #

很多时候代码里只执行了HFile的生成和提交，但没等待BulkLoad的收尾操作。比如SparkHadoopMapReduceWriter的runJob只是完成了HFile的写入，而将HFiles关联到HBase Region的LoadIncrementalHFiles操作如果没同步执行，就会留下隐患。

修改代码，显式等待BulkLoad完成：

val outputDir = new Path(HBaseUtils.getHFilesStorageLocation(resolvedTableName))
val job = Job.getInstance(hBaseConf)
job.getConfiguration.set(...)

// 执行HFile写入
SparkHadoopMapReduceWriter.write(job, ...)

// 显式执行BulkLoad并等待完成（这一步很关键！）
val hbaseConn = ConnectionFactory.createConnection(hBaseConf)
try {
  val table = hbaseConn.getTable(TableName.valueOf(resolvedTableName))
  val loader = new LoadIncrementalHFiles(hBaseConf)
  loader.doBulkLoad(outputDir, table)
} finally {
  hbaseConn.close()
}

// 再启动作业2

2. 检查Spark资源衔接配置 #

如果作业1结束后Executor被快速回收，作业2需要重新申请资源，也会导致延迟：

• 开启动态资源分配的话，调整spark.executor.idleTimeout（默认60秒），适当调大让Executor保留一段时间，供后续作业复用
• 设置spark.dynamicAllocation.minExecutors为至少等于作业需要的Executor数量，避免作业2启动时重新申请资源的等待

3. 验证HBase Region状态 #

作业1完成后，登录HBase Master UI，检查目标表的所有Region是否处于Online状态：

• 如果有Region在进行分裂、合并或者重新分配，这些操作会阻塞后续的读写请求
• 可以通过HBase命令行执行list_regions 'your_table_name'，确认所有Region状态正常

4. 临时排查：添加显式等待（仅用于定位问题） #

如果不确定是不是元数据同步的问题，可以在作业1结束后添加一段等待逻辑，比如：

// 等待HBase元数据同步（正式环境建议用API检查，不要硬编码sleep）
Thread.sleep(5000)

如果添加后整体耗时明显减少，就说明确实是HBase元数据同步的延迟导致的，再针对性优化。

总结 #

这种作业间延迟大多不是Spark本身的问题，而是HBase BulkLoad的收尾操作未同步或者资源复用配置不合理导致的。先定位延迟发生的具体阶段（作业2是Pending状态还是卡在读HBase），再对应调整代码或配置即可。

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