考察点
这道题通常在总线矩阵之后出现，考的是对 Kimball 总线架构的理解深度。面试官想看的是你是否明白「为什么不同人建的表能拼在一起」，以及工程上靠什么手段保证一致性。追问常问「维度不一致出过什么事故」「一致性怎么落地管控」。
参考答案
要解决什么问题
数仓是多个团队、多个阶段增量建设出来的。下单表是交易组建的，曝光表是流量组建的，如果各自用自己的「用户」定义——交易组的用户来自订单系统、流量组的用户来自埋点设备号——那么「下单用户的曝光转化率」这种最自然的跨域分析根本没法做：两张表的用户 ID 对不上，join 出来是错的。一致性维度和一致性事实就是要消除这种「各说各话」。
一致性维度
一致性维度指被多个业务过程共享时，含义、取值、键完全统一的维度。实现上不要求物理上只有一张表，但要求语义上只有一份定义。两种形态都算一致：
- 完全相同：全公司就一张
dim_user，所有事实表都关联它； - 子集一致：某个主题用的是大维度的子集或上卷——比如「门店维度」是「组织维度」在零售主题的子集，「月维度」是「日维度」的上卷，属性和键一一对应，也叫一致。
实践中的一致性保证手段有几层。架构层：公共维度由数据中台（或指定 owner 团队）统一建设和发布，其他团队只许引用不许自建；总线矩阵评审时就确定哪些是公共维度。数据层：维表产出要有唯一性校验（主键唯一）、有权威来源声明（用户维度只认统一用户服务的数据）。流程层：新业务过程建模时，第一题就是「我的维度里哪些已有公共版本」，复用不了的才新建，新建要评审是否值得升级成公共维度。
举一个常见事故当反例：商品维度，交易域从商品中心同步，流量域从埋点日志里的商品字段反向提取，两张维表里同一个 product_id 的类目对不上（埋点上报的是旧类目）。所有「按类目看曝光-成交漏斗」的报表全是错的，而且错得无声无息——join 能成功，数不对。这就是维度不一致的代价：不是报错，是静默的错误数据。
一致性事实
一致性事实指跨业务过程、跨报表使用的度量，同名必须同义，同义必须同名。GMV 在经营周报和实时大屏里必须是一个口径：含不含未支付订单、含不含退款、按下单时间还是支付时间归集，全公司只能有一个答案。
一致性事实靠指标字典/口径管理平台落地：每个事实（原子指标）登记唯一定义——名称、业务口径、计算公式、来源表和字段、负责人口径变更要评审、要通知下游。技术上有团队更进一步：指标定义写成配置（语义层、Headless BI 的思路），报表不手写 SQL 而是引用指标，平台统一下发计算逻辑，从源头杜绝同指标多种写法。
两者是总线架构的总线
回到总线架构：它承诺「独立建设的数据集市最终能拼装成一个数仓」，兑现这个承诺靠的就是这两个一致性——维度一致，表与表才能 join；事实一致，join 出来的数才可信。所以做数仓评审时这两个问题是最尖锐的：这张新表的维度是不是都用了公共版本？这个度量指标字典里有没有，有的话口径一不一样？过不了这两关的表，建出来就是未来的烟囱。
一句话总结
一致性维度管「能不能关联」，一致性事实管「关联出来对不对」。前者靠维表统一建设加架构评审，后者靠指标字典加口径平台。它们是规范问题，但本质要技术、流程、组织一起兜：只靠文档约定没人执行，只靠平台没有 owner 维护，都会失败。
可能的追问
- 维度要做到完全一致，还是允许差异？ 允许「受控差异」：上卷和子集是一致的一部分，没问题；真正危险的是含义漂移（同名不同义）。判断标准是跨事实表 join 后结果是否业务上正确。
- 老系统遗留的多套用户 ID 怎么统一？ 建统一 ID 映射（oneid）：以登录账号为主键，把设备号、手机号、各业务线 ID 挂到同一实体下，维表同时保留各套 ID 字段，下游按需关联。这是用户域建设的常见工程。
- 指标字典推不动怎么办？ 单靠文档没人看，要让字典长在工具链里：建表、写报表必须经过指标引用校验，新口径必须在平台注册才能上线，把治理嵌进发布流程而不是靠自觉。