数据增量接入（存储）方案

　　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。3CDC
　　CDC，ChangeDataCapture，变更数据获取的简称，使用CDC我们可以从数据库中获取已提交的更改并将这些更改发送到下游，供下游使用。这些变更可以包括INSERT，DELETE，UPDATE等。常用的第三方cdc工具有canal、debezium等。
　　如果使用cdc中间件，可以忽略上面的场景。使用cdc实时数据同步：比如我们将mysql库中的数据同步到我们的数仓中。
　　3技术实现
　　增量策略中的四种方案，目前大数据平台还未能实现（不知道会不会去开发实现），目前可以采用一种折中的方案实现，即：SRC数据还是采取全量快照的方式进行接入，然后再通过自定义代码的方法处理SRC层最新批次的全量数据，找出增量数据写入ODS层，这样后续的每一层数据都是增量分区的数据，如下图。
　　4缺点
　　如果有数据在业务系统中已经删除了，那么增量存储的表中还是会存这些数据的。严格来说，这个缺点不是增量存储的缺点，而是Hive的缺点，因为Hive的不可更新机制，导致了历史数据不能删除。如果采用MPP数据库（Greenplum、Vertica）则不会存在这个缺点。