数据增量接入（存储）方案
1 前言
在数据仓库中，数据的存储方式一般有四种：全量表、增量表、快照表和拉链表，如下表。
全量表
增量表
快照表
拉链表
数据
包含到前一天的全量数据
前一天的增量数据(和状态发生变化的数据)
包含到前一天的全量数据
前一天的增量数据和状态发生变化的数据
分区
不分区
按天分区
按天分区
按天分区/不分区
大数据平台支持增量表和快照表两存储方式。这里将重点讨论增量表存储方式。1.1 现状
目前大数据能力平台的增量接入功能较弱，基本不能在实际项目中使用。经测试和验证，主要有以下几个缺点：增量字段匹配少
如下图所示，增量字段必须是日期类型，且日期格式只有2种。在实际的项目中，增量字段有可能字符型，且格式有多种，如yyymm、yyyymmdd.....。
增量数据初始化方案有问题
大数据平台增量接入功能在第一次数据接入时，会进行数据的初始化，但目前的初始化方案很粗糙 ，即：将所有的存量数据写入一个分区。如下图所示。
而合理的初始化结果应该是根据增量字段来精准分区，如下图所示。
接入策略少，不支持函数的使用
平台的增量接入依赖增量字段，如果某个业务系统没有增量标识字段，那么增加接入就无法实现。
有些业务表会有[创建时间]和[更新时间]，通常情况下会以[更新时间]字段做增量标识，如果[更新时间]为空，则使用[创建时间]字段做增量标识，即函数nvl( 更新时间,创建时间)或者其他函数，但平台不支持这种使用方法。
小结：基于上面的3个缺点，在项目中很少使用增量接入功能，数据接入基本上采用的都是全量快照表的方式存储数据，增量接入功能还需要产品和开发持续完善。1.2 后果
由于增量接入存在的缺点，在项目实施过程中，数据接入基本采用的都是全量快照表的存储方式。而这种接入方式会造成如下后果。数据重复计算和处理，浪费宝贵的资源
以数据稽核为例(转换、开发、导出......)，每次稽核一个批次的数据，每个批次都会稽核在上一个批次中已经稽核过的数据。如下图，后续的所有数据计算都会存在重复计算。
节省宝贵的存储空间
如下图所示，增量存储表的数据量明显少了很多。增量接入获益的不仅仅是SRC层，后面的ODS、DW、APS每一层的数据存储量都会相应的减少。
2 增量策略
基于前期的项目总结，增量接入有四种策略，每种策略对应不同的业务表/应用场景，如下图所示四种策略。大数据平台应根据业务表的实际情况，提供四种接入方法。
2.1 有时间戳
这里的有时间戳是指业务表字段中有日期格式(日期或字符串类型)的增量字段来标识数据的创建时间或者更新时间，并不是所有的日期格式的字段都可以做增量标识字段。如下图所示，[创建时间]和[最后修改时间(更新时间)]，可以作为增量标识字段，而[出生日期]字段不能作为增量标识字段。
在业务系统中，有的表只有[创建时间]字段，有的表有[创建时间]和[更新时间]字段。这2种情况在增量存储时，数据会有些细微的差别，可根据具体的应用场景选择不同的存储策略。创建时间+更新时间
如果既有[创建时间]又有[更新时间]字段，在做增量接入时，增量标识字段就有2种选择。[创建时间]作增量标识，如下图所示，增量表中未能反映出[订单状态]更新的数据。
2. [更新时间]作增量标识，如下图所示，新增数据和状态发生改变的数据都写入到了增量表。其中，存在订单ID相同的数据(同一个数据分区理论上不会有相同订单ID)，但不是重复数据 (因为状态不相同)，亦是合理的数据。订单ID相同的数据反映了订单的历史轨迹(实现了拉链表的功能 )；如果想要统计订单总数，则根据订单ID去重统计即可，在其他具体应用时，取订单ID最新的状态数据即可(不要纠结重复不重复，针对具体场景来应用数据就行了 )。
小结：在实际的项目应用中，优先选择[更新时间]字段作增量标识。如果用户需求不关系数据的状态变化，使用[创建时间]字段做增量标识即可。创建时间
参考章节《创建时间+更新时间 ①》2.2 无时间戳
无时间戳指的是业务表中没有增量字段记录数据的创建/更新时间，这种业务表实现增量接入在技术上稍 麻烦些。在性能上要比有时间戳的要慢些，会消耗更多的计算资源(总有人纠结这个)。但这种资源消耗是可接受的，因为如果是全量快照的方式接入的话，后续的每一层、每种计算/转换/稽核都是基于全量数据计算的，消耗的资源会更多(每次处理全量的数据比处理增量的数据更耗资源)。有主键
如果业务表有主键字段，就可以根据主键值相同，对其他非主键字段(一个或多个)的值进行比对，来判断数据是更新数据还是新增数据。如下图所示，增量表的数据会根据指定的对比字段不同而不同。
无主键
没有主键的增量接入难办且不灵活，会改变表结构，需要手动给每一条数据增加主键值，主键值等于所有字段相加的HASH值。如下图所示，标红的与标蓝色的的数据因为内容完全一样，所以它们在2个批次的HASH主键值是一致的。
有了HASH主键以后，就可以根据有主键的方式对数据进行增量接入了(只要HASH主键变了，就是更新或者新增数据)，如下图所示。
一般不建议采用这种增加HASH主键的方式，基本上99%的业务表都会有主键。不到万不得已，不要采用这种方法。2.3 CDC
CDC，Change Data Capture,变更数据获取的简称，使用CDC我们可以从数据库中获取已提交的更改并将这些更改发送到下游，供下游使用。这些变更可以包括INSERT,DELETE,UPDATE等。常用的第三方cdc工具有canal、debezium等。
如果使用cdc中间件，可以忽略上面的场景。使用cdc实时数据同步：比如我们将mysql库中的数据同步到我们的数仓中。
3 技术实现
增量策略中的四种方案，目前大数据平台还未能实现(不知道会不会去开发实现)，目前可以采用一种折中的方案实现，即：SRC数据还是采取全量快照的方式进行接入，然后再通过自定义代码的方法处理SRC层最新批次的全量数据，找出增量数据写入ODS层，这样后续的每一层数据都是增量分区的数据，如下图。
4 缺点
如果有数据在业务系统中已经删除了，那么增量存储的表中还是会存这些数据的。严格来说，这个缺点不是增量存储的缺点，而是Hive的缺点，因为Hive的不可更新机制，导致了历史数据不能删除。如果采用MPP数据库(Greenplum、Vertica)则不会存在这个缺点。