ETL有四种主要实现模式：
触发器模式
触发器方式是普遍采取的一种增量抽取机制。
根据抽取要求，在要被抽取的源表上建立插入、修改、删除3个触发器，
每当源表中的数据发生变化，就被相应的触发器将变化的数据写入一个增量日志表（或MQ通知） ，
ETL的增量抽取则是从增量日志表中而不是直接在源表中抽取数据，
同时增量日志表中抽取过的数据要及时被标记或删除。
为了简单起见，增量日志表一般不存储增量数据的所有字段信息，
而只是存储源表名称、更新的关键字值和更新操作类型(insert、update或delete)，
ETL增量抽取进程首先根据源表名称和更新的关键字值，从源表中提取对应的完整记录，再根据更新操作类型，对目标表进行相应的处理。
优点：
数据抽取的性能高，ETL 加载规则简单，速度快，不需要修改业务系统表结构，可以实现数据的递增加载。
缺点：
要求业务表建立触发器，对业务系统有一定的影响，容易对源数据库构成威胁。
数据库的触发器过于隐蔽，且要对业务全面了解，后期维护困难。一般不建议使用。
日志比对
（如binlog）（CDC真好用对吧！Canal）
日志比对的方式是通过获取数据库层面的日志来捕获到变化的数据，不需要改变源业务系统数据库相关表结构，数据同步的效率比较高，同步的及时性也比较快，最大的问题就是前面所提到的不同的数据库的数据库日志文件结构存在较大的差异性，实施分析起来难度比较大，同时需要具备访问源业务库日志表文件的权限，存在一定的风险性，所以这种方式有很大的局限性。
日志比对方式中比较成熟的技术是Oracle的CDC(Changed Data Capture)技术，作用同样是能够捕获到上一次抽取之后的产生的相关变化数据，当CDC对源业务表进行新增、更新和删除等相关操作的时就可以捕获到相关变化的数据，相对于增量字段方式，CDC方式能够较好的捕获到删除数据，并写入相关数据库日志表，然后再通过视图或者别的某种可操作的方式将捕获到的变化同步到数据仓库当中去。
优点：
ETL同步效率较高，不需要修改业务系统表结构，可以实现数据的递增加载。
缺点：
业务系统数据库版本与产品不统一，难以统一实现，实现过程相对复杂，并且需深入研究方能实现。或者通过第三方工具实现，一般都是商业软件，而且费用较高。
增量字段两种子方法
增量标记字段法
原理：在源表中添加状态字段（如is_modified），标记变化记录。
特点：
- 优点：灵活性高，可自定义标记逻辑（如批量标记）。
- 缺点：需业务系统更新标记字段，存在数据不一致风险。
优化建议：
- 结合索引提升查询效率；
- 采用异步批量标记（减少对业务事务的影响）。
扩展：
- 可以用010101标记哪几个字段变更
基于时间戳的增量抽取
原理：利用源表的时间戳字段（如last_modified_time）筛选新增或修改的数据。
特点：
- 优点：实现简单（仅需SQL条件过滤），性能较高。
- 缺点：无法捕获删除操作，依赖时间戳字段的准确更新（需业务系统配合）。
优化方案：
- 自动更新时间戳（如MySQL的ON UPDATE CURRENT_TIMESTAMP）；
- 结合双时间戳（创建时间+修改时间）区分新增和更新。
缺点：
另外，无法捕获对时间戳以前数据的delete和update 操作，在数据准确性上受到了一定的限制。
如：多次更新，只能捕获抽取时的最后一次更新后的数据。
时间戳维护需要由业务系统完成，对业务系统也有很大的侵入性（加入额外的时间戳字段），特别是对不支持时间戳的自动更新的数据库，还要求业务系统进行额外的更新时间戳操作；
全表比对（MD5校验）
原理：计算源表和目标表记录的MD5哈希值，比对差异后抽取变化数据。
特点：
- 优点：无需侵入源系统，兼容所有数据库类型。
- 缺点：性能差（需全表扫描），仅适合小数据量（单表<100万行）。
适用场景：
- 无主键或唯一标识的表；
- 数据量小且无时间戳的遗留系统。
仅推荐在初始化目标库时使用。
全量同步又叫全表删除插入方式，是指每次抽取前先删除目标表数据，抽取时全新加载数据。该方式实际上将增量抽取等同于全量抽取。对于数据量不大，全量抽取的时间代价小于执行增量抽取的算法和条件代价时，可以采用该方式。
