首页/数据/数仓建模速查/幂等写入:重跑结果一致
分层与规范64 条

幂等写入:重跑结果一致

幂等是调度可重跑的前提:按分区先删后插、或整分区重写;避免 INSERT INTO 无去重、避免依赖自增序列与当前时间字段。

数仓建模速查数据更新于 2026-10-13

幂等写入是什么

幂等指同一个任务重跑多次,结果与只跑一次相同,这是调度敢放心重跑的前提。实现手段主要有两类:按分区先删后插(或整分区重写),让每次写入覆盖同一范围;以及用业务主键加更新时间的去重逻辑,让重复数据在写入前被合并。常见破坏幂等的写法有三种:INSERT INTO 无去重追加、把系统当前时间写进分区字段、依赖自增序列生成主键。

基本信息

判断标准重跑两次,结果与只跑一次一致
常用手段按分区先删后插、整分区重写
需要避免无去重追加、依赖当前时间与自增序列
验证方法同一分区连续执行两次,比对行数与指标
关联机制调度自动重试、人工补数回刷

典型使用场景

  • 调度失败自动重试:任务必须幂等,否则重试一次就多写一份数据
  • 人工补数回刷历史分区:按分区覆盖写入,不影响其他日期
  • 开发调试反复执行同一段 SQL:幂等写法可以放心重复运行
  • 实时与批量都写同一张目标表:需要明确由谁负责最终结果
  • 上下游重跑顺序不同的场景:分区级幂等能避免互相覆盖

幂等写法

幂等写法
-- 先清理目标分区再写入:重跑结果一致,可安全重试
ALTER TABLE dws_trade_store_day DROP IF EXISTS PARTITION (dt='2026-10-13');
INSERT INTO TABLE dws_trade_store_day PARTITION (dt='2026-10-13')
SELECT store_id, order_cnt, pay_amt FROM tmp_trade_store_day;

-- 等价写法:整分区重写,效果相同
INSERT OVERWRITE TABLE dws_trade_store_day PARTITION (dt='2026-10-13')
SELECT store_id, order_cnt, pay_amt FROM tmp_trade_store_day;

写法是否幂等

写法是否幂等原因
INSERT OVERWRITE ... PARTITION(dt=...)幂等每次覆盖同一个分区
先 DROP PARTITION 再 INSERT幂等清理范围与写入范围一致
INSERT INTO 且无去重不幂等每次追加一批,重跑后翻倍
分区字段取 current_date()不幂等跨天重跑会写进另一个分区
依赖自增 ID 或序列不幂等重跑生成新 ID,重复行无法合并
用系统当前时间做分区或版本字段会直接破坏幂等:重跑写进不同分区,产生重复数据或空分区。分区日期应由调度传入,或从业务数据里取,不要取自运行时刻。
验证幂等的办法很简单:在测试环境对同一分区连续执行两次,比对行数与关键指标是否一致。这个动作比事后靠对账发现问题便宜得多。

易错点

  • 任务失败后直接重跑:无去重追加导致数据重复,且往往无人发现
  • 分区取自运行时刻:跨零点重跑写进另一个分区,产生空分区与重复数据
  • DROP PARTITION 与 INSERT 范围不一致:清了 A 分区却写进 B 分区,旧数据残留
  • 只在开发环境保证幂等:生产调度参数不同(日期变量来源不同),幂等实际已失效
  • 把去重责任推给下游:每个下游各实现一套去重逻辑,迟早出现不一致

数据来源与参考

  • 阿里《大数据之路:阿里巴巴大数据实践》
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