实时数仓开发插件拆解第五篇 | 从配置到启动,实时任务最后四阶段详解

目录

• • 调试通过以后，任务还停在上线门外^[2]
• • 配置阶段先决定按什么条件运行^[3]
• • 跳过 SLA 也是一项决定^[4]
• • 提交成功只说明平台受理了请求^[5]
• • 发布以前还要过一道校验^[6]
• • 发布成功以后，任务仍未开始消费^[7]
• • 启动改变的是线上状态^[8]
• • 启动完成要看运行态，不看按钮颜色^[9]
• • 最后四段为什么必须分开^[10]

调试通过以后，任务已经能解释当前样本下的结果。到了这一步，开发者手里通常只有一个待运行对象，平台上还没有一条开始消费流量的运行实例。后面四段挨得很近。实际处理的是四种不同状态。

配置决定任务按什么资源、参数和备份关系运行。提交把对象交给平台。发布确定这次待上线的是哪个版本。启动才会让实例进入运行状态。任何一段把“操作成功”当成下一段已经完成，后面的判断都会失准。

调试通过以后，任务还停在上线门外

调试阶段确认了 SQL、来源、输出和当前数据方案。它没有决定任务上线时使用哪个集群，也没有证明提交后的对象已经通过发布校验。

实时任务常把开发版、发布版和运行实例放在同一个平台上。界面上出现任务名，可能只是开发态文件。平台显示提交完成，可能只代表请求已经受理。发布成功后，运行实例也可能还没启动。反过来，正在运行的旧实例还会让列表里一直有一条任务，新版本是否生效仍要单独看。

这些状态混在一起时，开发者很容易拿一个成功提示代替另一个动作。流水线在最后四段分别保存配置决策、提交回执、发布对象回读和启动确认。它们一层接一层，每一层都回答一个有限问题。

配置阶段先决定按什么条件运行

configure 从当前任务和目标环境出发，检查名称、集群、引擎和任务参数。配置动作不靠记忆完成，先读取平台上的原值，再展示原始值、目标值和差异。用户确认差异以后，才写入新值，写完全部逐字段回读。

集群要从实际候选中选。候选至少包含名称、资源水位和引擎版本。只凭一个顺口的集群名去填配置，写错环境时也可能收到一条成功回执。参数的作用范围也要写清，保存一份执行计划与让参数进入运行实例是两件事。

备份方式受引用关系影响。冷备只有在全部条件满足时才能采用。条件不齐时选热备，就要为每张引用元表配置主备映射。备表查不到，回到元表流程处理，不能把一张不存在的表写进映射里充数。

资源也要把验收一起算进去。本地开源验证里出现过一次很具体的情况。集群只有单 task slot，流作业占着唯一槽位，随后做批查询取证，平台停在“Pending slot request timed out”。从查询端看，任务像挂住了；Lake 表没有坏，资源只是排不上。

这类问题要在配置阶段看见。计划槽位时，同时计算流作业、批验证和后续运维的资源占用。总数够用，也可能被同一槽位卡住。要么增加槽位，要么在发布校验时按既定流程停流、腾出资源，再做批读取证。先想清楚这段资源关系，后面就不会把资源等待误判成数据故障。

跳过 SLA 也是一项决定

调试通过后，流水线会主动询问是否设置 SLA。这里得到的答复可以是一组明确指标，也可以是这次不配置。两种答复都需要落成 sla_decided。

空白不能当跳过。因为空白既没有说明谁看过 SLA，也没有说明为什么不配。任务后面出现延迟、积压或恢复时间问题时，接手者无法知道这是验收标准缺失，还是团队明确接受了当前边界。

manual 模式会保留这次决策的原话。auto 模式会在 Goal 范围内生成对应确认记录。两种模式都要让配置阶段拥有一个出口，避免任务卡在“看过页面但没有决定”的状态里。

参数写完以后，当前阶段仍然要在平台逐项回读。任务参数可能分层保存，逻辑配置和实际运行配置也可能不是同一份。显示页面返回了修改后的值，仍要重新查询，确认目标对象、字段和作用域都对上。

提交成功只说明平台受理了请求

submit 发起任务提交后，需要按配置中的轮询节奏等平台进入终态。提交回执中的对象、版本、受理状态和追踪编号都要落证据，门控 submit_ok 再指向这份独立文件。

提交成功没有包含发布结果。平台可能已经接收了请求，发布前校验还在执行；也可能需要人工处理一项确认。提交接口直接返回成功，只能支持“已提交”或“已受理”，不能支持“可以上线”。

发布前校验有自己的状态流转。执行中继续轮询，校验失败就回到任务里修正并重新提交，校验通过才展示待发布对象、版本和影响面。遇到待人工确认时，要原样返回平台的确认链接并停下。人完成确认以后，重新查询同一次校验的结果，不能因为页面没及时跳转而从头再提交一遍。

