
![](https://developer.qcloudimg.com/http-save/yehe-11851421/8ee7fc7c5a56e6dcb709b3347d4941df.jpg)

一次 SeaTunnel 任务提交，看起来只是一次 submitJob 请求；但在 Server 内部，它会经过 Master 判断、任务协调、JobMaster 初始化、物理执行计划构建、Pipeline 资源申请、TaskGroup 部署等多个阶段。

这篇文章基于我整理的 submitJob 时序，先聚焦一条主线：任务从提交请求进入 SeaTunnel Server，到最终调用 `TaskExecutionService.deployTask()` 部署 TaskGroup，中间都经过了什么。

本文暂不展开 `TaskExecutionService` 内部的线程模型、Task 运行细节和数据流转，重点放在任务提交与调度部署链路上。

## 核心角色

在进入流程之前，先看 submitJob 主链路里几个关键对象分别负责什么。

![](https://developer.qcloudimg.com/http-save/yehe-11851421/ccc044bb8b9c1c78a51f55e802d058cd.jpg)

## 总体流程

先用一张简化流程图看全局链路。

![](https://developer.qcloudimg.com/http-save/yehe-11851421/d31f571a7196c956f82ec867daa8dd70.jpg)

这条链路可以压缩成一句话：

```
SubmitJobServlet
  -> JobInfoService
  -> MasterNode / CoordinatorService
  -> JobMaster
  -> PhysicalPlan
  -> SubPlan
  -> PhysicalVertex
  -> TaskExecutionService
```

下面按阶段拆开看。

## 第一阶段：请求进入 JobInfoService

任务提交入口首先进入 `SubmitJobServlet`，随后交给 `JobInfoService` 处理。

这里的关键点不是马上启动任务，而是先判断：**当前接收请求的节点是不是 Master**。

![](https://developer.qcloudimg.com/http-save/yehe-11851421/243a01ce3152a53db5a12e1b9c8ee0ba.jpg)

如果当前节点就是 Master，`JobInfoService` 可以继续本地提交；如果当前节点是 Worker，则需要通过 `MasterNode.submitJob()` 转发给 Master。

这个设计保证了任务提交最终由 Master 统一协调，避免多个节点各自独立创建 Job 调度上下文。

## 第二阶段：CoordinatorService 接管任务

请求进入 Master 后，会继续调用 `CoordinatorService.submitJob()`。

`CoordinatorService` 在这里主要做两件事：

1. 判断这个 Job 是否已经存在或正在运行。
2. 如果是新任务，则创建并初始化对应的 `JobMaster`。

如果任务已经运行，SeaTunnel 不需要重复创建调度上下文，可以直接返回提交成功。如果是一个新任务，就会进入 `JobMaster` 初始化流程。

也就是说，`submitJob` 到这里已经从“接口请求处理”进入了“调度系统处理”。

## 第三阶段：JobMaster 初始化

`JobMaster` 可以理解为一个 Job 的运行控制中心。

创建 `JobMaster` 后，会完成一些运行前准备工作，例如：

* 构建任务运行所需的 classloader。
* 初始化 checkpoint 相关配置。
* 准备从逻辑 DAG 构建物理执行计划所需的上下文。

这一阶段还没有真正部署 Task，它更像是在为后续调度准备运行环境。

## 第四阶段：从逻辑 DAG 到 PhysicalPlan

JobMaster 初始化后，会基于逻辑 DAG 构建 `PhysicalPlan`。

![](https://developer.qcloudimg.com/http-save/yehe-11851421/b925df87e59f6b969f9c3a619b8716e4.jpg)

这里有一个重要概念：**SeaTunnel 不是一次性把任务全部启动，而是通过状态机逐步推进**。

在 Job 级别，核心状态推进可以简化理解为：

```
CREATED -> SCHEDULED -> startSubPlanStateProcess
```

`PhysicalPlan` 负责 Job 级别状态流转，而真正的 Pipeline 调度会继续下沉到 `SubPlan`。

## 第五阶段：SubPlan 申请资源并进入部署

到了 `SubPla`n 这一层，SeaTunnel 关注的粒度已经从整个 Job 下沉到 Pipeline。

`SubPlan.stateProcess()` 会根据当前 Pipeline 状态执行不同逻辑：

![](https://developer.qcloudimg.com/http-save/yehe-11851421/826b903db0ced610690d223a5ecf2256.jpg)

这一层的重点是：

* `CREATED` 状态下，Pipeline 会先推进到 `SCHEDULED`。
* `SCHEDULED` 状态下，开始通过 `ResourceUtils.applyResourceForPipeline()` 申请资源。
* 资源申请成功后，Pipeline 进入 `DEPLOYING`。
* 如果资源申请失败，则进入 `makePipelineFailing(e)`。

因此，Pipeline 不是被立即部署的；它必须先具备运行资源。

## 第六阶段：PhysicalVertex 部署 TaskGroup

当 Pipeline 进入 `DEPLOYING` 后，`SubPlan` 会开始启动内部的 `PhysicalVertex`。

`PhysicalVertex` 会先把 Task 状态更新为 DEPLOYING，然后根据分配到的 slotProfile 执行部署。

部署时有一个关键分支：目标 Worker 是本地还是远端。

![](https://developer.qcloudimg.com/http-save/yehe-11851421/c3ebcedc110984559e8fc566e7866787.jpg)

如果目标 Worker 是远端节点，则需要通过 `DeployTaskOperation` 把部署请求发送过去，最终仍然会在目标 Worker 上进入 `TaskExecutionService.deployTask(taskGroupInfo)`。

部署成功后，`PhysicalVertex` 会把 Task 状态更新为 RUNNING；如果失败，则进入 `makeTaskGroupFailing()`。

当 Pipeline 内部的 TaskGroup 部署完成并进入运行态后，SubPlan 也会推进到 RUNNING。

## 失败、取消与恢复分支

除了正常提交和部署，`SubPlan` 状态机里还需要处理失败、取消和恢复。

可以简化成下面这张图：

![](https://developer.qcloudimg.com/http-save/yehe-11851421/480c3ec3b38f5a8137349281d47c3b56.jpg)

这也是为什么前面的状态机设计很重要：

* 正常路径可以推进部署和运行。
* 失败路径可以进入 failing / failed。
* 取消路径可以进入 canceling / canceled。
* 如果满足恢复条件，还可以释放资源后重新申请并恢复 Pipeline。

换句话说，状态机不是为了让流程复杂，而是为了让任务生命周期可控。

## 完整时序图

最后，把主流程用时序图串起来，方便对照整体调用顺序。

![](https://developer.qcloudimg.com/http-save/yehe-11851421/4b2c9713ebf46180b46581d738af9914.jpg)

## 总结

SeaTunnel 提交任务后的核心逻辑，并不是“收到请求后直接启动任务”。

它大致会经过下面这条主链路：

```
SubmitJobServlet
  -> JobInfoService
  -> MasterNode / CoordinatorService
  -> JobMaster
  -> PhysicalPlan
  -> SubPlan
  -> PhysicalVertex
  -> TaskExecutionService
```

其中：

* `JobInfoService` 负责处理提交入口，并判断是否需要转发到 Master。
* `CoordinatorService` 负责接管任务协调，避免重复提交，并创建 JobMaster。
* `JobMaster` 负责初始化 Job 运行上下文。
* `PhysicalPlan` 负责 Job 级别状态推进。
* `SubPlan` 负责 Pipeline 级别的资源申请和调度。
* `PhysicalVertex` 负责 TaskGroup 部署。
* T`askExecutionService` 是最终执行 TaskGroup 部署的入口。

理解这条链路之后，再去看 SeaTunnel 的 Task 执行线程模型、数据流转和 checkpoint 机制，就会更容易把各个模块放到正确的位置上。

原文链接：https://nzw921rx.github.io/nzw921rx-blog/posts/seatunnel-submit-job-flow/



一次 SeaTunnel 任务提交，看起来只是一次 submitJob 请求；但在 Server 内部，它会经过 Master 判断、任务协调、JobMaster 初始化、物理执行计划构建、Pipeline 资源申请、TaskGroup 部署等多个阶段。

Apache SeaTunnel 提交一个任务都经过了什么？

大数据

后端

编程语言

SeaTunnel任务提交从SubmitJobServlet到TaskExecutionService的完整调度链路解析，涵盖JobInfoService请求分发、CoordinatorService任务协调、JobMaster初始化、PhysicalPlan状态机推进、SubPlan资源申请及PhysicalVertex部署TaskGroup等核心环节，揭示Master统一调度与Pipeline资源驱动的部署机制。

控制中心

代码解释

数据流

2026上云采购 | AI焕新·智启新局

datainlong

bigdata-class

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

SeaTunnel任务提交从SubmitJobServlet到TaskExecutionService的完整调度链路解析，涵盖JobInfoService请求分发、CoordinatorService任务协调、JobMaster初始化、PhysicalPlan状态机推进、SubPlan资源申请及PhysicalVert...

Apache SeaTunnel 提交一个任务都经过了什么？-腾讯云开发者社区-腾讯云

Apache SeaTunnel 提交一个任务都经过了什么？

Apache SeaTunnel 提交一个任务都经过了什么？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