漫談數據倉庫之拉鏈表（原理、設計以及在Hive中的實現）

本文將會談一談在數據倉庫中拉鏈表相關的內容，包括它的原理、設計、以及在我們大數據場景下的實現方式。

全文由下面幾個部分組成：

1. 先分享一下拉鏈表的用途、什么是拉鏈表。
2. 通過一些小的使用場景來對拉鏈表做近一步的闡釋，以及拉鏈表和常用的切片表的區別。
3. 舉一個具體的應用場景，來設計並實現一份拉鏈表，最后並通過一些例子說明如何使用我們設計的這張表(因為現在Hive的大規模使用，我們會以Hive場景下的設計為例)。
4. 分析一下拉鏈表的優缺點，並對前面的提到的一些內容進行補充說明，比如說拉鏈表和流水表的區別。

0x01 什么是拉鏈表

拉鏈表是針對數據倉庫設計中表存儲數據的方式而定義的，顧名思義，所謂拉鏈，就是記錄歷史。記錄一個事物從開始，一直到當前狀態的所有變化的信息。

我們先看一個示例，這就是一張拉鏈表，存儲的是用戶的最基本信息以及每條記錄的生命周期。我們可以使用這張表拿到最新的當天的最新數據以及之前的歷史數據。

我們暫且不對這張表做細致的講解，后文會專門來闡述怎么來設計、實現和使用它。

拉鏈表的使用場景

在數據倉庫的數據模型設計過程中，經常會遇到下面這種表的設計：

1. 有一些表的數據量很大，比如一張用戶表，大約10億條記錄，50個字段，這種表，即使使用ORC壓縮，單張表的存儲也會超過100G，在HDFS使用雙備份或者三備份的話就更大一些。
2. 表中的部分字段會被update更新操作，如用戶聯系方式，產品的描述信息，訂單的狀態等等。
3. 需要查看某一個時間點或者時間段的歷史快照信息，比如，查看某一個訂單在歷史某一個時間點的狀態。
4. 表中的記錄變化的比例和頻率不是很大，比如，總共有10億的用戶，每天新增和發生變化的有200萬左右，變化的比例占的很小。

那么對於這種表我該如何設計呢?下面有幾種方案可選：

1. 方案一：每天只留最新的一份，比如我們每天用Sqoop抽取最新的一份全量數據到Hive中。
2. 方案二：每天保留一份全量的切片數據。
3. 方案三：使用拉鏈表。

為什么使用拉鏈表

現在我們對前面提到的三種進行逐個的分析。

方案一

這種方案就不用多說了，實現起來很簡單，每天drop掉前一天的數據，重新抽一份最新的。

優點很明顯，節省空間，一些普通的使用也很方便，不用在選擇表的時候加一個時間分區什么的。

缺點同樣明顯，沒有歷史數據，要想翻舊賬只能通過其它方式，比如從流水表里面抽。

方案二

每天一份全量的切片是一種比較穩妥的方案，而且歷史數據也在。

缺點就是存儲空間占用量太大太大了，如果對這邊表每天都保留一份全量，那么每次全量中會保存很多不變的信息，對存儲是極大的浪費，這點我感觸還是很深的……

當然我們也可以做一些取舍，比如只保留近一個月的數據?但是，需求是無恥的，數據的生命周期不是我們能完全左右的。

拉鏈表

拉鏈表在使用上基本兼顧了我們的需求。

首先它在空間上做了一個取舍，雖說不像方案一那樣占用量那么小，但是它每日的增量可能只有方案二的千分之一甚至是萬分之一。

其實它能滿足方案二所能滿足的需求，既能獲取最新的數據，也能添加篩選條件也獲取歷史的數據。

所以我們還是很有必要來使用拉鏈表的。

0x02 拉鏈表的設計和實現

如何設計一張拉鏈表

下面我們來舉個栗子詳細看一下拉鏈表。

我們先看一下在Mysql關系型數據庫里的user表中信息變化。

在2017-01-01這一天表中的數據是：

在2017-01-02這一天表中的數據是， 用戶002和004資料進行了修改，005是新增用戶：

在2017-01-03這一天表中的數據是， 用戶004和005資料進行了修改，006是新增用戶：