实时任务重复提交的代价不小。平台可能留下两个请求、两个版本或两条后续动作，超时之后还会让排查者分不清哪一条有效。只提交一次，保存受理回执和追踪编号。结果不明时先查平台原状态，再决定下一步。

发布以前还要过一道校验

发布阶段接收的是已经通过校验的待发布对象。平台里的顶层版本通常表示当前运行态，待发布内容会放在另一层。拿顶层版本做判断，很容易把“正在跑的旧任务”误当成“这次准备发布的新版本”。

校验通过以后，先把待发布对象、目标版本、影响面和平台链接展示出来。manual 模式需要这次发布动作的当次确认。auto 模式按 Goal 已授权范围执行，同时建立高风险执行记录。两种模式都要保存动作、对象、版本和追踪信息。

发布回执必须带对象回读。只写一个“status=success”不够，因为这份回执无法说明发布到了哪个对象，也无法说明目标版本是否在平台上可读。publish_ok 要绑定带 object_readback 的证据，发布动作结束以后再把追踪编号写入执行记录。

发布完成说明待上线对象已经固定，不说明实例开始消费。此时最稳妥的描述是对象与版本已经就位，运行状态仍要等启动后的回读。把发布成功写成“上线完成”，后面的恢复点、版本生效和实例状态就全被跳过了。

发布成功以后，任务仍未开始消费

发布回读完成，只说明对象已经就位。实例还没有进入消费状态。

启动改变的是线上状态

启动属于生命周期动作，会改变线上状态。启动前的检查要展示六项内容，对象和环境、动作和版本、恢复点或重置时间、SQL 与执行计划影响、预计停顿、风险与回退边界。缺一项，就不能只问一句“要不要继续”。

执行器还要先确认操作、配对进度和状态核验所需的工具都能用。对象要精确到文件级编号、实例和任务，版本与 ID 一律按字符串保存。时区要随恢复点一起确认，不能等平台报时间格式错误时再倒推。

恢复点只能来自用户确认。首次启动没有检查点时，通常要走重启式启动，并由用户给出恢复位置。值的时间制有歧义时，在部署前问清。系统不能把当前时间自动填进去，因为“现在”只是操作发生的时刻，不能证明用户愿意从这里开始消费。

迁移场景还有两项独立条件。原任务已停止要有声明和状态回读，恢复点要有明确值，启动动作本身还要有当次确认。三项条件各管一件事，任何一项都不能被另一项覆盖。

start 的门控是它们共同的出口。启动成功之后，再看拓扑、运行状态、实际版本、SQL、执行计划和参数。热更新或多节点任务还有各自的回读要求，不能只凭一个总状态判断全部节点已经生效。

启动完成要看运行态，不看按钮颜色

操作结果需要一套固定状态词。未提交、已受理、进行中、失败、仅保存、已部署待验证和已验证，各自说的是不同进度。平台返回受理成功时，最多记到“已受理”。按钮变绿或流程节点变成完成，也不能替代运行态回读。

启动或发布超时以后，先保存原追踪编号，查询平台进度、运行态和变更记录。不要编一个追踪编号，也不要因为当前会话没收到返回就自动重发。两个请求同时进入平台以后，任务可能被重复部署，排查时也很难区分哪一次产生了当前状态。

验收也要回到对象本身。启动任务要看目标实例确实在运行，实际版本等于这次提交的版本，SQL、执行计划和参数与配置记录一致。涉及并发或算子结构变化时，回读物理结构，不能只看逻辑配置。部分节点成功时分别报告，一个节点成功不代表整组成功。

流水线的输出只承诺已经观察到的结果。没拿到平台链接就说没拿到，失败阶段如实返回。任务进入“已部署待验证”时照原样记录，下一轮再补运行态证据。这种写法不会让报告显得漂亮，却能让接手者知道下一步该查什么。

最后四段为什么必须分开

四段对应四种不同对象。配置阶段改的是运行条件，提交阶段交给平台的是请求，发布阶段固定的是待上线对象，启动阶段改变的是实例状态。

本地开源链路已经真实跑过提交、写入、结果回读和启停相关动作，单槽位排队的错误也留下了现场记录。平台 CLI 与 MCP 路径还没有完成真实生产环境验证。接入自己的平台时，先做执行器体检和一轮隔离环境联调，把回执字段、轮询状态和对象回读逐项对上，再让自动模式承担连续执行。

一条实时任务从待运行对象走到运行实例，靠的是一串可以互相核对的事实。配置有原始值与回读，提交有受理回执与追踪编号，发布有对象版本，启动有精确对象、恢复点和运行态。任何一段只留下一个绿色提示，后面接手的人都得重新猜。

项目地址 MrSuiChuan/realtime-data-pipeline^[1]许可证 Apache-2.0

引用链接

[1] MrSuiChuan/realtime-data-pipeline: https://github.com/MrSuiChuan/realtime-data-pipeline实时数仓开发插件拆解第二篇 |  状态机负责当前位置与合法转场详解

实时数仓开发插件拆解第四篇 |  实时开发四阶段及产出物详解