一般增量数据处理的几种场景
通常在数据量较少的情况下，我们从一个数据源将全部数据加载到目标数据库的时候可以采取的策略可以是：先将目标数据库的数据全部清空掉，然后全部重新从数据源加载进来。这是一个最简单并且最直观的并且不容易出错的一种解决方案，但是在很多时候会带来性能上的问题。
如果我们的数据源来自于不同的业务系统，数据动辄百万，千万甚至亿级计算。第一次需要全部加载，如果在第二次周期或者第三次周期的时候仍然全部加载的话，耗费了极大的物理和时间资源。有可能部分数据源并未发生变化，而有的数据源可能只是增加了少量的数据。
我们要考虑的问题是，对于已经存在目标数据库中的数据都是历史数据，对于数据源中的数据我们只应该考虑新修改的记录和新插入的记录，只应该考虑这两种数据。所以增量处理实质上就是处理变化的数据。
下面我们一起看看这些表，忽略从数据仓库设计的角度，只考虑如何实现增量数据的检测和抽取。
第一类 - 具有时间戳或者自增长列的绝对历史数据表
这张表能够代表一部分数据源的特征 - 绝对历史事实数据。它指的是表中的数据是不可逆的，只有插入操作没有删除或者修改操作，表示在过去一段时间内完成的事实业务数据。比如这张表表示的某些产品的下载信息，用户什么时候下载了产品就会在数据库中记录一条数据。
这种数据表一般会提供一列能够记载这条记录生成的历史时间，或者说这个操作发生的时间，越早的操作时间越靠前，越晚的操作时间越靠后。
那么对于这类表的增量处理策略就是：
- 第一次加载动作完成之后，记录一下最大的时间点，保存到一个加载记录表中。
- 从第二次加载开始先比较上次操作保存的最后/最大的时间点，只加载这个时间点以后的数据。
- 当加载过程全部成功完成之后再更新加载记录表，更新这次最后的时间点。
另外，如果这类表有自增长列的话，那么也可以使用自增长列来实现这个标识特征。
第二类 - 有修改时间特征的数据表
这类表中的数据一般属于可以修改带有维护性质的数据，比如像会员信息表，创建会员的时候会生成一条记录，会在 CreateDate 标记一下，并且在 UpdateDate 中保存的也是 CreateDate 的值。当 CreateDate 和 UpdateDate 相同的时候说明这一条数据是插入操作，但是这个会员的信息是可以被编辑和修改的，于是每次更新的同时也更新了 UpdateDate 时间戳。
假设上面的这几条数据在第一次加载到目标数据
