Data Vault 建模要点
Data Vault 用三类表表达企业数据：Hub 存业务键（客户号、订单号），只保留键与加载信息；Link 表达实体之间的关系（订单属于哪个客户）；Satellite 存描述属性与变更历史（名称、城市、等级及其生效时间）。它的优势是结构可扩展、加载可并行、插入即可（不更新既有行），适合多源接入与频繁变更的集成场景；代价是查询要写多层连接，对外服务时通常再叠加一层星型集市或宽表。
基本信息
| Hub | 业务键加加载时间与来源，每类实体一个 |
|---|---|
| Link | 两个或多个 Hub 之间的关系 |
| Satellite | 描述属性加生效时间，承载变更历史 |
| 加载特性 | 以插入为主、可并行，天然保留历史 |
| 使用方式 | 作为集成层，对外再建维度模型或宽表 |
典型使用场景
- 多源系统整合：同一客户在不同系统有不同编号，需要统一业务键
- 频繁结构变更：源系统经常新增字段，用 Satellite 扩展而不影响既有结构
- 审计要求高：需要保留每一次属性变更与来源信息
- 并行加载：多个批次同时入库而不互相锁等待
- 迁移过渡：从旧数仓迁移期间作为统一集成层
结构示意
结构示意
-- Hub：只放业务键与加载信息
hub_customer (customer_hk, customer_id, load_dts, src)
-- Link：表达实体之间关系
link_order_cust (order_hk, customer_hk, load_dts)
-- Satellite：描述属性与生效时间，变更即插入新行
sat_customer (customer_hk, load_dts, name, city, level)
-- 查询当前属性：取每个键最新的加载时间
SELECT c.customer_id, s.name, s.city, s.level
FROM hub_customer c
JOIN sat_customer s ON c.customer_hk = s.customer_hk
QUALIFY ROW_NUMBER() OVER (PARTITION BY c.customer_hk ORDER BY s.load_dts DESC) = 1;三类表分工
| 表类型 | 存什么 | 是否更新 | 常见问题 |
|---|---|---|---|
| Hub | 业务键与来源 | 不更新，只插入 | 业务键清洗规则不统一 |
| Link | 实体间关系 | 只插入 | 关系重复插入需去重 |
| Satellite | 描述属性加时间 | 只插入 | 加载时间口径需统一 |
| 对外层 | 星型或宽表 | 按需覆盖 | 加工逻辑需可追溯 |
Data Vault 适合多源接入、频繁变更的企业集成场景；数据量与人手有限时，直接建星型模型更省事，不必为了方法论而增加复杂度。
直接用 Data Vault 表对外提供分析，查询要写多层连接，使用者难以正确取到“当前最新属性”，容易出现口径错误。
Hub 与 Satellite 的加载时间口径不一致时，按时间点回溯会出现空洞：某个时点能查到键却查不到属性，回溯结论不可信。