重跑保护：并发与状态检查
重跑最大的风险不是跑得慢，而是与仍在运行的任务并发写同一个分区。这类并发通常不报错，但产出可能是半新半旧的数据，属于隐性数据事故。所以重跑前必须做状态检查与互斥：确认任务状态、目标分区是否被占用，必要时走调度平台的串行队列或分区锁，并记录重跑原因与范围。
基本信息
| 前置检查 | 任务状态与目标分区占用 |
|---|---|
| 并发控制 | 同一分区互斥 |
| 实现手段 | 调度串行队列、分区锁 |
| 留痕 | 重跑原因、发起人与范围 |
| 禁止 | 绕过调度手工触发生产写入 |
典型使用场景
- 失败任务重跑：先确认上游已就绪、同一分区没有并发任务
- 补数回刷：按分区加锁，避免与例行调度撞车
- 手工修数：走平台重跑入口，而不是在客户端直接执行 SQL
- 长任务并行：确认下游依赖不会在任务尚未结束时被触发
- 留痕记录：把重跑原因与范围写进任务备注，事后可追溯
重跑前状态探查
重跑前状态探查
-- 确认目标分区状态与位置
SHOW PARTITIONS dws_trade_store_day PARTITION (dt = '2026-10-12');
-- 查看分区目录的文件修改时间，判断是否有任务正在写入
SHOW TABLE EXTENDED LIKE 'dws_trade_store_day' PARTITION (dt = '2026-10-12');
-- 平台侧：给同一分区的任务配置互斥（串行队列），从机制上避免并发写
-- 重跑入口固定为调度平台，不直接在客户端执行 INSERT OVERWRITE重跑检查清单
| 检查项 | 目的 | 缺失后果 |
|---|---|---|
| 上游就绪 | 保证输入完整 | 重跑结果依旧错误 |
| 任务状态 | 避免与在跑任务并发 | 产出半新半旧数据 |
| 分区锁 | 同分区互斥 | 并发覆盖导致数据错乱 |
| 重跑记录 | 事后追溯 | 不知谁改过、为何改 |
两个任务并发写同一分区通常不报错，但结果不确定：可能是最后提交者生效，也可能文件互相覆盖，属于最难排查的一类数据事故。
重跑要走平台入口而不是手工执行 SQL：平台会处理依赖、锁与日志，手工执行会绕过全部保护，出事时连执行记录都查不到。