迟到数据怎么修正
按事件时间分区的事实表收到迟到数据时，不能简单追加，而要重写受影响分区。标准动作是先把迟到记录按它原本所属的日期分组，锁定受影响的分区集合，再用动态分区覆盖写入整个分区。范围能收窄就收窄：一次纠正重写半个月分区，既浪费资源，也会把没有问题的日期一起重算，风险成倍放大。
基本信息
| 处理策略 | 重写受影响分区，而非追加 |
|---|---|
| 核心语法 | INSERT OVERWRITE TABLE ... PARTITION (dt) |
| 影响范围 | 迟到数据所属日期去重后的集合 |
| 执行前置 | 备份受影响分区或依赖快照隔离 |
| 执行后校验 | 行数、唯一键、与上游明细核对 |
典型使用场景
- 移动端埋点延迟上报：昨天的行为数据今天才到
- 第三方对账文件延迟：T 加 1 甚至 T 加 2 才拿到明细
- 上游系统故障补推：停机恢复后批量重推数小时数据
- 跨时区业务：海外站数据按北京时间分区会天然迟到
- 人工补录：运营后台补录历史订单需要回写原日期分区
动态分区重写
动态分区重写
-- 先确认受影响日期集合，再整分区覆盖
SELECT DISTINCT dt AS affected_dt FROM stg_order_late;
INSERT OVERWRITE TABLE dwd_order PARTITION (dt)
SELECT order_id, user_id, amount, update_ts, dt
FROM stg_order_late
WHERE dt IN ('2026-10-09', '2026-10-11');
-- 执行后核对：分区行数与重写前差值应等于迟到记录净增量三种处理方式对比
| 方式 | 代价 | 风险 |
|---|---|---|
| 直接追加 | 最低 | 同键多行并存，指标虚高 |
| 重写受影响分区 | 中等 | 需快照或备份，期间下游读到中间态 |
| 全表重建 | 最高 | 影响面过大，通常没必要 |
动态分区覆盖要显式限定分区范围：不写条件的动态分区写入会覆盖表中所有同名的分区，把无关日期的数据清空。执行前先跑一次受影响日期清单的确认查询，再执行重写。
重写期间下游若在跑，会读到「部分分区已新、部分仍旧」的中间状态。做法是重写完成后统一通知下游重跑，或在下游读取时按批次日过滤，避免跨日期的不一致结论。