指标体系设计原则：原子指标与派生指标、业务总线矩阵、一致性维度与事实

好，咱们进入第二章。说实话，很多团队做指标层翻车，不是技术不行，而是设计原则没想清楚就开始建表。我见过最夸张的项目，同一个“支付金额”在三个主题域里口径都不一样——嗯，那场面，数据对不上，业务天天吵架。

这一章，我把指标体系设计的四个核心原则掰开揉碎讲清楚。你掌握了这些，后面搭指标层才不会走弯路。

2.1 原子指标与派生指标：指标的“最小颗粒度”思维

先问个问题：你建指标的时候，是直接按业务需求一个个建，还是先拆解再组合？

我个人习惯是：先定义原子指标，再基于它派生。为什么？因为业务需求会变，但最底层的度量不会变。

2.1.1 原子指标

原子指标，说白了就是不可再拆的业务度量。它通常对应一个事实表中的某个度量字段，加上业务限定条件。

举个例子：

• 交易金额（来自交易事实表的 amount 字段）
• 订单数量（对交易事实表的 order_id 做 count）
• 用户数（对用户事实表的 user_id 做 count distinct）

原子指标的定义公式很简单：

原子指标 = 业务过程 + 度量

比如“支付金额”这个原子指标，业务过程是“支付”，度量是“金额”。

2.1.2 派生指标

派生指标是在原子指标基础上，加上维度、统计周期、统计粒度后生成的。你可以理解为：原子指标是面粉，派生指标是面包、馒头、面条。

派生指标的定义公式：

派生指标 = 原子指标 + 维度 + 统计周期 + 统计粒度

看个对比表就清楚了：

2.2 业务总线矩阵：把指标和维度串起来

业务总线矩阵，这个名字听起来挺唬人。其实它就是一张二维表格，行是业务过程（事实），列是公共维度，交叉点打勾表示这个事实关联了哪些维度。

为什么要搞这个？因为指标层最怕的就是维度不一致。同一个“用户ID”，在订单表里叫 user_id，在支付表里叫 payer_id——你连表的时候就知道有多痛苦了。

下面是一个简化的业务总线矩阵示例：

你想想看，有了这张矩阵，你建指标的时候就知道：哪些维度可以共用，哪些事实可以关联。不会出现“订单金额按渠道统计”和“支付金额按渠道统计”口径打架的情况。

下面我用一张SVG图来展示业务总线矩阵的核心逻辑：

2.3 一致性维度：让所有指标“说同一种语言”

一致性维度，说白了就是同一个维度在不同事实表中长得一模一样。维度表的结构、编码、层级关系必须统一。

举个例子：

• 订单事实表中的“日期”字段，关联的是 dim_date 表
• 支付事实表中的“日期”字段，关联的也是 dim_date 表
• 两张事实表用的日期维度是同一张表，同一个主键

这样做的好处是什么？

1. 跨过程分析没问题——订单金额和支付金额按日期关联，不会出现日期对不上的情况
2. 维度属性复用——日期维度里的“是否节假日”“季度”“周数”等属性，所有事实表都能用
3. 维护成本低——改维度表一次，所有引用它的指标自动生效

2.4 一致性事实：度量口径必须统一

一致性事实，指的是同一个度量在不同事实表中的定义、计算逻辑、单位必须一致。

我遇到过最典型的反面案例：

• 订单事实表中的“金额”字段，单位是“元”，保留两位小数
• 支付事实表中的“金额”字段，单位是“分”，整数存储
• 财务事实表中的“金额”字段，单位是“万元”，保留四位小数

你想想看，三个表一关联，金额直接乱套。这就是典型的一致性事实没做好。

一致性事实的规范要求：

2.5 四个原则的关系：一张图说清楚

这四个原则不是孤立的，它们环环相扣：

• 原子指标是地基，定义最底层的度量
• 派生指标是上层建筑，基于原子指标组合出业务需要的各种指标
• 业务总线矩阵是骨架，把事实和维度的关系固定下来
• 一致性维度与事实是血液，确保所有指标在同一个体系里流通

少了任何一个，指标体系都会出问题。我见过太多团队只关注“怎么算指标”，不关注“怎么定义指标”，结果就是数据越做越乱，最后推倒重来。