做了 3 年数仓，才发现分层的本质不是分表，是分职责
数仓分层治理
问：「详细讲一下 DWM、DWT、DWS 这些层的具体职责，以及它们之间的数据流向。如果 DWS 层某个指标不准了，你会怎么排查？」
字节数仓分层（比传统 4 层更细）：
| 层级 | 全称 | 职责 | 示例表 |
| ODS | Operational Data Store | 原始数据，不做处理 | ods_orders, ods_user_behavior |
| DWD | Data Warehouse Detail | 清洗 + 维度退化 + 标准化 | dwd_order_detail, dwd_user_login_log |
| DWM | Data Warehouse Middle | 轻度汇总，通用中间层 | dwm_user_order_daily（每个用户每天的订单汇总） |
| DWT | Data Warehouse Topic | 主题宽表，跨域关联 | dwt_user_behavior_wide（用户行为宽表） |
| DWS | Data Warehouse Service | 服务层聚合，面向指标 | dws_gmv_daily（日 GMV 指标） |
| ADS | Application Data Service | 应用层，直接对接报表 | ads_dashboard_gmv_trend |
数据流向： ODS ─→ DWD（清洗/标准化）─→ DWM（轻汇总）─→ DWT（主题宽表）─→ DWS（指标）─→ ADS（应用） └── 可以跳过 DWM/DWT 直接 DWD → DWS（简单指标） └── DWM 和 DWT 之间可以双向（DWT 反过来给 DWM 提供维度）
DWS 指标不准排查流程：
Step 1: 确认异常时间点
→ 查监控看板，确认是哪个 dt 的指标出问题
Step 2: 分层回溯
→ ADS 层对比昨天今天的数据量，确认问题在 ADS 还是更下层
→ DWS 层查该 dt 的数据量和历史同期的偏差，确认问题是否在 DWS
Step 3: 血缘追踪
→ 查数据血缘工具（Atlas / DataHub / 自研），看 DWS 表依赖哪些上游表
→ 逐层向上追踪：DWS ← DWT ← DWM ← DWD ← ODS
Step 4: 上游表对账
→ 对每个上游表，抽样对比今天 vs 昨天的数据量、NULL 率、关键字段分布
→ 哪个表的数据量和历史偏差最大，大概率是脏数据来源
Step 5: 根因定位
→ ODS 层问题：上游业务系统字段变更 / 数据未写入 / 格式变化
→ DWD 层问题：清洗逻辑改动 / 增量数据未触达 / 分区写入失败
→ DWM/DWT 层问题：JOIN 逻辑变更 / 关联率下降
Step 6: 修复 + 通知
→ 重跑失败任务 + 通知下游 + 建专项数据质量监控规则