ETL中增量更新是一个比较依赖与工具和设计方法的过程，Kettle中主要提供Insert / Update 步骤，Delete 步骤和Database Lookup 步骤来支持增量更新，增量更新的设计方法也是根据应用场景来选取的，虽然本文讨论的是Kettle的实现方式，但也许对其他工具也有一些帮助。本文不可能涵盖所有的情况，欢迎大家讨论。

应用场景
增量更新按照数据种类的不同大概可以分成：
1. 只增加，不更新，
2. 只更新，不增加
3. 即增加也更新
4. 有删除，有增加，有更新
其中1 ，2， 3种大概都是相同的思路，使用的步骤可能略有不同，通用的方法是在原数据库增加一个时间戳，然后在转换之后的对应表保留这个时间戳，然后每次抽取数据的时候，先读取这个目标数据库表的时间戳的最大值，把这个值当作参数传给原数据库的相应表，根据这个时间戳来做限定条件来抽取数据，抽取之后同样要保留这个时间戳，并且原数据库的时间戳一定是指定默认值为sysdate当前时间（以原数据库的时间为标准），抽取之后的目标数据库的时间戳要保留原来的时间戳，而不是抽取时候的时间。
   对于第一种情况，可以使用Kettle的Insert / Update 步骤，只是可以勾选Don’t perform any update选项，这个选项可以告诉Kettle你只会执行Insert 步骤。
对于第二种情况可能比较用在数据出现错误然后原数据库有一些更新，相应的目标数据库也要更新，这时可能不是更新所有的数据，而是有一些限定条件的数据，你可以使用Kettle的Update 步骤来只执行更新。关于如何动态的执行限定条件，可以参考前一篇文章。
第三种情况是最为常见的一种情况，使用的同样是 Kettle的Insert / Update 步骤，只是不要勾选Don’t perform any update 选项。
第四种情况有些复杂，后面专门讨论。

对于第1，2，3种情况，可以参考下面的例子。
这个例子假设原数据库表为customers , 含有一个id , firstname , lastname , age 字段，主键为id , 然后还加上一个默认值为sysdate的时间戳字段。转换之后的结果类似：id , firstname , lastname , age , updatedate . 整个设计流程大概如下：

 
                                                                        图1
其中第一个步骤的sql 大概如下模式：
Select max(updatedate) from target_customer ;
你会注意到第二个步骤和第一个步骤的连接是黄色的线，这是因为第二个table input 步骤把前面一个步骤的输出当作一个参数来用，所有Kettle用黄色的线来表示，第二个table input 的sql 模式大概如下：
Select field1 , field2 , field3 from customers where updatedate > ?
后面的一个问号就是表示它需要接受一个参数，你在这个table input 下面需要指定replace variable in script 选项和execute for each row 为选中状态，这样，Kettle就会循环执行这个sql , 执行的次数为前面参数步骤传入的数据集的大小。
 
                                                                            图2

关于第三个步骤执行insert / update 步骤需要特别解释一下，
 
                                                                                    图3

Kettle执行这个步骤是需要两个数据流对比，其中一个是目标数据库，你在Target table 里面指定的，它放在The keys to look up the values(s) 左边的Table field 里面的，另外一个数据流就是你在前一个步骤传进来的，它放在The keys to look up the value(s) 的右边，Kettle首先用你传进来的key 在数据库中查询这些记录，如果没有找到，它就插入一条记录，所有的值都跟你原来的值相同，如果根据这个key找到了这条记录，kettle会比较这两条记录，根据你指定update field 来比较，如果数据完全一样，kettle就什么都不做，如果记录不完全一样，kettle就执行一个update 步骤。所以首先你要确保你指定的key字段能够唯一确定一条记录，这个时候会有两种情况：
1.维表
2.事实表
维表大都是通过一个主键字段来判断两条记录是否匹配，可能我们的原数据库的主键记录不一定对应目标数据库中相应的表的主键，这个时候原数据库的主键就变成了业务主键，你需要根据某种条件判断这个业务主键是否相等，想象一下如果是多个数据源的话，业务主键可能会有重复，这个时候你需要比较的是根据你自定义生成的新的实际的主键，这种主键可能是根据某种类似与sequence 的生成方式生成的，
事实表在经过转换之后，进目标数据库之前往往都是通过多个外键约束来确定唯一一条记录的，这个时候比较两条记录是否相等都是通过所有的维表的外键决定的，你在比较了记录相等或不等之后，还要自己判断是否需要添加一个新的主键给这个新记录。
上面两种情况都是针对特定的应用的，如果你的转换过程比较简单，只是一个原数据库对应一个目标数据库，业务主键跟代理主键完全相同的时候完全可以不用考虑这么多。