我们通常所说的增量数据,其实更确切的说,应该是变量数据,包括对数据的增加、修改和删除。特别是当有些系统存在物理删除数据的情况时,这一点尤为重要。    从各源系统获取增量数据,是DW/BI类相关应用所必需的环节,那么从源系统获取增量数据的方式究竟有哪些呢?哪些又是我们经常使用的呢?下面我们就来简单介绍介绍:

 这第一种可以是由源系统在数据处理过程当中由应用程序直接记录增量数据,产生增量数据文件。这种做法对源系统的效率会有较大影响,需要改造源系统的应用(植入获取增量数据的程序)所以如果源系统方比较强硬的话不同意植入,甚至源系统与DW系统不是一家单位的那就更无法让你植入了。

第二种由源系统在日终时按照数据的逻辑规则(如业务日期)识别增量数据,产生增量数据文件。这种做法不影响源系统的日间处理效率,需要开发新的增量数据卸载应用,能够比较有效的识别源系统中的增量数据。这是目前采取的比较多的方式。但是如果存在不经过应用而物理删除数据的情况,则无法识别(日积月累将导致数据仓库出现历史脏数据)

第三  利用数据库系统的机制,在源系统中增加设置(如trigger,mv,cdc),在日间数据处理过程中由数据库系统识别增量数据,然后再通过应用加工得到增量文件。这种方式对日间处理的效率会有一定的影响,但通常都可以接受,对增量的识别会非常全面,但识别出来的增量数据往往含有大量的过程数据,特别是当同一数据被多次修改时,会产生大量的冗余数据,这是这种方式的一个缺点,需要通过应用加以合并取得该数据的最终状态。这种方式的一个优点,是可以识别出绕过应用直接对数据库所作的修改,包括直接物理删除的内容,这是前一种方式难以做到的。这种方式也是目前比较常见的一种方式,但需要对相关的设置和使用方法非常熟悉。

 第四数据比对。将源系统当日的数据与昨日的数据进行比较,识别出差异部分作为增量数据,如果需要识别出被物理删除的数据,由于不同的实现方式这种比对可能需要执行两次,一次是找出源系统当日增加和修改了的数据,另一次是找出源系统中当日被删除的数据。这种比对需要首先将源系统的全量数据卸载,然后进行全量数据的比对,效率是一个主要的问题。这种方式据说也有采用,但好像不多。

第五 数据复制。如果目标数据库与源数据库是同构的,还可以利用数据库系统的复制机制直接获得增量数据并应用到目标数据库中。不同数据库厂商的复制机制不尽相同,对源系统效率的影响通常都可以接受,但复制本身的效率是需要特别关注的,而且还需要考察复制机制下的中断恢复能力。据说目前这种做法在某些领域也有应用。

第六 依赖RDBMS的日志,对事务数据库的日志文件进行分析,这种办法的成本太高并且要求也比较专业,一般不太适用。