數據倉庫中的拉鍊表詳解及hive實現拉鍊表

前言

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

全文由下面幾個部分組成：
先分享一下拉鍊表的用途、什麼是拉鍊表。
通過一些小的使用場景來對拉鍊表做近一步的闡釋，以及拉鍊表和常用的切片表的區別。
舉一個具體的應用場景，來設計並實現一份拉鍊表，最後並通過一些例子說明如何使用我們設計的這張表（因爲現在Hive的大規模使用，我們會以Hive場景下的設計爲例）。
分析一下拉鍊表的優缺點，並對前面的提到的一些內容進行補充說明，比如說拉鍊表和流水錶的區別。

1、什麼是拉鍊表

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

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

可以使用冒號來定義表格的對齊方式，如下：

註冊日期	用戶編號	手機號碼	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	432432	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

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

拉鍊表的使用場景

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

有一些表的數據量很大，比如一張用戶表，大約10億條記錄，50個字段，這種表，即使使用ORC壓縮，單張表的存儲也會超過100G，在HDFS使用雙備份或者三備份的話就更大一些。
表中的部分字段會被update更新操作，如用戶聯繫方式，產品的描述信息，訂單的狀態等等。
需要查看某一個時間點或者時間段的歷史快照信息，比如，查看某一個訂單在歷史某一個時間點的狀態。
表中的記錄變化的比例和頻率不是很大，比如，總共有10億的用戶，每天新增和發生變化的有200萬左右，變化的比例佔的很小。
那麼對於這種表我該如何設計呢？下面有幾種方案可選：

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

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

方案一

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

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

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

方案二

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

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

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

拉鍊表

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

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

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

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

0x02 拉鍊表的設計和實現

如何設計一張拉鍊表

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

我們接上在《漫談數據倉庫之維度建模》中的電商網站的例子，現在以用戶的拉鍊表來說明。

我們先看一下在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
說明

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’。（此處要好好理解，是拉鍊表比較重要的一塊。）
在Hive中實現拉鍊表

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

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

我們需要一張ODS層的用戶全量表。至少需要用它來初始化。
每日的用戶更新表。
而且我們要確定拉鍊表的時間粒度，比如說拉鍊表每天只取一個狀態，也就是說如果一天有3個狀態變更，我們只取最後一個狀態，這種天粒度的表其實已經能解決大部分的問題了。

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

我們可以監聽Mysql數據的變化，比如說用Canal，最後合併每日的變化，獲取到最後的一個狀態。
假設我們每天都會獲得一份切片數據，我們可以通過取兩天切片數據的不同來作爲每日更新表，這種情況下我們可以對所有的字段先進行concat，再取md5，這樣就ok了。
流水錶！有每日的變更流水錶。
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

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

拉鍊表和流水錶

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

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

查詢性能

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

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

hive數據庫設計中的拉鍊表、增量表、全量表

置頂2018年03月19日 23:03:27

閱讀數：1321

1) 存量、流量、增量

（1）存量：系統在某一時點時的所保有的數量；
（2）流量：是指在某一段時間內流入/出系統的數量
（3）增量：則是指在某一段時間內系統中保有數量的變化
（4）增量=流入量--流出量
（5）本期期末存量=上期期末存量+本期內增量

2) 拉鍊表：注意事項
（1）記錄一個事物從開始，一直到當前狀態的所有變化的信息；
（2）拉鍊表每次上報的都是歷史記錄的最終狀態，是記錄在當前時刻的歷史總量；
（3）當前記錄存的是當前時間之前的所有歷史記錄的最後變化量（總量）；
（4）存量是在某一時刻的總量；
（5）存量一般設計成拉鍊表（月報-常用、日報）；
（6）流量和存量的區別：流量是增量；存量是總量；
（7）封鏈時間可以是2999，3000，9999等等比較大的年份；拉鍊表到期數據要報0；
（8）拉鍊表和增量表的共同點：表結構基本一樣。

3) 拉鍊表：例子詳解

4) 增量表：注意事項
（1）記錄每次增加的量，而不是總量；
（2）流量是指在一定時間內的增量；
（3）流量一般設計成增量表（日報-常用、月報）；
（4）流量和存量的區別：流量是增量；存量是總量；
（5）增量表，只報變化量，無變化不用報

5) 增量表：例子詳解（增量表只有上報時間，開始時間更改爲上報時間）

6) 全量表：注意事項
（1）全量表，有無變化，都要報
（2）每次上報的數據都是所有的數據（變化的 + 沒有變化的）

7) 全量表：例子詳解（全量表只有上報時間，開始時間更改爲上報時間）

轉載自：https://blog.csdn.net/weixin_40444678/article/details/81083614

數據倉庫中的拉鍊表詳解及hive實現拉鍊表

數據倉庫中的拉鍊表詳解及hive實現拉鍊表

1、什麼是拉鍊表

hive數據庫設計中的拉鍊表、增量表、全量表

再談23種設計模式（3）：行爲型模式（學習筆記）

Power Automate Desktop 安裝完，登錄後老是提示one driver 錯誤

微前端學習筆記(4):從微前端到微模塊之EMP與hel-micro方案探索

微前端學習筆記（1）：微前端總體架構概述，從微服務發微

985 碩士程序員，空窗 4 個月沒有 Offer！

一文搞懂 Spring 循環依賴

賽博鬥地主——使用大語言模型扮演Agent智能體玩牌類遊戲。

VScode右鍵打開(添加到右鍵)

記一次 .NET某工控視覺自動化系統卡死分析

WindowsServer--SQL Server搭建主從同步實現讀寫分離 - 事務性分發

數據倉庫常用表整理

數據倉庫中的拉鍊表詳解及hive實現拉鍊表

aix的topas命令詳解，有圖有真相！

IOS開發視頻，輕鬆入門，百度雲下載地址

一套價值8800元的EXCEL教程,希望下載的都能有所幫助

Mac下配置sublime實現LaTeX

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結