数仓分层是什么
分层是把数据从「贴源的原始形态」一步步加工到「可直接使用的指标结果」的过程拆成若干有明确职责的层：ODS 负责贴源落地，DWD 负责业务过程明细，DIM 承载公共维度，DWS 做主题级轻汇总，ADS 输出面向报表与接口的结果。
为什么要分层
三层收益很实在。第一是复用：一份明细清洗好之后，多个主题的汇总都从它出发，避免每个需求各自从原始表加工一遍。第二是口径收口：指标口径落在固定层，改一处就能改全链路。第三是可追溯：从最终结果能沿链路回溯到原始记录，出现异常时能定位到具体环节。
基本信息
| 常见层数 | ODS / DWD / DIM / DWS / ADS 五层，小团队可合并到四层 |
|---|---|
| 分层依据 | 按加工深度与复用范围划分，而不是按报表划分 |
| 命名约定 | 层前缀加主题与频率后缀，如 dwd_trade_order_detail_di |
| 更新频率 | 通常按天分区，dws 可能是 1d / nd / td 多种粒度 |
| 代价 | 存储冗余与调度节点增加，链路变长后延迟上升 |
分层对照
| 层次 | 定位 | 典型加工 |
|---|---|---|
| ODS | 贴源落地，结构与源一致 | 抽取、加分区、极少清洗 |
| DWD | 业务过程明细，清洗后复用 | 去重、脱敏、类型规范、维度退化 |
| DIM | 公共维度，全库共享 | 一致性编码、历史跟踪（拉链表） |
| DWS | 按主题轻度汇总 | 按天与粒度聚合出宽表 |
| ADS | 面向报表与接口的最终结果 | 口径计算、指标落地 |
典型使用场景
- 新建数仓：先划清各层职责与命名规范，再动手建表
- 口径打架：把指标实现位置统一收口到某一层，明确只在这一层定义
- 新人接手：能按层前缀判断一张表的加工深度与更新方式
- 链路排障：按「源端—ODS—DWD—DWS—ADS」逐层核对，快速定位断在哪一段
- 性能优化：把重复计算下沉到公共层，避免多个 ADS 任务各算一遍
分层命名示例
分层命名示例
ods_order_mysql 源库订单表贴源，字段与源一致
dwd_trade_order_detail_di 订单明细（di 表示日增量）
dim_user_zip 用户维度拉链表（含生效与失效时间）
dws_trade_user_1d 用户主题日汇总（1d 表示最近一天）
ads_order_overview_1d 订单看板日结果
# 后缀约定同一套：di 日增量 / df 日全量 / 1d 最近一天 / nd 最近 N 天 / td 累计至今分层不是越多越好：小团队可以只保留 ODS / DWD / DWS / ADS 四层，关键是每层的边界清晰、指标只在固定层实现。层数多而职责重叠，比少一层更麻烦。
ADS 直接读 ODS 跳过公共层会迅速制造口径分裂：同一个指标在不同报表里各写一遍 SQL，改口径时改一处漏三处，最终没人能说清哪张表是对的。