如果在數據倉庫中設計成歷史拉鏈表保存該表，則會有下面這樣一張表，這是最新一天(即2017-01-03)的數據：

說明

• 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的歷史快照，則select from user where t_start_date <= ‘2017-01-02’ and t_end_date >= ‘2017-01-02’。(*where條件篩選當前有效數據，開始日期小於等於當前日期並且結束日期大於等於當前日期，則為有效*)

在Hive中實現拉鏈表

在現在的大數據場景下，大部分的公司都會選擇以Hdfs和Hive為主的數據倉庫架構。目前的Hdfs版本來講，其文件系統中的文件是不能做改變的，也就是說Hive的表只能進行刪除和添加操作，而不能進行update。基於這個前提，我們來實現拉鏈表。

還是以上面的用戶表為例，我們要實現用戶的拉鏈表。在實現它之前，我們需要先確定一下我們有哪些數據源可以用。

1. 我們需要一張ODS層的用戶全量表。至少需要用它來初始化。
2. 每日的用戶更新表。

而且我們要確定拉鏈表的時間粒度，比如說拉鏈表每天只取一個狀態，也就是說如果一天有3個狀態變更，我們只取最后一個狀態，這種天粒度的表其實已經能解決大部分的問題了。

另外，補充一下每日的用戶更新表該怎么獲取，據筆者的經驗，有以下方式拿到或者間接拿到每日的用戶增量，因為它比較重要，所以詳細說明：

1. 我們可以監聽Mysql數據的變化，比如說用Canal，最后合並每日的變化，獲取到最后的一個狀態。
2. 假設我們每天都會獲得一份切片數據，我們可以通過取兩天切片數據的不同來作為每日更新表，這種情況下我們可以對所有的字段先進行concat，再取md5，這樣就ok了。
3. 流水表!有每日的變更流水表。
4. 通過etl工具對操作型數據庫按照時間字段增量抽取到ods或者數據倉庫(每天抽取前一天的數據)，形成每天的增量數據(實際中使用最多的情形)。

拉鏈表實現方式一：

ods層的user表

現在我們來看一下我們ods層的用戶資料切片表的結構：

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層的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';
)

拉鏈表

現在我們創建一張拉鏈表：

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';
)

實現sql語句

然后初始化的sql就不寫了，其實就相當於是拿一天的ods層用戶表過來就行，我們寫一下每日的更新語句。

現在我們假設我們已經已經初始化了2017-01-01的日期，然后需要更新2017-01-02那一天的數據，我們有了下面的Sql。

然后把兩個日期設置為變量就可以了。

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
    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

拉鏈表實現方式二：

操作型數據庫的用戶表結構：

CREATE EXTERNAL TABLE ods.user (
  user_num STRING COMMENT '用戶編號',
  mobile STRING COMMENT '手機號碼',
  reg_date STRING COMMENT '注冊日期' ,
  last_modify_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.user表的業務主鍵為user_num+mobile作為聯合主鍵。

每天增量抽取的用戶表結構和抽取條件：

1）表結構和上面的表結構保持一致，我們取表名為ods.user_update

2）增量抽取條件：select * from ods.user where last_modify_date = '$date'

拉鏈表

現在我們創建一張拉鏈表：

CREATE EXTERNAL TABLE dws.user_his (
  user_num STRING COMMENT '用戶編號',
  mobile STRING COMMENT '手機號碼',
  reg_date STRING COMMENT '用戶編號',
  last_modify_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';
)

實現sql

1）

merge into dws.user_his tar 

using

(

　　select user_num,mobile from ods.user_update 

) sou on tar.user_num=sou.user_num and tar.mobile=sou.mobile and tar.t_start_date < '$date' and tar.t_end_date >  '$date' 

when matched then 

update set tar.t_end_date='9999-12-31'

按照主鍵篩選，在dws.user_his表中出現過的並且現在為有效數據的，全部更新為閉鏈數據。

2)

INSERT  TABLE dws.user_his
SELECT
　　C.user_num,
        C.mobile,
        C.reg_date,
         c.last_modify_date
         '2017-01-02' AS t_start_time,
         '9999-12-31' AS t_end_time
  FROM ods.user_update AS C

