【資料倉庫】3. 拉鍊表
0x00 前言
過了半年時間，對資料倉庫的理解又有了一些不同的認識，翻出來之前寫的關於拉鍊表的內容，稍作修改重新發出來。本篇將會談一談在資料倉庫中拉鍊表相關的內容，包括它的原理、設計、以及在我們大資料場景下的實現方式。
內容
全文由下面幾個部分組成：
-
先分享一下拉鍊表的用途、什麼是拉鍊表。
-
舉一個具體的應用場景，來設計並實現一份拉鍊表，最後並通過一些例子說明如何使用我們設計的這張表（因為現在 Hive 的大規模使用，我們會以 Hive 場景下的設計為例）。
-
分析一下拉鍊表的優缺點，並對前面的提到的一些內容進行補充說明，比如說拉鍊表和流水錶的區別。
0x01 什麼是拉鍊表
拉鍊表是針對資料倉庫設計中表儲存資料的方式而定義的，顧名思義，所謂拉鍊，就是記錄歷史。記錄一個事物從開始，一直到當前狀態的所有變化的資訊。
我們先看一個示例，這就是一張拉鍊表，儲存的是使用者的最基本資訊以及每條記錄的生命週期。我們可以使用這張表拿到當天的最新資料以及之前的歷史資料。
我們暫且不對這張表做細緻的講解，後文會專門來闡述怎麼來設計、實現和使用它。
拉鍊表的使用場景
在資料倉庫的資料模型設計過程中，經常會遇到下面這種表的設計：
-
有一些表的資料量很大，比如一張使用者表，大約 10 億條記錄，50 個欄位，這種表，即使使用 Orc 壓縮，單張表的儲存也會超過 100G，在 Hdfs 使用雙備份或者三備份的話就更大一些。
-
表中的部分欄位會被 Update 更新操作，如使用者聯絡方式，產品的描述資訊，訂單的狀態等等。
-
需要檢視某一個時間點或者時間段的歷史快照資訊，比如，檢視某一個訂單在歷史某一個時間點的狀態。
-
表中的記錄變化的比例和頻率不是很大，比如，總共有 10 億的使用者，每天新增和發生變化的有 200 萬左右，變化的比例佔的很小。
那麼對於這種表我該如何設計呢？下面有幾種方案可選：
-
方案一：每天只留最新的一份，比如我們每天用 Sqoop 抽取最新的一份全量資料到 Hive 中。
-
方案二：每天保留一份全量的切片資料。
-
方案三：使用拉鍊表。
為什麼使用拉鍊表
現在我們對前面提到的三種進行逐個的分析。
方案一
這種方案就不用多說了，實現起來很簡單，每天 Drop 掉前一天的資料，重新抽一份最新的。
優點很明顯，節省空間，一些普通的使用也很方便，不用在選擇表的時候加一個時間分割槽什麼的。
缺點同樣明顯，沒有歷史資料，先翻翻舊賬只能通過其它方式，比如從流水錶裡面抽。
方案二
每天一份全量的切片是一種比較穩妥的方案，而且歷史資料也在。
缺點就是儲存空間佔用量太大太大了，如果對這邊表每天都保留一份全量，那麼每次全量中會儲存很多不變的資訊，對儲存是極大的浪費。
當然我們也可以做一些取捨，比如只保留近一個月的資料。但是，需求是無恥的，資料的生命週期不是我們能完全左右的，你會發現，儲存週期可能會從 30 天變為 90 天，然後再從 90 天變為 1 年，然後需要永久儲存。
拉鍊表
拉鍊表在使用上基本兼顧了我們的需求。
首先它在空間上做了一個取捨，雖說不像方案一那樣佔用量那麼小，但是它每日的增量可能只有方案二的千分之一甚至是萬分之一。
其實它能滿足方案二所能滿足的需求，既能獲取最新的資料，也能新增篩選條件也獲取歷史的資料。所以在一些場景下，拉鍊表是能解決很多問題的。
0x02 拉鍊表的設計和實現
如何設計一張拉鍊表
下面我們來舉個栗子詳細聊一下拉鍊表。以使用者資料表為例，我們先看一下在關係型資料庫裡的 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'。（此處要好好理解，是拉鍊表比較重要的一塊。）
在Hive中實現拉鍊表
在現在的大資料場景下，大部分的公司都會選擇以 Hdfs 和 Hive 為主的資料倉庫架構。目前的 Hdfs 版本來講，其檔案系統中的檔案是不能做改變的，也就是說 Hive 的表只能進行刪除和新增操作，而不能進行 update。基於這個前提，我們來實現拉鍊表。
還是以上面的使用者表為例，我們要實現使用者的拉鍊表。在實現它之前，我們需要先確定一下我們有哪些資料來源可以用。
-
我們需要一張 Ods 層的使用者全量表。至少需要用它來初始化。
-
每日的使用者更新表。
而且我們要確定拉鍊表的時間粒度，比如說拉鍊表每天只取一個狀態，也就是說如果一天有 3 個狀態變更，我們只取最後一個狀態，這種天粒度的表其實已經能解決大部分的問題了。
另外，補充一下每日的使用者更新表該怎麼獲取，據筆者的經驗，有3種方式拿到或者間接拿到每日的使用者增量，因為它比較重要，所以詳細說明：
-
我們可以監聽 Mysql 庫資料的變化，比如說用 Canal，最後合併每日的變化，獲取到最後的一個狀態。
-
假設我們每天都會獲得一份切片資料，我們可以通過取兩天切片資料的不同來作為每日更新表，這種情況下我們可以對所有的欄位先進行 concat，再取 md5，這樣就 ok 了。
-
流水錶！有每日的變更流水錶。
Ods 層的 User表
現在我們來看一下我們 Ods 層的使用者資料切片表的結構：
Ods 層的 User_update 表
然後我們還需要一張使用者每日更新表，前面已經分析過該如果得到這張表，現在我們假設它已經存在。
拉鍊表
現在我們建立一張拉鍊表：
實現 Sql 語句
然後初始化的 Sql 就不寫了，其實就相當於是拿一天的 Ods 層使用者表過來就行，我們寫一下每日的更新語句。
現在我們假設我們已經已經初始化了 2017-01-01 的日期，然後需要更新 2017-01-02 那一天的資料，我們有了下面的 Sql。
然後把兩個日期設定為變數就可以了。
0x03 補充
好了，我們分析了拉鍊表的原理、設計思路、並且在 Hive 環境下實現了一份拉鍊表，下面對拉鍊表做一些小的補充。
拉鍊表和流水錶
流水錶存放的是一個使用者的變更記錄，比如在一張流水錶中，一天的資料中，會存放一個使用者的每條修改記錄，但是在拉鍊表中只有一條記錄。
這是拉鍊表設計時需要注意的一個粒度問題。我們當然也可以設定的粒度更小一些，一般按天就足夠。
查詢效能
拉鍊表當然也會遇到查詢效能的問題，比如說我們存放了5年的拉鍊資料，那麼這張表勢必會比較大，當查詢的時候效能就比較低了，個人認為兩個思路來解決：
-
在一些查詢引擎中，我們對 start_date 和 end_date 做索引，這樣能提高不少效能。這種方法其實在 Hive 中行不通，因為 Hive 相當於沒有索引，不過在其它系統中可以考慮。
-
保留部分歷史資料，比如說我們一張表裡面存放全量的拉鍊表資料，然後再對外暴露一張只提供近 3 個月資料的拉鍊表。
淘汰機制
關於淘汰機制，其實和效能也是有關係的，一方面是因為所有資料的積累會導致計算越來越慢，另一方面是業務側其實對歷史資料的需求也有一定的優先順序的。
因此在設計拉鍊表的時候可以制定一些資料的淘汰機制。淘汰的資料不一定要刪除，比如我們建立兩張拉鍊表，一張拉鍊表中只儲存最新的十條資料，其它的資料會存入一張歷史拉鍊表中。
轉載