DataPipeline丨数据源变化捕获

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

1. 基于日志的解析模式；
2. 基于增量条件查询模式；
3. 数据源主动Push模式。

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

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

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

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

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

1. 能够完整获取数据变化的操作类型，尤其是Delete操作，这是增量条件查询模式很难做到的；
2. 不依赖特别的数据字段语义，例如更新时间；
3. 多数情况下具备较强的实时性。

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

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

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