案例2：教工数据的实时同步

高校B在疫情期间，建设线上教职工每日健康信息上报的运用，要求运用建设方从开放平台中获取人员相关数据，但由于事业部门对人员状态、手机号等维护工作的不准确，导致很多教职工反馈自己无法填报或手机号码错误，信息部门也想借此机会提升数据质量，但是疲于跟事业部门交流、跟反馈问题的教职工沟通，无法抽身专心于数据问题本身，导致忙中出乱，连本职的同步数据的工作也出现问题，进而扩展对立，造成事业部门和教职工用户两边都不讨好的局势。

针对于这个场景，我们发现主要矛盾会集中在左面的部分，数据交流采取了全表对比的方式。那么，咱们可以通过转发代替更换解决问题吗？还是仍然通过全量和增量的转化？

案例2与案例1的最大差异在于，所要共享的数据既非单一来自于人事体系，也非单一来自于教务系统，而是对两个数据库的多张表进行了转化，最终形成了需求共享的教职工基本信息数据。然而，转化的计划是无法解决跨库、异构场景问题的，所以咱们无法使用转化的计划解决案例2的问题。

那么根据时刻戳的增量处理计划可行吗？也不可，原因是人事、教务体系关于人员的数据表没有时刻戳字段。那还有其他的增量数据同步的计划么？

结合校园运用ODI作为ETL东西的实际情况，咱们能够直接使用ODI中的同步CDC方法，使用触发器的原理来识别变化数据，减少数据交流量，做到数据的高实时同步。咱们来看一下ODI同步CDC的实现原理及过程。

除了同步CDC方式，ODI中还提供了一种异步CDC模式，是一种基于日志识别变化数据的增量交换模式。但只有ODI企业版中才有，需单独购买。基于日志的CDC需要的权限较高，甚至要求源库开启最小补全日志、归档日志及强制归档模式，增加了源业务库的存储及维护压力，但对源系统的性能影响几乎没有。