Kimball架构数据仓库中共享维度表的物理存放位置如何规划？

首先明确核心原则：你做维度最大化复用的底层基础是一致维度的全局唯一性，所有物理架构设计都要优先保障这个前提，再权衡运维、性能成本。

你提到的两种方案里，直接把维度同步到各数据集市独立存放的方式完全不可取，本质是制造维度副本孤岛，问题非常明确：

• 只要出现一次同步延迟、字段更新漏同步、口径调整没覆盖全副本，不同集市用同一个维度算出来的指标就会对不上，直接击穿数仓的指标可信度
• 运维成本会随集市数量线性上涨：比如用户维度新增一个「最近30天消费等级」字段，你需要给所有用到这个维度的集市挨个跑同步任务、做数据校验，漏一个就会出数据事故
• 根本实现不了真正的维度复用，各个集市用的只是维度的拷贝，不是同一个维度实体，后续做集市间的指标下钻、联动会处处是问题。

推荐采用「共享维度统一存放到独立库专属Schema」的方案，这也是Kimball总线架构的标准落地方式，落地时注意几个细节就能避开大部分坑：

• 存放公共维度的数据库不要存任何事实表，权限上仅给各数据集市的开发/运行账号开放维度表的只读权限，从流程上避免集市侧私自修改维度结构、篡改维度数据，保障维度的全局一致
• 不用过度担心跨库查询性能问题：当前主流的MPP数仓、云原生数仓，同实例下跨库/Schema关联查询的性能和同库关联几乎没有差异，没必要为了这点可以忽略的性能开销牺牲维度一致性
• 不需要把所有维度都放到公共库：如果某个维度是单个数据集市专属的私有维度（比如仅某个运营集市会用到的活动专属标签维度，永远不会被其他集市复用），直接存放在对应集市库内即可，不用强行放到公共维度库增加运维成本。

如果你们当前用的数仓引擎跨库访问对业务用户不友好，也不用做物理副本同步，可以在各集市库下建一层指向公共维度表的视图，上层用户访问时和同库表没有体验差异，也不会出现多副本不一致的问题，视图参考写法：

-- 示例：在电商数据集市库下创建公共用户维度的映射视图
CREATE VIEW dim_user AS
SELECT * FROM dimensions.dim_schema.dim_user;

内容的提问来源于stack exchange，提问作者skyline01