10.指标体系设计：原子指标 / 派生指标 / 复合指标 + 口径管理
指标体系是数仓「向上交付」的最后一环。指标定义不清，报表对不上，一切建模白费。这篇文章讲清原子/派生/复合指标的划分，以及最难的「口径管理」。
数仓建得再好，最终都要落到「指标」上。但「GMV」「活跃用户数」「留存率」这些词，在不同团队、不同报表里常常意味着不同的东西。指标体系设计的核心，就是让同一个指标，全公司只有一个定义、一个算法、一个结果。
一、什么是指标：从「度量」到「指标」
先厘清几个容易混淆的概念：
| 概念 | 含义 | 例子 |
|---|---|---|
| 度量（Measure） | 事实表里的可量化数值 | amount、qty |
| 维度（Dimension） | 观察度量的角度 | 时间、地区、用户 |
| 指标（Metric） | 度量 + 维度 + 统计口径的组合 | 「昨日 GMV」「北京用户日均下单数」 |
指标 = 「什么度量」 + 「什么维度」 + 「什么口径」。缺一个，指标就定义不清。
二、原子指标（Atomic Metric）
2.1 定义
原子指标是不可再拆分的度量，是指标体系的最小单位。它只回答「度量是什么」，不含维度、不含统计口径。
| 原子指标 | 含义 |
|---|---|
| 支付金额 | 用户支付的金额总和 |
| 下单数量 | 订单的数量 |
| 活跃用户数 | 活跃的去重用户数 |
2.2 特征
- 只描述度量本身，不含「时间/地区」等维度限定
- 通常直接来自事实表的某个字段 + 一个聚合方式（SUM/COUNT/DISTINCT）
-- 原子指标「支付金额」：事实表字段 + 聚合方式
SELECT SUM(pay_amount) FROM dwd_trd_payment_detail;
三、派生指标（Derived Metric）
3.1 定义
派生指标 = 原子指标 + 维度 + 统计口径。它是实际业务中最常用的指标形态。
| 派生指标 | 原子指标 | 维度 | 统计口径 |
|---|---|---|---|
| 昨日 GMV | 支付金额 | 日期 | 昨日（where dt=昨天） |
| 北京用户日均下单数 | 下单数量 | 地区+日期 | 北京、日 |
| 近 7 日活跃用户数 | 活跃用户数 | 日期 | 近 7 日（去重） |
3.2 特征
- 一个原子指标，配上不同维度和口径，派生出多个派生指标
- 派生指标是可复用的公共指标，通常物化在 DWS 层
-- 派生指标「用户日支付金额」：原子指标 + 用户维度 + 日口径
SELECT
user_id,
SUM(pay_amount) AS pay_amount_1d
FROM dwd_trd_payment_detail
WHERE dt = '${biz_date}'
GROUP BY user_id;
四、复合指标（Composite Metric）
4.1 定义
复合指标 = 多个指标之间的运算，通常表达「比率」「均值」这类相对值。
| 复合指标 | 构成 |
|---|---|
| 支付转化率 | 支付用户数 ÷ 下单用户数 |
| 客单价 | GMV ÷ 订单数 |
| 7 日留存率 | 第 7 日回访用户数 ÷ 新增用户数 |
4.2 关键：复合指标不能直接 SUM
复合指标（尤其比率类）是不可加事实，直接对分子分母分别聚合，再在 BI 层做除法：
-- ✅ 正确：分别算分子分母，BI 层再除
SELECT
COUNT(DISTINCT CASE WHEN is_paid = 1 THEN user_id END) AS pay_users,
COUNT(DISTINCT user_id) AS order_users
FROM dwd_trd_order
WHERE dt = '${biz_date}';
-- ❌ 错误：直接把各天的「转化率」相加再平均，结果无意义
复合指标的坑：「比率」不能直接 SUM 或 AVG 原始比率。应该存「分子 + 分母」两个可加分量，在 BI 层再算比率。这和 事实表完全指南 里的「不可加事实存可加分量」是同一个道理。
五、口径管理：指标体系最难的一环
5.1 什么是口径冲突
「活跃用户」这个指标，在你的公司有几个版本？
- 版本 A：当天打开过 App 的用户
- 版本 B：当天有任意行为的用户
- 版本 C：当天登录过的用户
如果三个团队各自算，报表必然对不上。这就是口径冲突。
5.2 口径管理的三个原则
| 原则 | 说明 |
|---|---|
| 一处定义 | 每个指标只在权威位置定义一次，下游只引用不重算 |
| 口径可落地 | 每个指标能写成确定的「表 + 字段 + 过滤条件 + 聚合方式」 |
| 口径与模型绑定 | 口径文档不能脱离模型独立维护，否则三个月后必对不上 |
5.3 指标命名规范
好的指标名，一眼能看出「原子 + 维度 + 口径」：
{主体}_{度量}_{时间粒度/口径}
例：
pay_amount_1d 支付金额，日粒度
active_users_7d 活跃用户数，近 7 日
order_cnt_30d 下单数，近 30 日
gmv_wow_rate GMV 环比（复合指标）
命名本身就是口径的一部分。
pay_amount_1d和pay_amount_7d是两个不同的派生指标，不能混用。这对应 数据仓库建模原则 里的「命名是契约」。
六、指标体系的分层落地
指标体系和数仓分层是对应的：
| 层 | 指标体系对应物 |
|---|---|
| DWD | 原子指标（事实度量） |
| DWS | 派生指标（公共汇总，可复用） |
| ADS | 复合指标 + 定制口径（具体报表） |
原子指标（DWD 度量）
↓ + 维度 + 口径
派生指标（DWS 公共汇总）
↓ 多个指标运算
复合指标（ADS 定制结果）
关键：派生指标放 DWS 复用，复合指标放 ADS 定制。别在 DWD 里算比率，也别把某个报表的口径塞进 DWS——这和 数仓分层的常见误区 里「DWS 与 ADS 职责不清」是同一个坑。
七、常见坑点
- 原子指标直接做报表——原子指标不含口径，直接拿去当「GMV」会漏掉「已支付」「已发货」等过滤条件
- 比率类复合指标直接 SUM——各天的转化率相加无意义，应存分子分母
- 同名不同义——两个团队都叫「活跃用户」但口径不同，报表对不上
- 口径只写文档不落地——口径定义写不成确定的 SQL，等于没定义
- 派生指标塞进 ADS——本该 DWS 复用的公共指标被某张报表私有化，别人又重算一遍
八、小结
| 类型 | 定义 | 例子 | 放哪层 |
|---|---|---|---|
| 原子指标 | 不可拆分的度量 | 支付金额 | DWD |
| 派生指标 | 原子 + 维度 + 口径 | 昨日 GMV | DWS |
| 复合指标 | 多指标运算 | 支付转化率 | ADS |
指标体系的本质，是**「让每个指标只有一个权威定义、一个算法、一个结果」**。定义清楚原子、派生、复合三层，再把口径管理落到实处，报表之间的「对不上」就会少一大半。
📌 本文是 dwsql.com 数仓建模方法论系列「数仓分层与指标体系」第 3 篇。上篇见 数仓分层的常见误区，下篇讲 OneData/OneModel 方法论，见 OneData / OneModel 方法论解析。
「数据仓库技术」文章同步更新，不错过每一篇干货
备注「数据仓库技术」加入社群，每日一道大厂SQL真题
