kettle实现拉链表_kettle 拉链表

前言

最近工作中遇到使用拉链表备份数据的需求，网上有相关概念，但是在用kettle实现过程中，发现还是不太满足现实业务，自己将概念和实现过程记录下来和大家分享。

一、概念

拉链表： 维护历史状态，以及最新状态数据的一种表，拉链表根据拉链粒度的不同，实际上相当于快照，只不过做了优化，去除了一部分不变的记录，通过拉链表可以很方便的还原出拉链时点的客户记录。

二、举例

百度百科讲的确实很专业，但是貌似看不太懂，下面举个简单例子，看图理解起来就很简单。

假设我们系统中有张用户表（user_info），总共有100万条数据，每日修改量可能在5万到10万左右，如果需要查询某个时间段内某个用户的信息变更记录，应该怎么实现？大家的答案肯定很多，但是从实现复杂度、需求实现时间以及实现成本等方面讲，通过拉链表实现是一个比较不错的解决方案。

1、新建一张 user_info表，插入10条数据：

2、新建用户表对应拉链表（user_info_his），注意拉链表需要比原表多 四个默认字段

• AGENCY_KEY 代理主键
• VERSION 拉链版本
• DATE_FROM 拉链起始日期
• DATE_TO 拉链结束日期

3，执行完拉链操作后，拉链表数据如下

说明：此处我将 user_info 中姓名为 Lily 的数据做了两次修改，将remark字段 从V1改到V3，每次修改后都用kettle执行转换操作。可以发现 user_info_his 表中框起来的数据特点：version字段自增；date_from 和 date_to 呈现拉链结构。这样我们要查某个时间段内的数据变化，通过date_from和date_to两个日期字段进行限制，是不是很方便。

三、kettle实现

总览

可能有同学看过网上有博主用kettle实现拉链表的分享，没有这么复杂啊。实不相瞒，我也是看博主实现的，但是网上的教程还存在两点个人认为不完善之处：

• 拉链功能实现后，拉链表中会有一条 AGENCY_KEY=0、 VERSION=1 其余内容为空的数据，这个我们是不需要的。
• 当原表中的数据删除后，拉链表中对应的记录不会删除，而且date_to是 2199-12-31，按正常逻辑处理的话这条数据还是生效的，这显然不是我们希望看到的结果

总览步骤较多的原因就是为了处理这两点不完善的情况，下面开始通过kettle实现

1、实现拉链功能

步骤1： 获取原表信息

步骤2： 获取系统信息，主要是获取操作时间，后续维度查询更新使用

步骤3： 创建维度查询/更新，此步骤是关键步骤，所以会将此步骤的内容分点注释

3-1：更新维度吗？必须勾选，否则不生效
3-2：字段：需要插入的字段，点开选择字段即可，如图：

3-3：用于确定对比数据的关键字
3-4：标识记录的唯一性（个人理解）
3-5：确定记录的更新版本
3-6：若记录有变动，记录创建新纪录的时间，拉链表的date_from和date_to 使用
3-7：记录的开始时间，自定义
3-8：记录的结束时间，自定义

至此，拉链表的基本功能已经实现，执行看下效果

原表未修改、拉链表为空时执行一次转换，看看效果：

修改原表的一条数据后，执行转换，看看效果：

可以看到功能已经基本实现，但是总有一条空的记录（AGENCY_KEY=0）很多余，kettle默认生成的这条数据需要想办法处理掉。接着往下摸索

2、删除默认生成的空数据

既然多余一条数据，直接删除就行，下面具体实现

步骤4： 阻塞步骤，kettle的步骤应该是并发执行的，此处不阻塞的话，会先执行第5步中的删除脚本， 后执行第4步，导致整个转换执行结束后，数据库还是会有一条空数据，所以此处做个阻塞操作

步骤5： 删除空数据的脚本，下图中勾选的 执行每一行 选项需要勾选，否则脚本还是先于步骤3执行

删除空数据操作已经完成，执行转换看看效果


可以看到已经没有空数据了，至此，我们的拉链表功能已经完成。准备庆祝时，产品经理来了句：如果原表数据删除的话，拉链表中对应数据会发生什么改变？想了想这也是正常业务场景，就自己去试了试，结果是原表数据删除后，拉链表数据并不会发生变化，如果按照正常逻辑展示历史记录，已经删除的数据还是会被作为 “有效数据”。怎么办呢，接着摸索呗

3、原表删除时处理拉链表对应数据

整体思路：将原表和拉链表的数据做合并记录操作，会得到每条数据对比结果，对对比结果是deleted的数据进行更新date_to字段操作，即可满足需求（网上没有找到方案，自己想的，如果有更好的方法建议评论或者私聊，不胜感激）
步骤6–>步骤14 是具体处理过程，下面只做步骤截图，不做具体说明（真的写累了），若步骤6–>步骤13的操作不清楚，建议先找其他博主看下 合并记录 的操作过程

步骤6：

步骤7：

步骤8：

步骤9：

步骤10：

步骤11：

步骤12：

步骤13：

步骤14：

至此整个流程完成，检测下这个转换是否满足我们的需求
原表删除之前一直操作的name=Lily 的数据

执行转换任务


结果：拉链表中，name=Lily的数据，最后一个版本的 date_to已经是执行转换的时间，满足我们的需求

四、说明

上述转换在kettle完成后，可以通过作业定时执行，也可以通过Java代码实现转换步骤，在代码使用通过定时任务实现。
至于 三–3 中，处理原表已删除的数据为什么这么复杂，直接写SQL脚本通过 原表和拉链表关联来处理不是很简单，网上确实都是这样处理的，但是我们项目中，原表和拉链表 不在一个数据库，所以不能通过关联处理。上述的处理步骤即使原表和拉链表不在一个数据库，也是可以实现的。

原创不易，转载请注明出处。