我之前在批量提交大规模Flink SQL作业时碰到过几乎一模一样的问题，结合你描述的症状，核心问题其实是JobManager在处理大量作业初始化时的资源过载，咱们一步步来拆解解决：

问题根因分析 #

本地独立运行时能正常执行，但Yarn集群里不行，本质差异在于：

• 本地环境资源是独占的，初期CPU高但能扛过ExecutionGraph的构建阶段；
• 而Yarn集群中的JobManager资源通常是受限的，一次性提交100条SQL会瞬间把JM的CPU、内存打满，导致它无法响应客户端的心跳请求，甚至连作业元数据都还没完成持久化就僵住了——这就是日志里出现job with ID xxx not found in JobManager的原因，不是作业不存在，是JM还没来得及把作业信息加载完成就卡住了。

具体解决方案 #

1. 拆分批量提交，避免一次性压垮JobManager #

不要一次性把100条SQL全部扔给JM，改成分批提交，给JM足够的处理间隙。比如每10-20条为一批，每批提交完成后等待30-60秒再提交下一批。你可以用简单的脚本实现这个逻辑：

# 示例Shell脚本：按目录下的SQL文件分批提交
sql_dir="./your-sql-files"
batch_size=10
current_count=0

for sql_file in "$sql_dir"/*.sql; do
    echo "Submitting $sql_file..."
    flink run -sql "$sql_file" &
    current_count=$((current_count + 1))
    
    # 达到批量数时等待当前批次完成，再休眠一段时间
    if [ $current_count -eq $batch_size ]; then
        wait
        current_count=0
        echo "Batch completed, sleeping 60s..."
        sleep 60
    fi
done
# 等待最后一批作业完成
wait

2. 调大JobManager的资源配置 #

默认的JM资源通常不足以支撑大规模作业的初始化，提交作业时显式指定JM的内存和CPU核数：

# 示例：指定JM内存为6G，CPU核数为3，根据集群实际情况调整
flink run -yjm 6144 -yjm-cores 3 -sql your-sql-file.sql

同时在flink-conf.yaml里优化JM的核心参数：

• 调大RPC超时时间：jobmanager.rpc.timeout: 900000（改成15分钟，给JM足够的初始化时间）
• 优化JM的GC配置：添加jobmanager.jvm.args: -XX:+UseG1GC -XX:MaxGCPauseMillis=200，减少GC停顿时间

3. 优化Flink SQL的执行计划复杂度 #

100条SQL可能存在大量重复逻辑，先做SQL层面的优化，减轻JM构建ExecutionGraph的压力：

• 合并相同数据源的查询：比如多个SQL都读取同一个Kafka Topic，可以先做一次统一的清洗/聚合，再分发给下游查询，避免重复构建数据源的执行计划
• 开启Flink SQL的优化开关：

  SET table.optimizer.join-reorder-enabled = true; -- 自动优化JOIN顺序
  SET table.optimizer.distinct-agg.split.enabled = true; -- 拆分DISTINCT聚合，降低计算复杂度
  

4. 排查JobManager的GC情况 #

JM卡住大概率和Full GC有关，开启JM的GC日志：
在flink-conf.yaml中添加：

jobmanager.jvm.args: -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:/path/to/gc-jm.log

提交作业后查看GC日志，如果频繁出现Full GC，说明当前JM内存不足以支撑，需要进一步调大堆内存。

5. 检查Yarn集群的资源调度 #

有时候JM完成了作业初始化，但Yarn集群没有足够的资源分配TaskManager，也会导致客户端超时。可以通过Yarn的Web UI查看：

• 作业所在队列的资源剩余情况
• 是否有其他大作业抢占了资源
  如果是资源不足，可以调整作业的队列优先级，或者联系集群管理员扩容队列资源。

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