数仓一致性维度怎么设计？
面试怎么回答
一致性维度用于让多个事实表和数据集市共享可对齐的业务语义。我会统一维度定义、主键映射、属性值域、层级和历史变化策略，再通过主键唯一、映射完整、孤儿键和生效时间检查保证质量。它不一定要求所有主题共用一张物理表，但必须遵守同一套维度契约，才能支持跨主题钻取和指标比较。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
业务提出一个看似简单的要求：订单、广告、用户三个主题的报表，都要按同一套渠道、地区和用户类型进行分析。
真正合表后却发现，同一个“新用户”有三种口径，同一个渠道在不同主题里编码也不一致，跨主题指标根本无法直接比较。
这就是一致性维度要解决的问题：让多个事实表和数据集市使用可复用、可对齐的维度语义。
一致的到底是什么？
一致性维度不只是“大家都关联一张维表”，至少要统一五件事：
- 业务定义：新用户、自然量、付费渠道分别怎么判断
- 标识体系：不同系统的用户 ID、商品 ID 如何映射成统一主键
- 属性口径：地区、渠道、品类等属性来自哪里
- 层级关系：国家—区域、品类—大类等汇总路径是否一致
- 历史语义：属性变化后，查当前值还是保留事实发生时的值
只有表名相同，但字段含义、时间边界和历史策略不同，仍然不能算真正一致。
不一定非要共用一张物理表
一致性首先是语义和契约一致，其次才是物理实现。
条件允许时，可以建设全局共享维度，让多个事实表引用同一套代理键和属性。系统边界复杂时，也可以保留主题内的物理维表，但必须通过统一主数据、映射关系、编码规范和版本规则保证可对齐。
设计一致性维度的五个步骤
第一步：先定业务定义和负责人
明确维度服务哪些业务过程、每个属性的业务含义、来源系统和口径负责人。口径争议应该在建模阶段解决，而不是留给报表临时解释。
第二步：建立统一键和映射关系
一个业务对象可能在 CRM、交易、广告平台有不同编码。需要维护源系统自然键到统一键的映射，并处理一对多、合并、拆分和未知成员。
第三步：统一属性和层级
字段名称相同不代表含义相同。要明确标准值域、层级路径、空值和默认值处理，避免各主题自行翻译。
第四步：统一历史变化策略
哪些属性覆盖更新，哪些属性使用 SCD2 保留历史，事实表关联的是当前维度还是发生时版本，都要写进模型契约。
第五步：建立质量和变更机制
至少监控主键唯一、映射完整、孤儿键、值域异常和生效时间重叠。维度定义变更时，还要评估所有下游事实表和指标是否需要回刷。
一个典型反例
订单主题按“首次下单日”定义新用户，用户主题按“注册日”定义新用户，广告主题又按“首次激活日”定义新用户。
三张表都有 is_new_user，但放在一起对数时永远对不上。
正确做法不是强行让某张表覆盖其他表，而是先确认业务问题：分析注册新增、激活新增还是首购新增。必要时保留多个明确命名的属性，而不是让一个模糊字段承担三种含义。
一致性维度的价值，不是少建几张表，而是让跨业务过程的指标能够被同一组维度正确切分和比较。