Data Vault 解决什么问题
Data Vault 用 Hub、Link、Satellite 三类对象组织数据：Hub 存业务键，Link 存实体之间的关系，Satellite 存描述属性与历史。它把「同一件事的稳定标识」与「属性的历史变化」彻底分开，因此天然支持多源整合、并行加载与逐条追溯来源。
基本信息
| Hub | 业务键去重 + 代理键（常用 hash 生成） |
|---|---|
| Link | 实体间关系，只存键，不存描述 |
| Satellite | 描述属性与历史，按源或变更节奏拆分 |
| 附加字段 | hash key、load_dts、record_source、hashdiff |
| 适用场景 | 多源整合、强审计、频繁新增源系统 |
典型使用场景
- 多源整合：同一客户在 CRM、ERP、订单系统各有标识，需要长期合并而不丢来源
- 审计与合规：每条记录都要能回答来自哪个系统、什么时候进入仓库
- 源系统频繁新增：新增一个源只需加 Hub、Link 或 Satellite，不动既有结构
- 并行加载：按对象分片加载，互不阻塞，吞吐可线性扩展
- 需要重放：原始与历史完整保留，可回溯到任意时点重算
三类对象示意
三类对象示意
-- Hub：只存业务键与加载信息，同一业务键只出现一次
hub_customer(hub_customer_key, cust_id, load_dts, record_source)
-- Link：只存关系，两个 Hub 的键加加载信息
link_order_customer(link_key, hub_order_key, hub_customer_key, load_dts)
-- Satellite：属性与历史，按源拆分，hashdiff 用于变更检测
sat_customer_crm(hub_customer_key, load_dts, name, level, hashdiff)
-- 取某客户当前最新属性：从 Satellite 里按加载时间取第一行
SELECT * FROM sat_customer_crm
WHERE hub_customer_key = :hk
ORDER BY load_dts DESC LIMIT 1;对象职责读法
| 对象 | 存什么 | 不存什么 |
|---|---|---|
| Hub | 业务键、代理键、来源与加载时间 | 任何描述属性 |
| Link | 实体间关系的键组合 | 描述属性、度量 |
| Satellite | 属性值、历史版本、变更标记 | 关系的键组合 |
| hash key | 由业务键计算出的代理键 | 业务含义，仅用于关联 |
Data Vault 的可审计与可并行是有代价的：查询一张完整的客户视图要关联多个 Hub、Link 与 Satellite。它的定位是集成层，面向分析仍需要在上层做维度化加工，直接把它交给 BI 使用通常会被 join 复杂度劝退。
hash key 的算法与输入必须在全仓统一（例如统一是否大写、是否拼接来源标识），算法不一致会导致本该相同的业务键算出不同哈希，join 结果静默出错，排查成本极高。