● ADS层与DWS层的区别与划分边界

这是数仓建设中最容易模糊的一对概念。很多团队 DWS 和 ADS 表混在一起，本质就是没想清楚这两层的边界。

---

一、本质区别：通用性 vs 定制性

┌──────────┬────────────────────────────┬────────────────────────────────┐
│ 维度 │ DWS 汇总层 │ ADS 应用层 │
├──────────┼────────────────────────────┼────────────────────────────────┤
│ 核心定位 │ 公共汇总指标层 │ 专属应用结果层 │
├──────────┼────────────────────────────┼────────────────────────────────┤
│ 服务对象 │ 服务 N 个下游应用 │ 服务 1 个具体应用 │
├──────────┼────────────────────────────┼────────────────────────────────┤
│ 建模导向 │ 数据导向（围绕分析对象） │ 业务导向（围绕业务诉求） │
├──────────┼────────────────────────────┼────────────────────────────────┤
│ 复用性 │ 高度复用（一次算多次用） │ 不追求复用（专表专用） │
├──────────┼────────────────────────────┼────────────────────────────────┤
│ 指标性质 │ 原子指标、基础派生指标 │ 复合指标、业务指标 │
├──────────┼────────────────────────────┼────────────────────────────────┤
│ 粒度 │ 标准粒度（用户/店铺/商品） │ 业务粒度（千人千面、混合维度） │
├──────────┼────────────────────────────┼────────────────────────────────┤
│ 稳定性 │ 稳定（变化少） │ 易变（跟着需求走） │
├──────────┼────────────────────────────┼────────────────────────────────┤
│ 数据组织 │ 宽表（横向扩展指标） │ 结果表（贴合应用结构） │
├──────────┼────────────────────────────┼────────────────────────────────┤
│ 加工逻辑 │ 标准化聚合 │ 业务规则、排名、分层、阈值 │
├──────────┼────────────────────────────┼────────────────────────────────┤
│ 谁来用 │ 数据开发、分析师 │ 业务方、产品、运营、算法 │
├──────────┼────────────────────────────┼────────────────────────────────┤
│ 下游 │ 给 ADS、其他 DWS、临时分析 │ 给 BI、API、看板、算法 │
└──────────┴────────────────────────────┴────────────────────────────────┘

---

二、淘宝场景对比

DWS 层：通用的"指标超市"

dws_user_trade_nd（用户多周期交易宽表）
字段：
user_id, dt,
– 都是基础原子/派生指标，不掺杂业务规则
pay_amount_1d, pay_amount_7d, pay_amount_30d, pay_amount_90d,
pay_order_cnt_1d, pay_order_cnt_7d, pay_order_cnt_30d,
refund_amount_30d, refund_rate_30d,
avg_order_value_30d,
last_pay_date, first_pay_date,
buy_cate_cnt_30d, buy_brand_cnt_30d

特点：

• 任何用 user_id 切片的分析都能用
• 字段是"中性的",不带业务判断
• 一张表喂养几十个下游应用

---

ADS 层:专属的"业务成品"

ads_member_rfm（RFM 会员分层结果表）
字段：
user_id, dt,
R_score, – 1-5 分
F_score, – 1-5 分
M_score, – 1-5 分
rfm_segment – “重要价值客户”/“重要发展客户”/“流失预警”/…
– ↑ 这是【业务定义】的分层结果

ads_double11_dashboard（双11大屏）
字段：
dt, hour,
total_gmv, gmv_yoy, gmv_target_complete_rate, – 同比、达成率
top10_cate_json, – 类目TOP10的JSON
top10_shop_json, – 店铺TOP10的JSON
realtime_uv, peak_qps – 大屏专用字段

ads_shop_score_rank（商家评分排名）
字段：
shop_id, dt,
trade_score, service_score, logistics_score,
total_score,
rank_in_cate, – 类目内排名
rank_change, – 排名变化
star_level – 1-5 星

特点：

• 字段紧贴某个具体业务场景
• 充满"业务规则"：分数怎么算、星级怎么定、TOP10怎么选
• 换一个场景就需要换一张表

---

三、判断一张表该放 DWS 还是 ADS：5 个核心判据

判据1：是否被多个下游复用？

问：这张表会被几个应用使用？

1 个 → DWS（通用资产，沉淀复用）
= 1 个 → ADS（专属应用，无需通用化）

例子：

