Data Vault 的 Hub、Link 和 Satellite 怎么设计？
面试怎么回答
Data Vault 把稳定业务键、实体关系和可变属性分别建成 Hub、Link、Satellite。Hub 保持身份稳定，Link 固化关系粒度，Satellite 用加载时间、来源和哈希差异保存历史。它适合多源快速接入和强审计场景，但表数量多、查询链路长，所以我会把 Raw Vault 当可追溯底座，再通过 Business Vault 和维度模型向消费侧交付。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
源系统一天一个版本，字段反复改，历史又不能丢。
如果所有变化都塞进一张宽表，维护成本很快超过查询成本。
Data Vault 用 Hub 管业务键、Link 管关系、Satellite 管可变属性和历史，适合强调可追溯与持续接入的场景。
Hub 管身份，不管会变化的描述
Hub 保存客户号、订单号等稳定业务键，以及加载时间、记录来源和用于连接的代理键或哈希键。客户姓名、等级、地址会变化，不应直接塞进 Hub。业务键选错，后续 Link 和 Satellite 都会失去稳定锚点。
Link 管关系和业务事件
Link 连接两个或多个 Hub，例如客户与订单、订单与商品。它描述关系曾经发生过，而不是把双方全部属性复制一遍。对于交易明细类关系，还要明确关系粒度，避免同一业务事件因为键不完整而被错误合并。
Satellite 管属性和变化历史
Satellite 依附于 Hub 或 Link，保存描述属性、加载时间、来源、有效时间和变化检测信息。不同变化频率、不同来源或不同安全等级的属性可以拆成多个 Satellite，减少无关字段一起变更造成的放大。
Raw Vault 不等于最终消费层
Raw Vault 优先保留来源事实和审计链路，规则较少、模型稳定；Business Vault 可以增加业务规则、派生关系和计算；最终仍常构建星型模型、宽表或语义层服务报表。让 BI 直接跨大量 Hub、Link、Satellite 查询，往往会把接入灵活性转成消费复杂度。
一个典型场景
客户信息来自 CRM、支付和客服三个系统，客户等级和联系方式更新频率不同。可以用统一客户业务键建立 Hub，来源间的映射关系进入 Link，各系统属性进入独立 Satellite。出现数据争议时，可以沿 load_time 和 record_source 回溯，而不必覆盖旧值。
参考资料
- Data Vault Alliance 方法概览：https://datavaultalliance.com/news/dv/dv2