两类建模方法论
Data Vault 面向集成与审计：用 Hub、Link、Satellite 把业务键、关系和描述属性分开存放，天然支持多源接入、并行加载与全量历史追踪。Kimball 维度建模面向分析体验：星型结构直接服务报表与自助查询，交付快、易理解。两者不是二选一的信仰问题，常见的成熟做法是分层组合——Vault 承担集成层，维度模型承担集市层，各管一段。
基本信息
| Data Vault 强项 | 多源接入、可审计、并行加载、历史完整 |
|---|---|
| 维度模型强项 | 面向分析、易用、交付速度快 |
| 组合形态 | Vault 做集成层，维度化 DWS/ADS 做集市层 |
| 选择依据 | 数据源数量、审计要求、交付节奏三者权衡 |
典型使用场景
- 多源合并且源系统频繁上新：Vault 的 Hub 按业务键去重，接入新源不动存量结构
- 强审计行业（金融、医疗）：需要逐条还原变更，Satellite 天然保留全量历史
- 交付节奏紧张的业务集市：直接维度建模，用最短路径产出可分析的宽表
- 组合落地：Vault 保证集成层稳定，集市层按主题重刷而不影响上游
- 方法论评审：用取舍清单统一团队认知，避免两派各写一套表
分层组合示意
分层组合示意
源系统（CRM / 订单 / 支付） # 多源异构接入
-> 贴源层 STG # 只做格式统一，不做业务加工
-> Data Vault 集成层 # Hub 存业务键、Link 存关系、Sat 存属性与历史
-> 维度化集市层 DWS/ADS # 星型模型，面向报表与自助分析
边界约定：Vault 层不直接对外供 BI 查询，避免使用者直面 Hub/Sat 结构取舍对照
| 判断项 | 选 Data Vault | 选维度模型 |
|---|---|---|
| 数据源数量 | 源多且持续新增 | 源少且相对稳定 |
| 审计要求 | 需要逐条变更可追溯 | 以分析结论为主 |
| 交付节奏 | 可接受较长建设期 | 要求快速产出可用宽表 |
| 使用者 | 数仓工程师维护集成 | 业务与分析师直接查询 |
组合方案成败的关键是明确边界。集成层如果允许业务直接查询，Vault 的多表结构会把复杂度原样暴露给使用者，等于同时承担了两套方法的缺点。
团队能力是常被忽略的约束：只熟悉其中一套方法时，另一套结构的维护质量会在半年内明显下滑，选型时要把培训成本算进去。