依赖等待（Sensor）作业

场景　两个工作流各自有自己的调度周期,但下游依赖上游的产出表——不想把两个工作流的调度时刻硬绑死,而是让下游"等上游表真正就绪了再往下走"。

能干什么

你想做的事	配置成 Sensor 长这样(示意)
等一张表被建出来	就绪条件选「表存在即就绪」
等一张表真正写入过数据	就绪条件选「需有数据快照」(更严格)
控制等多久、多久查一次	探测策略:每 N 秒探测一次,超时 M 秒判失败

亮点

• 轮询的是目标表本身,不是上游作业实例状态——直接查 Iceberg catalog 元数据(HMS/Iceberg 表 snapshot),不起 Spark、不依赖上游作业是否属于同一空间/同一工作流。
• 两级就绪条件——「表存在即就绪」只要求表被正式建过;「需有数据快照」进一步要求 currentSnapshot 非空,即表里已经真正写入过数据,不是空表。
• 跨工作流依赖的标准姿势——下游工作流用一个 Sensor 节点起手,等的是"表就绪"这个事实,不用管上游工作流叫什么、什么时候跑、跑没跑成功,天然解耦两个独立调度的工作流。
• 超时是明确失败,不会无限等——探测间隔和超时都可配置,超时后直接判失败(不是挂起),可以配失败重试或走告警,不会占着资源傻等。

完整操作示例:两次真实运行,一次就绪一次超时

新建「依赖等待」作业 sensor_wait_orders_demo,探测 catalog 选 iceberg_lake,就绪条件选「需有数据快照」。

第一次:指向一张已有数据的真实表(前面 Flink SQL demo 写入的 site_demo_ws10.flink_datagen_sensor),每 5s 探测一次、超时 30s。运行后第 1 次探测就命中,直接成功:

第二次:把目标表改成一张不存在的表(site_demo_ws10.table_not_ready_yet),其余配置不变。运行后每 5s 探测一次、连续 6 次都发现表不存在,31s 后触发超时,状态判为失败,平台明确提示"等待超时(30s):… 未就绪":

想了解产出表本身怎么来的,看Spark SQL 作业和Flink SQL 作业;想了解失败后怎么排查,看AI 智能诊断。

看全部作业类型 →