数据仓库collateral维度多来源新增数据接入最优方案咨询

方案对比 #

方案1：直接扩展现有dimCollateral维度 #

仅适合新增属性为全量抵押品通用核心属性、后续无高频新增数据源的场景。

• 优势：下游取数无需关联多表，查询逻辑简单、性能高
• 劣势：每次新增属性都要修改核心维度表结构、回溯全量历史数据，对银行这类后续会持续接入新数据源的场景，维护成本极高，还会影响已基于现有维度开发的报表、风控模型的稳定性，完全不适合你的业务现状。

方案2：新建独立扩展维度 #

完全匹配你当前的银行多源迭代场景。

• 优势：无需改动现有核心维度结构，对已有下游业务零影响，后续接入新数据源时仅需新增对应扩展表即可，迭代成本极低
• 劣势：需要统一关联规则，下游取数如果直接查底层表需要关联核心维度和扩展维度，容易出现关联错误，这个问题可以通过上层封装视图解决。

最优落地方案 #

采用核心通用维度+来源专属扩展维度的雪花型设计，具体规则如下：

1. 核心dimCollateral仅保留所有数据源共有的通用属性，比如抵押品全局唯一ID、抵押品分类、登记日期、所属机构、数据源标识等全量抵押品都有值的字段，保持核心维度的稳定性，非必要不调整结构。
2. 本次新增遗留系统的属性单独建dimCollateralLegacy扩展表，关联键统一使用collateral_surrogate_key（抵押品代理键）+effective_date（生效日期），兼容缓慢变化维度的历史数据存储需求，扩展表的字段统一加来源前缀（比如leg_xxx），避免和其他来源的同名字段冲突。
3. 后续接入新的抵押品数据源时，直接新增对应来源的扩展维度即可，不需要改动现有表结构。如果后续发现多个扩展表中有通用度极高的字段，再定期将这类字段下沉到核心维度。
4. 在上层封装一个公共视图vdimCollateralFull，自动关联核心维度和所有已有的扩展维度，下游分析师需要全量抵押品属性时直接查询视图即可，不需要自行写关联逻辑，避免出错。

注意事项 #

• 所有扩展表和核心维度的映射关系必须是1:1或者1:0（部分抵押品无对应扩展属性），严格禁止出现1:N的映射，避免关联后数据行数膨胀。
• 扩展维度要和核心维度走统一的缓慢变化维度处理逻辑，保证历史数据的时间一致性。

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