指标混进维度是什么
这个反模式指把累计消费金额、近 30 天活跃天数、订单数这类每天都在变的度量当成属性放进维度表。后果有三层：维表被迫每天全量重刷、行宽与体积膨胀；一旦纳入 SCD 跟踪，拉链表会随指标变化天天产生新版本；更隐蔽的是指标口径藏在维表里，没人做对账。维度的边界是描述性属性，度量属于事实表或指标层。
基本信息
| 正确边界 | 维度放描述属性，事实放可加度量 |
|---|---|
| 典型症状 | 维表每日全量更新、体积持续膨胀 |
| 常被塞入 | 近 30 天订单数、累计消费额、活跃天数、最近登录时间 |
| 直接后果 | 拉链版本数量爆炸，维表失去稳定性 |
| 判定问句 | 这个属性是否每天都会变；变了是否影响历史口径 |
典型使用场景
- 现象识别：dim_user 里出现 order_cnt_30d、last_pay_amt 这类每日刷新的字段
- 设计评审：把「是否混入指标列」列为评审必查项，发现即要求移出
- 存量整改：指标列迁到事实或指标层，维表只保留稳定属性与分群标签
- 性能治理：维表日更行数过大，导致下游所有 join 变慢
- 口径治理：同一指标在维表与指标层取数不一致时，统一收敛到指标层
- 拉链保护：跟踪属性里混入指标，会让每批数据都开新版本
反模式与正解
反模式与正解
-- 反模式：把每日变化的指标塞进维表，每天全量重刷
dim_user -- user_id, name, city, order_cnt_30d, gmv_30d, active_days_7d
-- 正解一：留在事实或汇总事实表，按日期切片
fact_user_daily -- dt, user_sk, order_cnt, gmv, is_active
-- 正解二：确有稳定分群含义时，用离散标签代替原始指标
dim_user -- user_id, name, city, value_tier -- 高价值/中/低，按批次更新字段归属判断
| 字段 | 归属 | 理由 |
|---|---|---|
| name、city、注册渠道 | 维度（维表） | 描述性属性，低频变化 |
| 总消费金额 | 事实或指标层 | 每日变化、可加，需要按时间切片 |
| 近 30 天订单数 | 指标层 | 时间窗口型指标，本质是滚动计算 |
| 价值分层标签 | 维度（打标维表） | 按批次生成，可版本化且取值离散 |
| 最近一次登录时间 | 事实或打标维表 | 高频变化，放维表会天天开新版本 |
区分维度属性与指标，最简单的判据是问「这个属性变化时，已经发生的事实是否应该跟着改口径」。描述属性变了只影响后续分析；指标变了说明口径随时间滚动，它就该住在事实或指标层，而不是被冻在维表的某个版本里。