Hive数仓拉链表原理

一、拉链表原理

1、引入

在数据仓库的数据模型设计过程中，经常会遇到这样的需求：
（1）数据量比较大。
（2）表中的部分字段会被update,如用户的地址，产品的描述信息，订单的状态等等。
（3）需要查看某一个时间点或者时间段的历史快照信息，比如，查看某一个订单在历史某一个时间点的状态。
（4）查看某一个用户在过去某一段时间内，更新过几次等等。
（5）变化的比例和频率不是很大，比如，总共有1000万的会员，每天新增和发生变化的有10万左右。
（6）如果对这边表每天都保留一份全量，那么每次全量中会保存很多不变的信息，对存储是极大的浪费。
拉链表，既能满足反应数据的历史状态，又可以最大程度的节省存储。

2、拉链表概念

拉链表是针对数据仓库设计中表存储数据的方式而定义的，顾名思义，所谓拉链，就是记录历史。记录一个事物从开始，一直到当前状态的所有变化的信息。

3、举例说明

下面有一张原始表，表里面的有5条数据，该数据含有orderid、create_time、mod_time三列，分别表示订单编号、订单创建时间、订单修改时间。可以看出该数据都是在2020-11-14统计出来的，当天只能统计出前一天的数据。

有了一张原始表之后，我们创建一个拉链表，所来记录之后所有的订单更新以及新建的详情，如下图所示，我们可以看出拉链表比原始表多了两列，分别为start_time、end_time,分别表示为订单的生效日期以及失效日期。其中一开始生效日期就是创建日期，而失效日期我们设置为很大的数字，表示只要该条订单不被修改，那就是永久生效。

创建原始表和初步的拉链表后，到15号开始统计14号的数据，又有两条记录，入下图所示。因为我们每天产生的记录都会按照日期将数据保存在分区表中，所以该分区表最后多了一列表示分区名，其实就是日期。

更新原始表如下图所示，我们发现在14号的记录中，2号订单在14号被修改过一次，同时又创建了一个6号订单

然后我们需要将14号数据的分区表和初步设计的拉链表开始整合，进行左外连接(left join),拉链表left join 分区表,连接后的表里面end_time字段为null的值重新设置为永久生效日期。

为什么要这样设置呢？
（1）首先进行左外链接，结果是只有2号订单能够和拉链表匹配的上，说明只有2号订单在14号发生了更新，那我们就将拉链表中的2号订单的end_time改成14号，而其他4个订单的end_time会为null，说明没有发生更新，那我们就将其设置为永久生效日期。
（2）我们还发现在14日的数据中除了修改2号订单，又创建了一个6号订单，所以在拉链表中我们在最后直接加入一个6号订单。

最终将14号的记录更新后，拉链表如下图所示。

依此类推，我们开始收集15号的记录数据，导入分区表中，如下图所示。发现2号订单又更新了一次，4号订单也更新了一次，同时又创建了一个7号订单。

更新原始表如下图与所示。将2号和4号订单的end_time改成15号，同时增加一个7号订单信息。

更新拉链表,让新的14号的拉链表和15号的数据分区表做left join,以及之后的整合。

这边有一个很重要的一点:就是2号订单之前已经修改过一次，end_time时间为14号，现在15号又修改一次，那之前14号的修改的那条2号订单数据其实已经失效，新的2号订单end_time为15号；与此同时，4号订单做了第一次的更新，所以将4号订单的end_time改成15号即可；最后又创建一个7号订单。如下图所示

最后一步就是将15号数据中修改2号订单和4号订单的数据重新添加到拉链表中。并且重新设置end_time为永久生效日期。

最终拉链表展示：我们可以看出某个订单在哪一天发生了变更，到了变更的那一天，按照订单号查找订单，就可以查出该订单编号之后有没有再变更，该过程就形成了一张拉链表。以2号订单为例：我们发现，2号订单在13号的时候被创建，14号的时候修改过一次，然后去统计15号的数据，发现2号订单在15号的时候又被修改过一次，最后2号订单是否还会被修改需要收集查看之后每天的数据分区表。