同一业务流程双源系统的维度建模设计考量咨询

核心对齐Kimball方法论的调整思路 #

1. 锚定业务驱动的统一粒度 #

跳过迁就系统原生粒度的误区，直接从财务团队的分析需求（比如比率指标的计算粒度是采购订单级还是行项目级）出发，定义唯一的目标业务粒度。所有后续的模型设计都围绕这个粒度展开：

• 若遗留系统粒度粗（如订单汇总），需拆分到目标粒度（可通过关联遗留系统的明细补充表或填充合理默认值实现）
• 若新系统粒度更细，可按目标粒度做聚合转换

2. 强制构建一致性维度 #

严格遵循Kimball的"单一版本真相"原则，针对供应商、物料、组织、日期等核心维度，只构建一套一致性维度表：

• 提取两套系统维度的共同属性作为核心字段，补充业务必需的扩展属性
• 处理维度编码差异：通过ETL建立跨系统维度映射，用代理键统一标识（比如遗留系统供应商IDS001和新系统1001映射到同一代理键1）
• 缓慢变化维度（SCD）处理：以业务认可的权威来源（优先新系统）为基准，同步遗留系统的历史维度属性，保证维度属性的一致性

两种方案的优劣势与落地建议 #

方案1：两套独立维度模型 #

• 优势：开发周期短，无需处理复杂的跨系统映射，适合临时满足单一系统的分析需求
• 劣势：无法直接生成跨系统比率指标，业务团队需手动整合数据，长期维护成本高，违背数据仓库的核心价值
• 适用场景：仅需单独分析历史或当前数据的过渡阶段，不推荐作为长期架构

方案2：单一维度模型+独立事实表（推荐） #

这是符合Kimball理念的长期最优方案，具体实施要点：

• 基于统一的一致性维度层，为两套系统分别创建事实表，保证事实表粒度与目标业务粒度完全一致
• 在每套事实表中新增source_system字段（如legacy/modern），用于标识数据来源，方便跨系统筛选和计算
• 标准化事实指标：针对同一业务指标（如订单金额），统一计算规则（比如统一为含税金额），ETL阶段完成转换，可保留原始值用于溯源，同时存储标准化值用于分析
• 可选构建整合事实视图：将两套事实表按统一粒度union，封装跨系统整合逻辑，供业务团队直接使用

关键细节处理 #

• 缺失数据补全：遗留系统缺失的维度属性（如物料分类），通过业务规则映射或人工补全填充，确保一致性维度的完整性
• 指标一致性验证：选取样本数据，对比跨系统整合前后的比率指标计算结果，确保数据准确
• ETL流程隔离：两套系统的ETL流程独立开发，但维度层的更新需保证原子性，避免一致性维度出现数据不一致

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