比如我們要1月2號的數據，取出來的數據為

select from user where t_start_date <= ‘2017-01-02’ and t_end_date >= ‘2017-01-02’

與1月2號數據完全一致。 

0x03 補充

好了，我們分析了拉鏈表的原理、設計思路、並且在Hive環境下實現了一份拉鏈表，下面對拉鏈表做一些小的補充。

拉鏈表和流水表

流水表存放的是一個用戶的變更記錄，比如在一張流水表中，一天的數據中，會存放一個用戶的每條修改記錄，但是在拉鏈表中只有一條記錄。

這是拉鏈表設計時需要注意的一個粒度問題。我們當然也可以設置的粒度更小一些，一般按天就足夠。

查詢性能

拉鏈表當然也會遇到查詢性能的問題，比如說我們存放了5年的拉鏈數據，那么這張表勢必會比較大，當查詢的時候性能就比較低了，個人認為兩個思路來解決：

1. 在一些查詢引擎中，我們對start_date和end_date做索引，這樣能提高不少性能。
2. 保留部分歷史數據，比如說我們一張表里面存放全量的拉鏈表數據，然后再對外暴露一張只提供近3個月數據的拉鏈表。

 

4 拉鏈表回滾

　　4.1 具體操作方案

　　　　假設恢復到t天之前的數據，即未融合t天數據之前的拉鏈表，假設標記的開始日期和結束日期分別為s、t，具體分析如下：

1 當t-1>e時，s數據、e數據在t天之前產生，保留即可
2 當t-1=e時，e數據在t天產生，需修改
3 當s<t<=e時，e數據在t+n天產生，需修改
4 當s>=t時，s數據、e數據在t+n天產生，刪除即可

　　　　具體例子：

spark-sql> select * from t_dw_orders_his order by orderid,dw_start_date;
1       2015-08-18      2015-08-18      創建    2015-08-18      2015-08-21
1       2015-08-18      2015-08-22      支付    2015-08-22      2015-08-22
1       2015-08-18      2015-08-23      完成    2015-08-23      9999-12-31
2       2015-08-18      2015-08-18      創建    2015-08-18      2015-08-21
2       2015-08-18      2015-08-22      完成    2015-08-22      9999-12-31
3       2015-08-19      2015-08-21      支付    2015-08-19      2015-08-20
3       2015-08-19      2015-08-21      支付    2015-08-21      2015-08-22
3       2015-08-19      2015-08-23      完成    2015-08-23      9999-12-31
4       2015-08-19      2015-08-21      完成    2015-08-19      2015-08-20
4       2015-08-19      2015-08-21      完成    2015-08-21      9999-12-31
5       2015-08-19      2015-08-20      支付    2015-08-19      2015-08-22
5       2015-08-19      2015-08-23      完成    2015-08-23      9999-12-31
6       2015-08-20      2015-08-20      創建    2015-08-20      2015-08-21
6       2015-08-20      2015-08-22      支付    2015-08-22      9999-12-31
7       2015-08-20      2015-08-21      支付    2015-08-20      2015-08-20
7       2015-08-20      2015-08-21      支付    2015-08-21      9999-12-31
8       2015-08-21      2015-08-21      創建    2015-08-21      2015-08-21
8       2015-08-21      2015-08-22      支付    2015-08-22      2015-08-22
8       2015-08-21      2015-08-23      完成    2015-08-23      9999-12-31
9       2015-08-22      2015-08-22      創建    2015-08-22      9999-12-31
10      2015-08-22      2015-08-22      支付    2015-08-22      9999-12-31
11      2015-08-23      2015-08-23      創建    2015-08-23      9999-12-31
12      2015-08-23      2015-08-23      創建    2015-08-23      9999-12-31
13      2015-08-23      2015-08-23      支付    2015-08-23      9999-12-31　

　　　　比如在插入2015-08-23的數據后，回滾2015-08-22的數據，使拉鏈表與2015-08-21的一致，具體操作過程如下

