Hive数仓拉链表原理

一、拉链表原理

1、引入

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

2、拉链表概念

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

3、举例说明

下面有一张原始表,表里面的有5条数据,该数据含有orderid、create_time、mod_time三列,分别表示订单编号、订单创建时间、订单修改时间。可以看出该数据都是在2020-11-14统计出来的,当天只能统计出前一天的数据。
Hive数仓拉链表原理_第1张图片
有了一张原始表之后,我们创建一个拉链表,所来记录之后所有的订单更新以及新建的详情,如下图所示,我们可以看出拉链表比原始表多了两列,分别为start_time、end_time,分别表示为订单的生效日期以及失效日期。其中一开始生效日期就是创建日期,而失效日期我们设置为很大的数字,表示只要该条订单不被修改,那就是永久生效。
Hive数仓拉链表原理_第2张图片
创建原始表和初步的拉链表后,到15号开始统计14号的数据,又有两条记录,入下图所示。因为我们每天产生的记录都会按照日期将数据保存在分区表中,所以该分区表最后多了一列表示分区名,其实就是日期。
image.png
更新原始表如下图所示,我们发现在14号的记录中,2号订单在14号被修改过一次,同时又创建了一个6号订单
Hive数仓拉链表原理_第3张图片

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

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

最终将14号的记录更新后,拉链表如下图所示。
Hive数仓拉链表原理_第5张图片

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

更新原始表如下图与所示。将2号和4号订单的end_time改成15号,同时增加一个7号订单信息。
Hive数仓拉链表原理_第6张图片

更新拉链表,让新的14号的拉链表和15号的数据分区表做left join,以及之后的整合。
Hive数仓拉链表原理_第7张图片

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

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

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

你可能感兴趣的:(hive)