数仓退化维度什么时候用？
面试怎么回答
退化维度是直接保留在事实表中的业务标识，例如订单号、发票号和运单号。它们与事实粒度强相关，常用于筛选、去重和明细钻取，但没有足够描述属性，不值得单独建维表。我会检查它是否稳定唯一、是否需要历史属性、是否会被多个主题复用；一旦属性变丰富或需要历史管理，就应考虑演进成独立维度。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
订单号需要放进事实表，用于查询和钻取，但它除了编号本身几乎没有其他描述属性。
要不要为了“维度建模完整”再建一张只有 order_id 的订单维表？
这个建模争议，正好对应一个常见问题：数仓退化维度什么时候用？
退化维度是保留在事实表中的业务标识。它有维度筛选和钻取价值，但没有足够属性值得单独建设维表。
哪些字段适合退化？
常见包括：
- 订单号
- 发票号
- 运单号
- 交易流水号
- 工单编号
这些字段通常：
- 与事实粒度强相关；
- 经常用于查询、去重或明细钻取；
- 本身缺少独立描述属性；
- 单独建表只会产生无意义 Join。
它和普通维度有什么区别？
普通维度通常有多个描述属性，例如商品维度包含名称、类目、品牌和规格，需要独立管理历史变化。
退化维度往往只有业务编号。事实表直接保留编号，就能支持：
- 按订单号定位明细
- 统计订单数
- 跨事实表核对业务单据
- 从汇总结果钻取原始业务实例
什么时候不能退化？
有丰富描述属性
如果订单存在渠道、类型、来源、标签等大量订单级属性，需要独立治理和复用，就应该考虑订单维度或其他合理模型。
需要历史变化管理
属性会变化且需要保留历史版本时，独立维表更合适。
编号不是稳定业务键
如果编号会复用、跨租户重复或生成规则变化，直接放事实表前必须补齐完整业务唯一键。
高基数字段被滥用为聚合维度
订单号适合筛选和去重，不适合直接做高频大规模 Group By。建模正确不代表任何查询方式都高效。
一个典型反例
比如为了订单号单独建 dim_order_id，表里只有代理键和订单号。
每次查询订单明细都要先把事实表 Join 这张维表，既没有补充属性，也没有降低复杂度，反而增加维护和关联成本。
直接把稳定订单号保留在订单事实表中，更符合使用方式。
但如果后续订单级属性逐渐丰富，就应该重新评估，而不是因为最初用了退化维度就永久拒绝演进。
退化维度是简化模型，不是省略业务语义。