基于Data Vault建模INFORMATION_SCHEMA实现数据血缘的方案咨询

列HUB业务键选型 #

列本身的唯一业务标识就是全限定名称，直接用数据库名.模式名.表名.列名的组合作为HUB_COLUMN的业务键即可，天然解决同名列的唯一识别问题。如果觉得字符串过长不适合做关联键，可对该全限定名字符串做哈希（如MD5、SHA256）生成HUB的代理主键，业务键字段仍存储原始全限定名，方便后续匹配、排查问题。

多活动卫星存储列的方案不可行原因 #

列是元数据建模中的核心独立实体，而非表的附属属性，你要实现的列级数据血缘必然涉及跨表、跨库的列映射关联，卫星表本身不支持关联其他核心实体构建LINK，因此必须单独构建HUB_COLUMN，不要尝试用多活动卫星存储列信息。

DB -> SCHEMA -> TABLE -> COLUMN 嵌套结构的Data Vault建模最佳实践 #

• 所有层级核心实体单独构建HUB，各HUB业务键均对应自身全限定名：
  • HUB_DB业务键：数据库实例/集群唯一标识
  • HUB_SCHEMA业务键：数据库名.模式名
  • HUB_TABLE业务键：数据库名.模式名.表名
  • HUB_COLUMN业务键：数据库名.模式名.表名.列名
• 层级依赖关系用LINK表存储：
  分别构建LINK_DB_SCHEMA（关联HUB_DB和HUB_SCHEMA）、LINK_SCHEMA_TABLE（关联HUB_SCHEMA和HUB_TABLE）、LINK_TABLE_COLUMN（关联HUB_TABLE和HUB_COLUMN）。如果需要记录层级关系的生命周期（如表迁移、列删除等变更），可给对应LINK表添加附属卫星，存储生效时间、失效时间、操作人等变更属性。
• 血缘关系单独构建LINK表：
  表级血缘构建LINK_TABLE_LINEAGE关联源表和目标表HUB，列级血缘构建LINK_COLUMN_LINEAGE关联源列和目标列HUB。给血缘LINK添加附属卫星，存储转换公式、ETL任务ID、执行时间、血缘可信度等属性即可满足血缘追溯需求。
• 实体属性统一存储到对应HUB的附属卫星：
  列的描述、数据类型、长度、是否主键、业务含义等属性存储到SAT_COLUMN；表的描述、创建时间、所属业务域等属性存储到SAT_TABLE，不要跨实体存储属性。

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