ETL有四种主要实现模式:触发器模式、增量字段、全量同步、日志比对
触发器模式
触发器方式是普遍采取的一种增量抽取机制。该方式是根据抽取要求,在要被抽取的源表上建立插入、修改、删除3个触发器,每当源表中的数据发生变化,就被相应的触发器将变化的数据写入一个增量日志表,ETL的增量抽取则是从增量日志表中而不是直接在源表中抽取数据,同时增量日志表中抽取过的数据要及时被标记或删除。
为了简单起见,增量日志表一般不存储增量数据的所有字段信息,而只是存储源表名称、更新的关键字值和更新操作类型(insert、update或delete),ETL增量抽取进程首先根据源表名称和更新的关键字值,从源表中提取对应的完整记录,再根据更新操作类型,对目标表进行相应的处理。
优点:
数据抽取的性能高,ETL 加载规则简单,速度快,不需要修改业务系统表结构,可以实现数据的递增加载。
缺点:
要求业务表建立触发器,对业务系统有一定的影响,容易对源数据库构成威胁。
增量字段
增量字段方式来捕获变化数据,原理就是在源系统业务表数据表中增加增量字段,增量字段可以是时间字段,同时也可以是自增长字段(如oracle的序列),设计要求就是源业务系统中数据新增或者被修改时,增量字段就会产生变化,时间戳字段就会被修改为相应的系统时间,自增长字段就会增加。
每当ETL工具进行增量数据获取时,只需比对最近一次数据抽取的增量字段值,就能判断出来哪些是新增数据,哪些是修改数据。这种数据抽取方式的优点就是抽取性能比较高,判断过程比较简单,最大的局限性就是由于某些数据库在进行设计的时候,未考虑到增量字段,需要对业务系统进行改造,基于数据库其他方面的原因,还有可能出现漏数据的情况。
优点:
同触发器方式一样,时间戳方式的性能也比较好,ETL 系统设计清晰,源数据抽取相对清楚简单,可以实现数据的递增加载。
缺点:
时间戳维护需要由业务系统完成,对业务系统也有很大的侵入性(加入额外的时间戳字段),特别是对不支持时间戳的自动更新的数据库,还要求业务系统进行额外的更新时间戳操作;
另外,无法捕获对时间戳以前数据的delete和update 操作,在数据准确性上受到了一定的限制。
全量同步
全量同步又叫全表删除插入方式,是指每次抽取前先删除目标表数据,抽取时全新加载数据。该方式实际上将增量抽取等同于全量抽取。对于数据量不大,全量抽取的时间代价小于执行增量抽取的算法和条件代价时,可以采用该方式。
同步流程:
优点:
对已有系统表结构不产生影响,不需要修改业务操作程序,所有抽取规则由ETL完成,管理维护统一,可以实现数据的递增加载,没有风险。
缺点:
ETL 比对较复杂,设计较为复杂,速度较慢。与触发器和时间戳方式中的主动通知不同,全表比对方式是被动的进行全表数据的比对,性能较差。当表中没有主键或唯一列且含有重复记录时,全表比对方式的准确性较差。
日志比对
日志比对的方式是通过获取数据库层面的日志来捕获到变化的数据,不需要改变源业务系统数据库相关表结构,数据同步的效率比较高,同步的及时性也比较快,最大的问题就是前面所提到的不同的数据库的数据库日志文件结构存在较大的差异性,实施分析起来难度比较大,同时需要具备访问源业务库日志表文件的权限,存在一定的风险性,所以这种方式有很大的局限性。
日志比对方式中比较成熟的技术是Oracle的CDC(Changed Data Capture)技术,作用同样是能够捕获到上一次抽取之后的产生的相关变化数据,当CDC对源业务表进行新增、更新和删除等相关操作的时就可以捕获到相关变化的数据,相对于增量字段方式,CDC方式能够较好的捕获到删除数据,并写入相关数据库日志表,然后再通过视图或者别的某种可操作的方式将捕获到的变化同步到数据仓库当中去。
优点:
ETL同步效率较高,不需要修改业务系统表结构,可以实现数据的递增加载。
缺点:
业务系统数据库版本与产品不统一,难以统一实现,实现过程相对复杂,并且需深入研究方能实现。或者通过第三方工具实现,一般都是商业软件,而且费用较高。
模式对比
增量机制 | 兼容性 | 完备性 | 抽取性能 | 源库压力 | 源库改动量 | 实现难度 |
触发器 | 关系型数据库 | 高 | 优 | 高 | 高 | 容易 |
增量字段 | 关系型数据库.具有”字段”结构的其它数据格式 | 低 | 较优 | 低 | 高 | 容易 |
全表同步 | 任何数据格式 | 高 | 极差 | 中 | 无 | 容易 |
日志比对 | 关系型数据库(oracle/mysql) | 高 | 较优 | 中 | 中 | 较难 |