• dws_user_trade_nd 同时喂给 RFM分层、流失预测、营销推送、业务看板 → DWS
• ads_double11_dashboard 只服务双11大屏一个产品 → ADS

判据2:是否包含业务规则/阈值/排序?

问：表里有没有"业务上的判断"？

无 → DWS（中性指标）
有 → ADS（业务结果）

业务规则的信号词：

• 分层：高价值/低价值、活跃/沉默、新客/老客
• 阈值：>1000元算大客户、<7天未登录算流失
• 排名：TOP10、行业第N
• 评级：1-5星、A/B/C级
• 标签:“潜力流失”、“重要保持”

只要出现这些,就是 ADS。

判据3:粒度是否标准?

DWS 粒度：单一标准对象 + 时间
- user_id + dt
- shop_id + dt
- item_id + dt

ADS 粒度：可能是混合的、应用导向的
- dt + 类目 + 地区 + 渠道（多维交叉）
- 一行一个看板（整个看板序列化成一行）
- 一行一个用户的所有标签（千人千面）

判据4:换需求会不会影响?

问：业务方改了一个需求,这张表要不要动?

不动,只是下游 SQL 改 → DWS（稳定的资产）
要改字段或重建 → ADS（贴合需求的成品）

判据5:它的"用户"是谁?

数据开发拿来做下一步加工 → DWS
业务方/BI/API 直接消费 → ADS

---

四、加工逻辑的差异

DWS 的加工：标准化聚合

– dws_user_trade_nd（典型 DWS 逻辑）
SELECT
user_id,
SUM(IF(dt >= date_sub(now(), 30), pay_amount, 0)) AS pay_amount_30d,
COUNT(DISTINCT IF(dt >= date_sub(now(), 30), order_id)) AS pay_order_cnt_30d,
MAX(pay_time) AS last_pay_date
FROM dwd_trade_order_pay_di
GROUP BY user_id;

只有 SUM/COUNT/MAX/AVG 这种纯统计,没有业务判断。

ADS 的加工:业务规则落地

– ads_member_rfm(典型 ADS 逻辑)
SELECT
user_id,
– R/F/M 打分:业务规则
CASE
WHEN datediff(now(), last_pay_date) <= 30 THEN 5
WHEN datediff(now(), last_pay_date) <= 60 THEN 4
WHEN datediff(now(), last_pay_date) <= 90 THEN 3
WHEN datediff(now(), last_pay_date) <= 180 THEN 2
ELSE 1
END AS R_score,

CASE
  WHEN pay_order_cnt_90d >= 10 THEN 5
  WHEN pay_order_cnt_90d >= 5  THEN 4
  ...
END AS F_score,

-- RFM 分层:业务定义
CASE
  WHEN R>=4 AND F>=4 AND M>=4 THEN '重要价值客户'
  WHEN R>=4 AND F<=2 AND M>=4 THEN '重要发展客户'
  WHEN R<=2 AND F>=4 AND M>=4 THEN '重要保持客户'
  WHEN R<=2 AND F<=2 AND M>=4 THEN '重要挽留客户'
  ...
END AS rfm_segment

FROM dws_user_trade_nd – ← 直接拿 DWS 的指标用
WHERE dt = ‘2026-06-11’;

充满 CASE WHEN、阈值、业务标签。

---

五、典型数据流：DWD → DWS → ADS

dwd_trade_order_pay_di (一条支付明细)
dwd_trade_order_refund_di (一条退款明细)
│
│ 按用户 group by 多周期聚合
▼
dws_user_trade_nd (用户:30天支付3500元、12笔)
│
│ 套用业务规则:RFM 打分 + 分层
▼
ads_member_rfm (用户A = “重要价值客户”)
│
▼
营销系统 API / CRM 看板

DWS 是"原料",ADS 是"菜品"。
同一份原料(dws_user_trade_nd),可以做成不同的菜:

• → ads_member_rfm(RFM 分层)
• → ads_member_churn(流失预测特征)
• → ads_member_lifecycle(生命周期分布)
• → ads_marketing_target(营销人群包)

---

六、常见误区与纠偏

误区1:把 ADS 当 DWS 用

❌ 错误做法:
ads_member_rfm 算好了"重要价值客户",
另一个业务方说:“我也要这个分层,直接用你的 ADS 表”

✅ 正确做法:
如果 RFM 分层要被复用,就要把它【沉淀】到 DWS,
新建 dws_user_rfm_nd 作为公共资产,
两个 ADS 都从 dws_user_rfm_nd 取。