1 增加臨時表t_dw_orders_his_tmp1，用來記錄t-1>e的數據
CREATE TABLE t_dw_orders_his_tmp1
AS
SELECT 
　　orderid,
　　createtime,
　　modifiedtime,
　　status,
　　dw_start_date,
　　dw_end_date
FROM 
　　t_dw_orders_his
WHERE 
　　dw_end_date < '2015-08-21'

3       2015-08-19      2015-08-21      支付    2015-08-19      2015-08-20
4       2015-08-19      2015-08-21      完成    2015-08-19      2015-08-20
7       2015-08-20      2015-08-21      支付    2015-08-20      2015-08-20

2 增加臨時表t_dw_orders_his_tmp2，用來記錄t-1=e的數據 
CREATE TABLE t_dw_orders_his_tmp2 
AS 
SELECT 　　
　　orderid,
　　createtime, 　　
　　modifiedtime, 　　
　　status, 　　
　　dw_start_date, 　　
　　'9999-12-31' AS dw_end_date 
FROM 
　　t_dw_orders_his
WHERE 
　　dw_end_date = '2015-08-21'

1       2015-08-18      2015-08-18      創建    2015-08-18      9999-12-31
2       2015-08-18      2015-08-18      創建    2015-08-18      9999-12-31
6       2015-08-20      2015-08-20      創建    2015-08-20      9999-12-31
8       2015-08-21      2015-08-21      創建    2015-08-21      9999-12-31

 
3 增加臨時表t_dw_orders_his_tmp3，用來記錄s<t<=e的數據
CREATE TABLE t_dw_orders_his_tmp3
AS
SELECT 
　　orderid,
　　createtime,
　　modifiedtime,
　　status,
　　dw_start_date,
　　'9999-12-31' dw_end_date
FROM 
　　t_dw_orders_his
WHERE 
　　dw_start_date < '2015-08-22' AND dw_end_date >= '2015-08-22'

3       2015-08-19      2015-08-21      支付    2015-08-21      9999-12-31
4       2015-08-19      2015-08-21      完成    2015-08-21      9999-12-31
5       2015-08-19      2015-08-20      支付    2015-08-19      9999-12-31
7       2015-08-20      2015-08-21      支付    2015-08-21      9999-12-31

4 所有數據插入新表t_dw_orders_his_new
CREATE TABLE t_dw_orders_his_new
AS
SELECT * FROM t_dw_orders_his_tmp1
UNION ALL
SELECT * FROM t_dw_orders_his_tmp2
UNION ALL
SELECT * FROM t_dw_orders_his_tmp3

1       2015-08-18      2015-08-18      創建    2015-08-18      9999-12-31
2       2015-08-18      2015-08-18      創建    2015-08-18      9999-12-31
3       2015-08-19      2015-08-21      支付    2015-08-19      2015-08-20
3       2015-08-19      2015-08-21      支付    2015-08-21      9999-12-31
4       2015-08-19      2015-08-21      完成    2015-08-19      2015-08-20
4       2015-08-19      2015-08-21      完成    2015-08-21      9999-12-31
5       2015-08-19      2015-08-20      支付    2015-08-19      9999-12-31 
6       2015-08-20      2015-08-20      創建    2015-08-20      9999-12-31
7       2015-08-20      2015-08-21      支付    2015-08-20      2015-08-20
7       2015-08-20      2015-08-21      支付    2015-08-21      9999-12-31
8       2015-08-21      2015-08-21      創建    2015-08-21      9999-12-31

 

與原數據一致，驗證無錯

 

　　4.2 備用方案

　　　　可以采用備份的方案，保證無誤和可行。（保存增量數據，並對t_dw_orders_his表每個月備份一次全量數據。如需回滾，最多重跑30天數據即可）

 

 

0xFF 總結

我們在這篇文章里面詳細地分享了一下和拉鏈表相關的知識點，但是仍然會有一會遺漏。歡迎交流。

在后面的使用中又有了一些心得，補充進來：

1. 使用拉鏈表的時候可以不加t_end_date，即失效日期，但是加上之后，能優化很多查詢。
2. 可以加上當前行狀態標識，能快速定位到當前狀態。
3. 在拉鏈表的設計中可以加一些內容，因為我們每天保存一個狀態，如果我們在這個狀態里面加一個字段，比如如當天修改次數，那么拉鏈表的作用就會更大。