ETL 任务如何设计幂等和可重跑？
面试怎么回答
我会从输入、主键、写入和副作用四层设计。输入要固定业务日期与版本；明细定义稳定业务主键；整分区使用影子写入校验后覆盖，增量场景采用去重加 MERGE 或 Upsert；外部消息和接口单独使用幂等键与执行账本。重跑前还会核对上游是否变化，完成后做行数、金额和唯一性对账。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
凌晨任务失败后，值班同学点击重跑。任务成功了，但当天收入翻倍、用户数却没变。
“能够重跑”不等于“重跑结果正确”，关键是同一业务输入重复执行后，目标状态必须一致。
ETL 幂等要同时约束输入范围、业务主键、写入方式、外部副作用和运行版本。
固定本次处理边界
任务必须记录业务日期、数据版本、上游快照或增量位点。若每次重跑都读取“当前最新数据”，同一个运行日期可能得到不同输入，无法复现。
定义稳定业务主键
明细层要明确什么字段唯一标识一条业务事实。没有稳定键，MERGE 无法判断更新与新增；仅靠全行 DISTINCT 只能掩盖重复，不能处理状态变化。
选择匹配的写入策略
整分区结果可采用临时表校验后原子覆盖；增量事实可使用 MERGE、去重后 Upsert 或版本表。不要一边覆盖一边追加，更不要在校验前破坏旧分区。
控制外部副作用
发送消息、调用接口、刷新缓存等操作需要幂等键和执行账本。数据表重跑成功，不代表外部通知可以重复发送。
为什么不能只回答概念？
“误区：重跑前先删分区就一定安全”之所以常见，是因为它在理想数据和单次执行里往往说得通。但生产环境会加入数据规模、异常值、并发、版本、失败重试和下游口径，这些条件一变化，只记住术语就很容易给出错误结论。
所以我会把 固定本次处理边界、定义稳定业务主键、选择匹配的写入策略、控制外部副作用 串成一条完整链路。最终判断标准不是某个函数或配置是否出现，而是能否稳定得到可解释、可验证、可恢复的业务结果。
落地时我会检查什么？
- 输入边界：确认数据范围、时间口径、主键和异常值是否符合假设。
- 执行过程：观察分区、并行度、状态、Shuffle 或资源变化，验证方案是否真正生效。
- 输出结果：用行数、唯一性、关键指标和样本明细证明结果正确，而不是只看任务成功。
- 失败恢复：说明重跑、回滚、版本兼容和责任人，避免一次成功后无人维护。
这些检查不一定全部写进一条 SQL 或一个任务，但面试时能主动补充，说明你回答的不是背诵题，而是在描述一套可上线的工程方案。
一个典型场景
典型场景是任务先 Append 明细，再覆盖汇总。第一次运行写入明细后失败，重跑再次 Append，汇总层按用户去重所以人数正常，但金额对明细求和后翻倍。修复后使用运行批次加业务主键去重，明细先写影子分区，校验通过再切换，并把通知步骤放入独立幂等环节。
可重跑的目标不是“再次成功”，而是“再次执行仍得到同一业务状态”。