分层边界是什么
数仓分层（ODS 贴源、DWD 明细、DWS 汇总、ADS 应用）本身不解决数据可信问题，真正决定结果的是「一段加工逻辑写在哪一层」。边界划得太浅，同一套清洗与映射会在多个下游各写一份；划得过深，公共层就被单个业务需求绑架，改一次全体回归。
各层职责
| ODS | 贴源落地、分区、去重与追加，不做业务加工 |
|---|---|
| DWD | 清洗、类型规范、维度退化、枚举与金额口径统一 |
| DWS | 按主题与常用维度做共性聚合，供多个下游复用 |
| ADS | 最终口径与交付形态，允许含报表定制逻辑 |
| 总原则 | 同一规则只写一处；越通用越靠前，越易变越靠后 |
典型使用场景
- 新需求评审：判断新增字段进 DWD 公共层，还是只在 ADS 报表里算
- 口径冲突排查：两个报表同一指标数字不同，先看规则是否分裂在多层
- 上游变更评估：变更落在公共层还是应用层，直接决定回归测试范围
- 公共层重构：把散落在 ADS 里的通用聚合上移到 DWS 复用
- 成本治理：减少同一份明细被反复扫描、重复计算
判断标准对照
| 情形 | 建议落层 | 理由 |
|---|---|---|
| 被两个以上下游使用的清洗与映射 | DWD | 改一处即可全链路生效，避免口径分裂 |
| 只服务单一报表的定制聚合 | ADS | 变更不牵动公共层，回归面最小 |
| 多报表共用的汇总口径 | DWS | 一次计算多次复用，省资源也保一致 |
| 高频变化的业务规则（活动口径） | ADS 或配置表 | 公共层求稳，规则外置便于快速调整 |
判断清单
判断清单
# 按顺序回答，先命中先决定落层
# 这段逻辑有 2 个以上下游使用吗？
# 是 -> 下沉 DWD 或 DWS
# 是业务规则吗（枚举映射、币种、单位换算）？
# 是 -> 放 DWD，不要留在报表里
# 只服务一个报表吗？
# 是 -> 留在 ADS
# 经常变吗？
# 是 -> 放 ADS 或配置表，避开公共层
# 改动需要全链路重跑吗？说明放得太浅，考虑上移分层不是教条：团队规模小时 DWD 与 DWS 可以合并成一套明细层，但「规则只写一处」不能破，否则合并只是把混乱集中进一张更大的表。
公共层表被单个业务需求改动后，所有下游都要回归测试。公共层变更应走评审，并附下游任务、报表、指标的影响面清单。