一、拉鏈表的使用場景
在數據倉庫的數據模型設計過程中，經常會遇到下面這種表的設計：
1)有一些表的數據量很大，比如一張用戶表，大約10億條記錄，50個字段，這種表，即使使用ORC壓縮，單張表的存儲也會超過100G，在HDFS使用雙備份或者三備份的話就更大一些。
2)表中的部分字段會被update更新操作，如用戶聯系方式，產品的描述信息，訂單的狀態等等。
3)需要查看某一個時間點或者時間段的歷史快照信息，比如，查看某一個訂單在歷史某一個時間點的狀態。
4)表中的記錄變化的比例和頻率不是很大，比如，總共有10億的用戶，每天新增和發生變化的有200萬左右，變化的比例占的很小。
那么對於這種表我該如何設計呢？下面有幾種方案可選：
- 方案一：每天只留最新的一份，比如我們每天用Sqoop抽取最新的一份全量數據到Hive中。
這種方案實現起來很簡單，每天drop掉前一天的數據，重新抽一份最新的。優點很明顯，節省空間，一些普通的使用也很方便，不用在選擇表的時候加一個時間分區什么的。缺點同樣明顯，沒有歷史數據，先翻翻舊賬只能通過其它方式，比如從流水表里面抽。
- 方案二：每天保留一份全量的切片數據。
每天一份全量的切片是一種比較穩妥的方案，而且歷史數據也在。缺點就是存儲空間占用量太大太大了，如果對這邊表每天都保留一份全量，那么每次全量中會保存很多不變的信息，對存儲是極大的浪費。當然我們也可以做一些取舍，比如只保留近一個月的數據？但是，需求是無恥的，數據的生命周期不是我們能完全左右的。
- 方案三：使用拉鏈表。
拉鏈表在使用上基本兼顧了我們的需求。首先它在空間上做了一個取舍，雖說不像方案一那樣占用量那么小，但是它每日的增量可能只有方案二的千分之一甚至是萬分之一。其實它能滿足方案二所能滿足的需求，既能獲取最新的數據，也能添加篩選條件也獲取歷史的數據。所以我們還是很有必要來使用拉鏈表的。
二、拉鏈表的設計和實現
1、數據需求
我們先看一下在Mysql關系型數據庫里的user表中信息變化。
- 在2017-01-01這一天表中的數據是：
注冊日期 用戶編號 手機號碼
2017-01-01 001 111111
2017-01-01 002 222222
2017-01-01 003 333333
2017-01-01 004 444444
- 在2017-01-02這一天表中的數據是， 用戶002和004資料進行了修改，005是新增用戶：
注冊日期 用戶編號 手機號碼 備注
2017-01-01 001 111111
2017-01-01 002 233333 （由222222變成233333）
2017-01-01 003 333333
2017-01-01 004 432432 （由444444變成432432）
2017-01-02 005 555555 （2017-01-02新增）
- 在2017-01-03這一天表中的數據是， 用戶004和005資料進行了修改，006是新增用戶：
注冊日期 用戶編號 手機號碼 備注
2017-01-01 001 111111
2017-01-01 002 233333
2017-01-01 003 333333
2017-01-01 004 654321 （由432432變成654321）
2017-01-02 005 115115 （由555555變成115115）
2017-01-03 006 666666 （2017-01-03新增）
如果在數據倉庫中設計成歷史拉鏈表保存該表，則會有下面這樣一張表，這是最新一天（即2017-01-03）的數據：
注冊日期 用戶編號 手機號碼 t_start_date t_end_date
2017-01-01 001 111111 2017-01-01 9999-12-31
2017-01-01 002 222222 2017-01-01 2017-01-01
2017-01-01 002 233333 2017-01-02 9999-12-31
2017-01-01 003 333333 2017-01-01 9999-12-31
2017-01-01 004 444444 2017-01-01 2017-01-01
2017-01-01 004 432432 2017-01-02 2017-01-02
2017-01-01 004 654321 2017-01-03 9999-12-31
2017-01-02 005 555555 2017-01-02 2017-01-02
2017-01-02 005 115115 2017-01-03 9999-12-31
2017-01-03 006 666666 2017-01-03 9999-12-31
2、拉鏈表設計說明
-
t_start_date表示該條記錄的生命周期開始時間，t_end_date表示該條記錄的生命周期結束時間。
-
t_end_date = '9999-12-31’表示該條記錄目前處於有效狀態。
-
如果查詢當前所有有效的記錄，則
select * from user where t_end_date = ‘9999-12-31’
- 如果查詢2017-01-02的歷史快照，判斷生效時間小於等於2017-01-02，失效時間大於等於2017-01-02，則
select * from user where t_start_date <= ‘2017-01-02’ and t_end_date >= ‘2017-01-02’
三、在Hive中實現拉鏈表
1、創建ods層和dw層表
- ods層的ods.user表
以日期作為分區字段，壓縮格式為ORC
CREATE EXTERNAL TABLE ods.user (
user_num STRING COMMENT '用戶編號',
mobile STRING COMMENT '手機號碼',
reg_date STRING COMMENT '注冊日期'
COMMENT '用戶資料表'
PARTITIONED BY (dt string)
ROW FORMAT DELIMITED FIELDS TERMINATED BY '\t' LINES TERMINATED BY '\n'
STORED AS ORC
LOCATION '/ods/user';
)
- ods層的ods.user_update表，即用戶每日更新表
CREATE EXTERNAL TABLE ods.user_update (
user_num STRING COMMENT '用戶編號',
mobile STRING COMMENT '手機號碼',
reg_date STRING COMMENT '注冊日期'
COMMENT '每日用戶資料更新表'
PARTITIONED BY (dt string)
ROW FORMAT DELIMITED FIELDS TERMINATED BY '\t' LINES TERMINATED BY '\n'
STORED AS ORC
LOCATION '/ods/user_update';
)
- 在dw層創建拉鏈表：dws.user_his
在這張表中沒有分區，但壓縮格式依舊是ORC
CREATE EXTERNAL TABLE dws.user_his (
user_num STRING COMMENT '用戶編號',
mobile STRING COMMENT '手機號碼',
reg_date STRING COMMENT '用戶編號',
t_start_date ,
t_end_date
COMMENT '用戶資料拉鏈表'
ROW FORMAT DELIMITED FIELDS TERMINATED BY '\t' LINES TERMINATED BY '\n'
STORED AS ORC
LOCATION '/dws/user_his';
)
2、增量的sql實現
假設我們已經已經初始化了2017-01-01的日期，然后需要更新2017-01-02那一天的數據
實現思路：（對需要修改的數據進行update） UNION ALL （新增的數據）
INSERT OVERWRITE TABLE dws.user_his
SELECT * FROM
(
SELECT A.user_num,
A.mobile,
A.reg_date,
A.t_start_time,
CASE
WHEN A.t_end_time = '9999-12-31' AND B.user_num IS NOT NULL
THEN '2017-01-01'
ELSE A.t_end_time
END AS t_end_time
FROM dws.user_his AS A
LEFT JOIN ods.user_update AS B
ON A.user_num = B.user_num
UNION ALL
SELECT C.user_num,
C.mobile,
C.reg_date,
'2017-01-02' AS t_start_time,
'9999-12-31' AS t_end_time
FROM ods.user_update AS C
) AS T
3、查詢性能
假如存放了5年的拉鏈數據，那么這張表勢必會比較大，當查詢的時候性能就比較低了，個人認為兩個思路來解決：
-
在一些查詢引擎中，我們對start_date和end_date做索引，這樣能提高不少性能。
-
保留部分歷史數據，比如說我們一張表里面存放全量的拉鏈表數據，然后再對外暴露一張只提供近3個月數據的拉鏈表。
四、拉鏈表的sparkSQL整合hive實現
現在介紹的這種設計方案與上面的方案大同小異，主要區別在於數據的存儲格式，以及分區的設計，增量抽取數據時增加了臨時表作為存儲。
0、拉鏈表的數據效果圖
1、拉鏈表設計具體步驟
- 1）第一次全量導入
- 所有的ODS層數據全量導入到拉鏈歷史記錄表中
- 2）增量導入（某天，例如：2021-07-21）
- 增量導入某天的數據到ODS分區
- 合並歷史數據（通過連接查詢的方式進行更新）
2、MySQL和ods層以及dw層數據說明
-
MySQL層數據和ods層數據保持一致
-
在ods層使用dt作為日期，對每日增量數據進行分區存儲，即每天都會增加一個分區
-
ods層數據都是用parquet格式存儲，snappy壓縮格式，對於sparkSQL的支持是最好的
-
在dw層使用拉鏈表技術，不分區
-
dw層每張表都有一張對應的臨時中間表
3、數據導入
- 使用sparkSQL進行數據操作全量導入（數據日期是20190909號之前的）
modifyTime，為數據的修改時間
dw_start_date，為數據的生效時間，只要當modifyTime不為空，就等於modifyTime的時間，否則就等於createTime創建時間的值
dw_end_date，為數據的失效時間，第一次全量導入時全部都初始化為"9999-12-31"，寓意永久不失效
- 增量導入（將20190910號的數據導入到拉鏈表中）
1）使用kettle將20190910的數據抽取到ods
2）編寫spark-sql更新歷史數據（從ods層的20190910號分區獲取數據）
dw_start_date，為數據的生效時間，此時不會做改變
dw_end_date，為數據的失效時間，如果dw_end_date依舊為"9999-12-31"，並且ods層的20190910號分區中goodsId（即兩張表中都用此商品Id時），把dw_end_date更新為昨天的日期"2019-09-09"，否則日期不變
3）編寫spark-sql獲取當日數據
dw_start_date，為數據的生效時間，只要當modifyTime不為空，就等於modifyTime的時間，否則就等於createTime創建時間的值
dw_end_date，為數據的失效時間，此時不會做改變
4）先把數據合並到臨時表中，第5步在把臨時表中的數據插入到dw層的表中
5）將歷史數據和當日數據導入到歷史拉鏈表中及查詢數據
