数据指标平台
概述
指标是业务的"度量衡"。同一指标在不同报表里口径不一致，是数仓团队最常见的痛点。指标平台通过统一管理、统一口径、统一加工解决这一问题。本文讲透指标管理、口径定义、指标血缘与 OneData 方法论。
一、指标平台的痛点与价值
痛点：
指标口径不统一（GMV 有 3 个版本）
指标散落各处（报表/看板/接口）
指标定义靠人传（离职即丢失）
指标加工重复（同一个指标 N 处开发）| 问题 | 表现 | 后果 |
|---|---|---|
| 口径不一 | 同指标多数值 | 业务互相对不上 |
| 缺乏管理 | 指标无登记 | 找不到/重复造 |
| 加工重复 | 多处开发 | 浪费算力人力 |
| 无法追溯 | 无血缘 | 取数不敢信 |
价值：
口径统一 → 数出一门
资产沉淀 → 指标即资产
效率提升 → 定义一次复用 N 次
可信可溯 → 数据可追责二、指标基础知识
2.1 指标 vs 维度
| 概念 | 说明 | 示例 |
|---|---|---|
| 指标 | 可量化的度量 | 成交金额、订单数 |
| 维度 | 观察角度 | 时间、类目、城市 |
| 粒度 | 指标统计的明细程度 | 订单级、用户级 |
SQL 视角：
SELECT 维度, SUM(金额) FROM 事实 GROUP BY 维度
↑ 指标 ↑ 维度2.2 指标分类
| 分类 | 说明 | 示例 |
|---|---|---|
| 原子指标 | 基于明细直接计算 | 订单金额 |
| 派生指标 | 原子指标 + 修饰词 | 华北区订单金额 |
| 复合指标 | 多个指标组合运算 | 客单价 = 金额/人数 |
示例：
原子指标：交易金额
修饰词：支付成功、当日
派生指标：当日支付成功交易金额
复合指标：客单价、转化率三、指标管理
3.1 指标生命周期
需求提出 → 口径评审 → 指标登记 → 加工开发
→ 上线发布 → 日常运维 → 下线归档| 阶段 | 关键动作 | 产出 |
|---|---|---|
| 需求 | 业务提诉求 | 需求单 |
| 评审 | 统一口径 | 评审结论 |
| 登记 | 注册元数据 | 指标卡片 |
| 开发 | 数仓加工 | 指标表 |
| 发布 | 上线同步 | 指标目录 |
| 运维 | 监控告警 | 质量报告 |
3.2 指标卡片
每个指标在平台里对应一张指标卡片：
| 字段 | 说明 |
|---|---|
| 指标名称 | 业务可读名 |
| 指标编码 | 全局唯一 |
| 指标类型 | 原子/派生/复合 |
| 口径定义 | 计算公式 |
| 统计粒度 | 订单级/用户级 |
| 来源表 | 依赖的明细/汇总表 |
| 负责人 | 业务/开发责任人 |
| 状态 | 草稿/已发布/下线 |
指标编码规范（示例）：
IND + 域 + 业务 + 序号
例如 IND_TRA_GMV_001四、口径定义
4.1 口径为什么难统一
| 原因 | 说明 |
|---|---|
| 业务多样 | 各团队定义不同 |
| 隐含规则 | 口径散落在 SQL 里 |
| 无权威源 | 各做各的 |
| 变更随意 | 改了不通知 |
4.2 口径要素
一个完整口径需明确 5 个要素：
口径五要素：
1. 计算逻辑：SUM/COUNT/AVG
2. 统计范围：过滤条件
3. 统计粒度：订单/用户/日
4. 时间口径：发生时间/支付时间
5. 排除规则：退款剔除等| 示例指标 | 口径 |
|---|---|
| GMV | 支付成功订单金额之和，剔除退款 |
| 订单数 | 下单成功订单计数 |
| 活跃用户 | 当日有任意行为去重用户数 |
4.3 口径落地
开发视角：
口径定义 → 标准 SQL 模板 → 各层引用
口径变更 → 评审 + 版本管理 + 全链路通知口径必须可执行：定义给出后，可直接翻译成 SQL 模板，杜绝"口头口径"。
五、指标血缘
5.1 什么是指标血缘
指标血缘描述指标 → 汇总表 → 明细表 → 源数据的链路：
指标（GMV）
↑ 依赖
DWS 汇总表（日成交汇总）
↑ 依赖
DWD 明细表（订单明细）
↑ 依赖
ODS 源表（业务订单表）5.2 血缘的价值
| 场景 | 价值 |
|---|---|
| 影响分析 | 上游改表 → 影响哪些指标 |
| 问题排查 | 指标异常 → 定位到源 |
| 数据可信 | 可解释可追溯 |
| 成本治理 | 识别重复加工 |
5.3 血缘采集
| 方式 | 说明 |
|---|---|
| SQL 解析 | 解析加工 SQL 提取依赖 |
| 调度上报 | 任务执行时上报输入输出 |
| 元数据同步 | 引擎元数据定期拉取 |
血缘粒度：
表级血缘（表 → 表）
字段级血缘（字段 → 字段）
指标级血缘（指标 → 字段）六、OneData 方法论
6.1 定位
OneData 是阿里巴巴提出的数据中台方法论，核心是"指标原子化 + 统一管理"。它把指标体系拆解为规范、模型、标准三部分，保证从源头统一。
6.2 核心思想
OneData 核心：
数据规范（命名/编码/分层）
指标体系（原子/派生/复合）
统一标准（口径/质量/安全）| 原则 | 说明 |
|---|---|
| 全域统一 | 一个平台管所有指标 |
| 原子沉淀 | 指标按原子拆解 |
| 以数定标 | 口径有唯一出处 |
| 服务化 | 指标通过 API 输出 |
6.3 指标拆解
拆解方法：
业务过程 → 原子指标 → 修饰词 → 派生指标
订单成交 → 成交金额 → 按城市 → 华北成交金额示例拆解：
业务过程：下单、支付、退款
原子指标：下单金额、支付金额、退款金额
修饰词：时间、地区、渠道、商品类目
派生指标：支付金额 × 时间维度 = 日支付金额好处：原子指标沉淀复用，派生指标按需组合，避免指标爆炸。
七、指标体系设计实践
7.1 常用模型：OSM + AARRR
| 模型 | 说明 | 示例指标 |
|---|---|---|
| OSM | 目标-策略-度量 | 提升 GMV → 促销 → 促销转化率 |
| AARRR | 获取-激活-留存-收入-传播 | 新增、活跃、留存、ARPU、分享率 |
AARRR 指标示例：
A（获取）：新增用户、下载量
A（激活）：启动率、注册转化
R（留存）：次日/7日/30日留存
R（收入）：GMV、ARPU、付费率
R（传播）：分享率、K 因子7.2 指标体系落地步骤
步骤：
1. 梳理业务过程 → 找关键动作
2. 定义原子指标 → 统一口径
3. 搭建维度模型 → 支持任意切片
4. 派生组合 → 按角色出指标
5. 平台登记 → 卡片化沉淀| 角色 | 常用指标 |
|---|---|
| 老板 | 收入、毛利、用户规模 |
| 运营 | 转化、留存、活跃 |
| 产品 | 功能使用、渗透率 |
| 产研 | 稳定性、性能 |
7.3 指标管理规范
| 规范 | 说明 |
|---|---|
| 命名规范 | 业务域+指标+粒度 |
| 编码规范 | 唯一编码 |
| 评审规范 | 上线前口径评审 |
| 变更规范 | 变更走流程留痕 |
| 质量规范 | 上线前数据校验 |
八、指标平台架构
业务层：指标目录 / 指标检索 / 指标看板 / 指标 API
↓
管理层：指标注册 / 口径管理 / 血缘管理 / 权限管理
↓
加工层：指标引擎（自动生成 SQL）/ 调度 / 校验
↓
存储层：明细表 / 汇总表 / 指标宽表| 模块 | 职责 |
|---|---|
| 指标目录 | 检索/浏览指标 |
| 指标引擎 | 按定义生成加工任务 |
| 血缘服务 | 采集/展示血缘 |
| 校验服务 | 上线前后质量校验 |
| API 服务 | 指标数据对外输出 |
典型交互：
业务在目录找到"日支付金额"
查看口径定义与血缘
通过 API 获取数据
口径变更 → 平台自动联动加工九、常见问题与最佳实践
9.1 指标爆炸如何避免
| 手段 | 说明 |
|---|---|
| 原子化 | 只沉淀原子指标 |
| 修饰词复用 | 维度组合不重复建 |
| 收敛入口 | 指标必须走平台 |
| 定期下线 | 清理低使用指标 |
9.2 口径变更管理
最佳实践：
变更必须走评审
变更需带版本（V1/V2）
变更前通知所有使用者
变更后全链路重新校验9.3 指标质量保障
| 检查项 | 说明 |
|---|---|
| 空值率 | 核心指标不能过高 |
| 波动预警 | 环比/同比异常提醒 |
| 对账 | 与财务/业务核对 |
| 回归 | 口径变更后回归对比 |
十、小结
指标平台是数据从"能看"到"可信"的关键一环。核心路径：指标管理 → 口径统一 → 血缘可溯 → 平台落地。用好 OneData 方法论与原子化拆解，才能让指标真正成为可复用的数据资产。