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

针对于这个场景,我们发现主要矛盾会集中在左面的部分,数据交流采取了全表对比的方式。那么,咱们可以通过转发代替更换解决问题吗?还是仍然通过全量和增量的转化?
案例2与案例1的最大差异在于,所要共享的数据既非单一来自于人事体系,也非单一来自于教务系统,而是对两个数据库的多张表进行了转化,最终形成了需求共享的教职工基本信息数据。然而,转化的计划是无法解决跨库、异构场景问题的,所以咱们无法使用转化的计划解决案例2的问题。
那么根据时刻戳的增量处理计划可行吗?也不可,原因是人事、教务体系关于人员的数据表没有时刻戳字段。那还有其他的增量数据同步的计划么?
结合校园运用ODI作为ETL东西的实际情况,咱们能够直接使用ODI中的同步CDC方法,使用触发器的原理来识别变化数据,减少数据交流量,做到数据的高实时同步。咱们来看一下ODI同步CDC的实现原理及过程。


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