在后合并场景中建立单一真实来源需要采用领域驱动设计的数据治理方法，而不是立即进行物理合并。实施一种联合主数据管理 (MDM) 体系架构，采用事件驱动的复制策略，利用变更数据捕获 (CDC) 机制从每个子公司的CRM流式传输修改到中央Apache Kafka集群。这通过增量收敛创建了一个“黄金记录”仓库，允许遗留系统在标准模型成熟的同时保持运行。
通过API 网关实施攀爬无花果模式，拦截客户数据请求，将读取路由到新兴的MDM中心，同时逐步迁移写入。这种方法满足了六个月的监管期限，通过从中心提供即时报告能力，同时董事会的零停机制约通过异步同步得到满足，永远不会冻结源数据库。
背景。 一家私人股权公司收购了五家区域物流公司，以形成国家承运商，每家公司都运行各自独特的CRM平台。西部部门使用高度定制的Salesforce，中西部使用带有专有插件的遗留Microsoft Dynamics 365，东南部使用SAP Sales Cloud，东北部依赖于基于MySQL的自定义Ruby on Rails应用程序，而西南部操作具有复杂Zoho Creator扩展的Zoho CRM。监管机构要求在180天内进行统一的客户尽职调查 (CDD) 报告，以符合反洗钱 (AML) 合规要求，而董事会明确禁止任何会违反现有**99.9%**的正常运营水平协议 (SLA) 的操作停机。
问题。 在五个生态系统之间没有共同的唯一标识符；Salesforce使用18字符ID，Dynamics采用GUID，而自定义Rails应用依赖于自增整数。数据质量差异显著，部分子公司将地址存储为非结构化文本，而其他子公司则保持规范化模式。传统的提取-转换-加载 (ETL) 批量迁移在切换期间需要冻结数据，这在24/7的调度操作以及服务中断的合同罚款情况下是不可行的。
解决方案1：大爆炸迁移。 该策略建议在一个完整的周末进行全面的切换，所有五个遗留系统将同时将其客户数据集导出到中心Snowflake数据仓库。在此窗口期间，复杂的转化逻辑将标准化模式并去重，然后将清理后的数据与新的统一Salesforce实例同步。这种方法承诺立即消除技术债务，但在迁移窗口期间需要完全冻结系统。
优点： 立即消除技术债务；简化长期维护；单一供应商关系以提供支持。
缺点： 同时暴露所有五个收入流的风险；如果同步失败，灾难性的回滚复杂性；直接违反董事会不可谈判的零停机约束；如果48小时窗口不足以处理超过200万个记录数据集，可能会造成数据丢失。
裁决： 由于不可接受的业务连续性风险被拒绝。
解决方案2：虚拟数据联邦层。 该替代方案建议使用Denodo或TIBCO数据虚拟化实施中间件，以创建一个实时抽象层，聚合数据而无需物理合并。虚拟化层将向报告工具提供统一视图，同时保持实际数据在源CRM平台中，有效地创建逻辑数据仓库。虽然这避免了数据移动，但它完全依赖于网络稳定性和源系统可用性来满足每个查询。
优点： 对现有用户工作流没有操作中断；即时合规报告能力；不需要对子公司员工进行重新培训。
缺点： 在高峰早晨调度期间，由于跨系统联接导致严重查询性能下降；地区间网络延迟导致报告超时；未能解决潜在的数据质量问题或重复客户记录；创造了永久技术债务而非架构解决方案。
裁决： 被拒绝作为永久解决方案，但在前90天内保留作为临时合规桥梁。
解决方案3：增量基于领域的整合与事件源。 这种混合方法使用Informatica MDM建立中心MDM中心，部署CDC代理，如Debezium用于MySQL和Salesforce及Dynamics的原生流式API。这些代理将所有数据修改流式传输到Apache Kafka集群，Apache Spark MLlib进行概率匹配，以识别子公司间的重复记录并创建遗留记录。该架构使用AWS DMS（数据库迁移服务）写后模式，以保持与遗留系统的兼容性，同时逐步迁移业务流程以从黄金记录API中获取数据。
优点： 通过一次迁移一个子公司来实现风险隔离；通过异步同步保持100%正常运行时间；并行运行能力进行验证；通过中心实现合规，同时保持操作独立。
缺点： 初始基础设施成本较高；维护双重系统的临时复杂性；潜在的双向同步冲突需要人工干预。
选择的解决方案和理由。 我们选择了解决方案3，因为它独特地平衡了激进的监管截止日期和不可谈判的操作约束。我们优先考虑前两个最大的子公司进行第一阶段，利用Kafka的日志压缩功能来保持不可变事件历史，允许操作团队重播任何同步错误而不丢失数据。MDM中心成为所有新客户注册的记录系统，而AWS DMS将这些变更传回遗留接口，确保用户能够继续使用熟悉的工作流，而数据在其下方收敛。
结果。 在五个月内完成整合，期间任何子公司均未出现计划外停机。来自MDM中心生成的AML合规报告顺利通过监管审计，未出现例外。通过匹配算法，重复客户记录减少了73%，并且由于最终统一的客户可见性，第一季度交叉销售收入增加了18%。
当两个子公司为同一客户声称不同的信用额度时，你如何解决冲突数据所有权？这两个值在各自的地区合同下都合法。
这种情况考验对双时态数据建模和上下文化黄金记录的理解。与其通过破坏性合并强制单一值，MDM必须实施多值属性，保留两个信用额度及其有效期和法律实体上下文。该解决方案需建立一个由各子公司代表组成的数据治理委员会，以定义优先级规则——例如，“对于企业风险评估，适用最严格的限制”——同时保持两个原始值以供子公司特定的报告。技术上，这涉及为规范模型添加管辖权和合同有效性元数据字段，确保系统能够呈现企业视图（保守风险暴露）和子公司视图（合同义务）而不损失数据。
在将具有外键约束的关系数据库合并到最终一致的事件驱动架构使用Apache Kafka时，如何确保引用完整性？
候选人常常忽视事务边界分析和Saga模式。当业务操作跨多个子公司时——例如，更新部分存在于Salesforce、部分存在于SAP的客户公司层次结构——BA必须设计补偿交易。如果Salesforce的更新成功但SAP的更新失败，系统必须发布补偿回滚事件以保持一致性。这需要在MDM中心实施Saga orchestrators，以管理跨Kafka主题的分布式交易。此外，在事件架构中加入向量时钟或Lamport时间戳允许在子公司同时更新同一实体时检测因果关系违规，从而根据业务规则（例如“最后时间戳优先”或“收入最高的子公司优先”）进行冲突解决。
在并行运行期间，如何验证数据准确性，而不增加需要在两个遗留CRM系统和新的MDM中心中确认记录的业务用户的手动验证工作量？
这解决了在零停机迁移中固有的验证悖论。解决方案涉及合成事务监控和统计数据指纹而非手动对账。使用Great Expectations或Deequ等框架实施自动校验和比较，以生成源系统和目标系统中数据分布的统计概况。对于关键字段，如税务识别号码，部署确定性匹配和自动异常报告。BA应定义容忍阈值——接受非关键字段的99.5%匹配率，同时要求财务标识符的100%准确性——并在Tableau或Power BI中实施数据质量仪表板，实时突出显示异常，使用户仅关注显著的差异。