数仓任务用全量刷新还是增量更新？怎么选、增量怎么保证正确？

一句话：全量用完整快照覆盖，换资源买正确和简单；增量只处理新变化，省扫描但要把水位、回放和对账设计进去。没有「永远增量」这回事，只有「日常增量、出错能回放、定期全量校准」。

先看数据怎么变，再谈刷新方式。
- 上游每天给你一张完整快照（用户维、配置表、全量导出）：目标表本质是「昨天那一版长什么样」。这种表全量覆盖最干净。
- 上游是业务流水或 CDC（订单、点击、账变）：事实按事件追加，按 dt 或主键变更加增量。
- 还有第三种：看起来像流水，但源库会改历史（售后改金额、状态回撤）。增量必须能重放那一段，不能只 append。

全量刷新。 读上游当日完整集合，写出覆盖目标。常见落地是分区覆盖：INSERT OVERWRITE TABLE ads_user_daily PARTITION (dt='昨天')，或整表替换后改指针。优点：逻辑等于「昨天快照」，重跑就是再覆盖一次，对账用行数+主键哈希就够。缺点：维表 10 亿、每天只变 0.1%，你仍扫全量、写全量，贵，也容易把高峰窗口打满。

增量更新。 只处理「上次水位之后」的变化。水位可以是业务时间（updated_at > last_watermark）、分区日期（只跑 dt=昨天）、或 CDC 位点（LSN/binlog）。写出必须幂等：
- 日分区事实：覆盖 dt 分区，不要往分区里 append 出重复文件。
- 主键型明细：按主键 MERGE（有则更新、无则插入），回撤用删除标记或版本比较。

口述级增量骨架：

-- 日分区事实：只跑昨天，覆盖写出，重跑不双计
INSERT OVERWRITE TABLE dwd_order_item PARTITION (dt='${bizdate}')
SELECT order_id, user_id, sku_id, pay_amt, pay_time, ...
FROM ods_order_item
WHERE dt = '${bizdate}';

-- 主键维：按更新时间拉增量，MERGE 进当前像
MERGE INTO dim_user t
USING (
  SELECT * FROM ods_user_cdc
  WHERE updated_at > '${last_watermark}'
) s
ON t.user_id = s.user_id
WHEN MATCHED AND s.updated_at >= t.updated_at THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *;

增量最容易错的三件事。
1. 水位切错：用处理时间当业务时间，源库卡住时你会以为「没新数据」；或 > 写成 >= 在边界重复、写成 > 又漏掉同一秒多条。约定半开半闭：(last_wm, current_wm]，并持久化水位表。
2. 迟到和回撤：T-2 的订单今天才进 ODS，只跑昨天分区会漏。增量窗口要留 lookback（例如重跑近 3 天分区），或按事件日 MERGE 进历史分区。回撤要版本字段，不能只 insert。
3. 漏抽没有报警：增量成功但少了 10% 变更，调度是绿的。必须有全量对账：主键差集、金额 checksum，按周或按天对热点表。

怎么选。
- 小表、维表、枚举、口径常改的指标表：全量。正确性优先，省下来的钱不够一次事故。
- 大事实、按日不可变事件（点击、曝光）：按 dt 增量覆盖。
- 会改历史的大表：增量 MERGE + 定期全量校准（周末或月末拿源库快照对一遍）。
- 口径重刷、回填 30 天：走分区覆盖回放，不要手写 30 条 UPDATE。

收尾三句：按变更形态选型、增量必须幂等且可回放、全量对账兜底。能主动说「日常增量、出错回放近 N 天、定期全量校准」，这题就过了。