Data Vault无强外键场景下如何创建用户与Lead的LINK关联

你的核心思路方向正确，Call实体必须建模为Hub，关联逻辑可按分层原则处理，具体方案如下：

• 首先明确Data Vault各对象的定位：
  Hub是存储独立业务实体唯一业务键的核心对象，Call本身有全局唯一的业务标识CallId，属于独立业务实体，完全符合Hub的定义，不能作为Link使用（Link仅用于描述多个Hub之间的关联关系，本身没有独立的业务主键）。
• 原始层（Raw Data Vault）建模结构：
  1. 新建3个核心Hub：
  • Hub_User：业务键为UserId，关联Satellite存储Username、Email等属性
  • Hub_Lead：业务键为LeadId，关联Satellite存储标准化后的PrimaryContactNumber、SecondaryContactNumber等属性
  • Hub_Call：业务键为CallId，关联Satellite存储标准化后的CalleeNumber、CallerNumber、Duration等通话属性
  2. 新建2个Link：
  • Link_User_Call：关联Hub_User和Hub_Call，可直接通过通话数据自带的UserId+CallId生成，无需推断
  • Link_Call_Lead：关联Hub_Call和Hub_Lead，基于标准化后的被叫号码与Lead主/次联系号的匹配规则生成关联，同时在该Link对应的Satellite中新增match_type字段，标记当前关联是匹配主号码还是次号码，便于后续追溯
• 号码匹配逻辑的分层处理：
  优先在Staging层完成所有号码的标准化清洗：统一去除国家码前缀、特殊符号、空格，避免格式导致的匹配误差。如果匹配规则稳定，可直接在Raw Data Vault层生成Link_Call_Lead的关联记录；如果匹配规则迭代频繁，可把匹配逻辑放到业务层（Business Data Vault）处理，Raw层只留存原始数据，规则变更时仅需重刷业务层即可，无需改动原始数据。
• 多匹配场景的处理：
  如果出现同一个被叫号码对应多个Lead的情况，Raw层不要提前做过滤删除，要把所有可能的关联都存入Link_Call_Lead，等到数据集市（Datamart）层再根据业务规则（比如Lead归属销售、创建时间、最近交互记录等）筛选出最合理的关联，或者直接把多匹配结果暴露给业务方自行判断，避免原始层丢失有效数据。

不建议把号码匹配和关联逻辑全部放到Datamart阶段处理：Raw层提前构建关联可避免每次Datamart计算都重复执行匹配逻辑，同时Data Vault的Satellite快照能力可留存历史匹配记录，后续Lead联系号更新时也能追溯历史关联的正确性，可追溯性和计算效率都远优于在Datamart层才处理的方案。

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