数据源监听

数据源监听

源数据变化捕获是数据集成的起点,获取数据源变化主要有三种方式:

  • 基于日志的解析模式;

  • 基于增量条件查询模式;

  • 数据源主动推送模式。

基于日志的解析模式常用于各种类型的数据库,例如 MySQL 的 Binlog、Oracle 的 Redo&Achieve Log、SQL Server Change Tracking & CDC 等。

不同数据库日志解析的原理差别很大,以 MySQL Binlog 模式为例,解析程序本身是一个 Slave,能够实时收到 MySQL Master 的数据流推送,并解析还原成 DDL 和 DML 操作。而 SQL Server 的 CT 模式下,增量是通过定期查询 Change Tracking 表实现的。

基于增量条件的查询模式不依赖于源端开启日志记录,但对于数据源通常有额外的格式要求。例如,数据库表或文档对象需要有标志更新时间的字段,这在一些业务系统中是无法满足的。

数据源主动推送模式的常见形式为业务插码,即应用系统通过打点或者配置切面的方式,将数据变化封装为事件,额外发送一份给数据集成平台。这种方式一般需要对源端系统代码进行一定程度的修改。

数据库日志增量捕获

通常而言,基于数据库的日志进行增量捕获应当被优先考虑。其具备以下几个显著优点:

  • 能够完整获取数据变化的操作类型,尤其是 Delete 操作,这是增量条件查询模式很难做到的;

  • 不依赖特别的数据字段语义,例如更新时间;

  • 多数情况下具备较强的实时性。

当然,事物都具有两面性。开启数据库日志通常会对源库性能产生一定的影响,需要额外的存储空间,甚至一些解析方法也会对源库资源造成额外消耗。因此,实施过程中需要在 DBA 的配合下,根据数据库特点和解析原理进行 DB 部署规划。

推荐使用数据库的复制和灾备能力,在独立服务器对从库进行日志解析。此外,当数据库产生批量更新时,会在短时间内产生大量日志堆积,如果日志留存策略设置不当,容易出现数据丢失。这些都需要根据具体的业务数据增长特点,在前期做好规划,并在上线后根据业务变化定期进行评估和调整。

数据源推送

数据源主动 push 模式下,由于事件发送和业务处理很难做到事务一致性,所以当出现异常时,数据一致性就无从保证,比较适合对于数据一致性要求不高的场景,例如用户行为分析。