大数据环境下历史数据归档实践

一、拉链表原理

链: 今人以锒铛之类相连属者为链 ——《六书故》。

顾名思义，链，有衔接、连接的意思。

拉链表是维护历史状态，以及最新状态数据的一种表。所谓拉链，就是记录历史，记录一个事物从开始，到当前状态的所有变化信息。拉链表能够减少数据冗余，节约存储空间，既能获取最新数据，也能根据筛选条件获取历史数据。以下是拉链的大致原理介绍。

假设有一张订单表orders，表结构如下：

该每日全量表的原始数据如下图所示

由图可知，该表现存三天订单的全量状态，共有14条记录，但是部分数据重复保存。例如，表中order_id为2和4的数据，每日重复保存了无变化的数据，而在实际生产环境中一条数据通常会有更多的字段，这样会造成极大的存储浪费。

将该表设计成拉链表orders_zipper保存，则会有下面一张表，表结构如下表所示。

拉链后数据缩减为9条记录，如下图所示。

说明：

1.start_dt表示该条记录的生命周期开始时间，

end_dt表示该条记录的生命周期结束时间；

2.end_dt='99991231'表示该条记录目前处于

有效状态；

3.如果查询当前所有有效的记录，则使用查询：

select * from orders_zipper where 

end_dt='99991231'        

4.如果查询20200311的历史快照，则使用查询：

select * from orders_zipper where

start_dt <='20200311' and 

end_dt >'20200311'，

这条语句会查询到记录如下图所示，

拉链表中查询的数据和下图所示的orders源表在3月11日的记录完全一致。因此将全量表处理为历史拉链表，既能满足查看历史数据的需求，又能节约存储资源。

二、算法说明

拉链表算法步骤介绍如下（文中SQL为示意说明）:

补充说明：

三、实践效果及场景推荐

在实际生产环境中，针对我行ODS层的631张表单进行拉链处理，共释放集群空间9.5T ,下图为10张数据量相对较大的表单拉链前后的空间对比情况，从图中可以看出拉链操作后空间占用明显降低，表单最高压缩比为99.66%，最低压缩比为74.79%。

 针对单张表分析，例如表单tab_7,共释放空间206.58GB，压缩比高达99.66%，该表在我行的生命周期策略为保留最近30天以及最近60个月的月底数据。值得注意的是，该表储存的历史数据为2019年4月至2020年3月，仅有11个月数据，尚未达到生命周期保留的月底数量，如果该表单存在60个月的历史数据，仅单张表，按此预估能释放超过1T数据量。因此，随着业务的不断发展，历史数据的逐渐积累，拉链操作客观上将会释放更多的集群空间，极大程度的缓解硬件资源的压力。

同时，在拉链过程中，发现少部分表单空间释放效果一般，分析原因可能为，该表数据变动频繁或为交易类型数据、该表本身数据量较小等情况。本文给出拉链表常规参考使用场景如下图所示。

拉链表常规使用场景

1、表数据量大，字段多

2、表中的某些少量字段会更新，例如：客户信息表的电话号码、住址等

3、需要查看表某时间点或时间段的历史信息

4、表中数据新增或变化频率低，尤其是日志型数据

end