判断信号:当一个 ADS 开始被多个下游引用,它就该升级为 DWS。

误区2:DWS 里写业务规则

❌ 错误做法:
– dws_user_trade_nd 里直接写
CASE WHEN pay_amount_30d > 1000 THEN ‘高价值’ END AS user_level

✅ 正确做法:
"高价值"是业务定义的(可能今天>1000,明天>2000),
应该放到 ADS,DWS 只提供 pay_amount_30d 这个原子指标。

误区3:DWS 太薄,ADS 干所有活

❌ 现象:DWS 只是 DWD 的简单 group by,几乎没指标沉淀,
所有计算都在 ADS 里写,导致 ADS 表之间大量重复计算。

✅ 修正:把多个 ADS 共用的中间指标下沉到 DWS。

误区4:DWS 太厚,把 ADS 该做的也做了

❌ 现象:DWS 里堆了几百个字段,包含各种排名、分层、标签,
导致 DWS 表跟着业务需求频繁变更,失去稳定性。

✅ 修正:带业务规则的字段抽到 ADS。

---

七、划分边界的实战准则

准则1:DWS 沉淀"指标",ADS 沉淀"应用"

DWS 关心:这个用户/店铺/商品有哪些可度量的事实?
ADS 关心:这个业务问题(看板/算法/活动)需要什么数据?

准则2:DWS 的字段名都是中性的

DWS:pay_amount_30d、order_cnt_30d、avg_order_value_30d
(都是事实)

ADS:rfm_segment、is_high_value、churn_risk_level、shop_star
(都是判断/标签)

准则3:DWS 表少而精,ADS 表多而专

一个大型电商:
DWS 大约 20-50 张(用户/店铺/商品/类目/品牌主题宽表)
ADS 可能 200-500 张(每个看板、每个 API、每个活动专属表)

准则4:三个问题快速分流

面对一张要建的表,问自己:

1. 会被几个应用用? → 多个=DWS,单个=ADS
2. 里面有业务规则吗? → 有=ADS,没有=DWS
3. 它的客户是数据人还是业务人? → 数据人=DWS,业务人=ADS

三个问题,基本不会划错层。

---

八、对比总结表

┌──────────┬──────────────────┬─────────────────────┐
│ 维度 │ DWS │ ADS │
├──────────┼──────────────────┼─────────────────────┤
│ 角色 │ 公共资产 │ 业务成品 │
├──────────┼──────────────────┼─────────────────────┤
│ 通用性 │ 高 │ 低 │
├──────────┼──────────────────┼─────────────────────┤
│ 业务规则 │ 不含 │ 大量包含 │
├──────────┼──────────────────┼─────────────────────┤
│ 指标性质 │ 原子/派生 │ 复合/业务 │
├──────────┼──────────────────┼─────────────────────┤
│ 字段含义 │ 中性的事实 │ 业务的判断 │
├──────────┼──────────────────┼─────────────────────┤
│ 粒度 │ 标准对象+时间 │ 业务定制 │
├──────────┼──────────────────┼─────────────────────┤
│ 数量级 │ 几十张 │ 几百张 │
├──────────┼──────────────────┼─────────────────────┤
│ 稳定性 │ 稳定 │ 易变 │
├──────────┼──────────────────┼─────────────────────┤
│ 谁建 │ 数据开发(数仓侧) │ 数据开发+业务方共建 │
├──────────┼──────────────────┼─────────────────────┤
│ 谁消费 │ 下游数据加工 │ BI/API/算法 │
├──────────┼──────────────────┼─────────────────────┤
│ 变更频率 │ 低 │ 高 │
├──────────┼──────────────────┼─────────────────────┤
│ 命名 │ dws_主题_周期 │ ads_业务方向_应用 │
└──────────┴──────────────────┴─────────────────────┘

---

九、一句话总结

▎ DWS 是"指标的中央厨房",ADS 是"端到客户面前的菜"。
▎
▎ - DWS 解决"重复计算"问题 —— 把通用指标算一次,N 个下游复用
▎ - ADS 解决"业务对接"问题 —— 把指标包装成业务方能直接消费的形态
▎
▎ 最关键的一刀切:有没有业务规则。
▎ - 纯统计聚合 → DWS
▎ - 含分层/排名/阈值/标签 → ADS

记忆口诀:

• DWS 像批发市场:卖标准化的食材,谁来都能买
• ADS 像私房菜馆:为特定客人定制菜品,带着厨师的手艺(业务规则)