全量与增量怎么选
汇总表有两种刷新方式。全量重算每天把整个汇总重跑一遍，逻辑简单、结果与明细天然一致，代价是资源消耗随历史规模增长；增量滚动只算新增分区再追加，省资源，但必须处理迟到数据、重复提交与历史修正三件事。选择标准通常是上游稳定性与数据量：上游稳定、数据量大的事实表用增量，口径频繁调整、数据量可控的表用全量。
基本信息
| 全量重算 | 结果稳定，成本随历史规模上升 |
|---|---|
| 增量滚动 | 只算新分区，需配套回补机制 |
| 风险点 | 迟到数据、重复提交、历史修正 |
| 幂等要求 | 同一分区重跑结果一致 |
典型使用场景
- 日粒度汇总表数据量大、上游稳定，用增量滚动加分区覆盖写
- 口径频繁调整阶段用全量重算，省掉回补逻辑的维护成本
- 迟到数据到达后按受影响分区定向回补，而不是整表重跑
- 上游批量修正历史（财务调账、组织调整）时评估是否全量重算
- 为长跑任务加并发保护，避免两次运行同时写同一分区
增量与回补
增量与回补
-- 每日增量：按分区覆盖写，保证重跑幂等
INSERT OVERWRITE TABLE dws_sales_day PARTITION (dt = '2026-10-12')
SELECT '2026-10-12' AS dt,
region_sk,
sum(amt) AS amt,
count(1) AS order_cnt
FROM dwd_sales
WHERE dt = '2026-10-12'
GROUP BY region_sk;
-- 回补：明细分区被修正后，重算并覆盖同分区
-- 触发条件来自明细的更新时间，而不是固定周期策略对照
| 策略 | 适用条件 | 主要风险 |
|---|---|---|
| 全量重算 | 数据量可控、口径常变 | 资源消耗随历史增长 |
| 增量滚动 | 上游稳定、数据量大 | 迟到数据造成长期偏差 |
| 混合 | 热分区增量、冷分区全量 | 两套逻辑需同时维护 |
增量方案必须配套迟到数据回补任务，触发依据是明细的更新时间或上游数据水位，而不是凭经验定期重跑历史区间。
全量重算要加并发保护与超时控制：上一次还没跑完就启动下一次，两个任务会同时写同一分区，结果不可预期。