緩慢變化維

說到歷史拉鏈表，首先得說下緩慢變化維。

在現實世界中，維度的屬性并不是靜態的，而是隨著時間的變化而變化，這也體現了數據倉庫的特點之一，是反映歷史變化的。相對于數據增長較為快速的事實表，維度的變化是相對緩慢的。

在維度建模理論中，處理緩慢變化維有三種方式：

新的維度屬性直接覆蓋舊的維度屬性，不保留歷史數據；

增加新的維度行(需要生成代理鍵來支持)，維度變化前的事實關聯變化前的維度值，維度變化后的事實關聯變化后的維度值。缺點是無法歸一為變化前的維度值或者變化后的維度值進行統計；

增加維度列，即針對維度的某一屬性時，在設計表時需要至少包含兩列，新屬性和舊屬性。優點是可以根據業務需求進行不同的歸一化處理，缺點是擴展性不好，保留的維度歷史數據有限。

歷史拉鏈表

而歷史拉鏈存儲恰恰是對第二種方式的一種升級，同樣是以增加新的維度行來實現，不同的是使用時間鍵來代替代理鍵。時間鍵包含兩個字段，開始時間和結束時間，一般以天為粒度保留變更的維度數據。

查詢方式

• 查詢當前最新狀態維度數據：select * from table_name where end_day = ‘30001231’
• 查詢某一天的維度狀態數據：select * from table_name where start_day <= ‘20200201’ and end_day > '20200201'

加工方式

假設商品歷史拉鏈表(goods_hist)有如下5個字段：goods_id(商品編號)、price(商品價格)、is_on_sale(商品是否在售)、start_day(開始日期)、end_day(結束日期)

商品最新全量快照表(goods_cur)有如下3個字段：goods_id(商品編號)、price(商品價格)、is_on_sale(商品是否在售)，快照日期為20200201

則SQL加工語句為：

WITH hist AS( SELECT goods_id, price, is_on_sale, start_day FROM goods_hist WHERE end_day = 30001231),cur AS( SELECT nvl(goods_id,-1) AS goods_id, nvl(price,-1) AS price, nvl(is_on_sale,-1) AS is_on_sale FROM goods_cur)SELECT nvl(cur.goods_id,hist.goods_id) AS goods_id, nvl(cur.price,hist.price) AS price, nvl(cur.is_on_sale,hist.is_on_sale) AS is_on_sale, nvl(hist.start_day,20200201) AS start_day, CASE WHEN cur.goods_id IS NULL THEN 20200201 ELSE 30001231 END AS end_dayFROM cur FULL OUTER JOIN hist ON cur.goods_id = hist.goods_id AND cur.price = hist.price AND cur.is_on_sale = hist.is_on_sale

SQL語句輸出的結果包括兩部分：

• end_day=30001231的最新狀態維度數據
• end_day=20200201的已失效的維度數據

分區方式

• 方式1(使用start_day作為分區鍵)：缺點是查詢最新數據無法走分區；查詢某一天數據時end_day限制條件無法走分區；加工歷史拉鏈表數據時，end_day=30001231的結果數據不方便入庫
• 方式2(使用end_day作為分區鍵)：缺點是查詢某一天數據時start_day限制條件無法走分區；優點是加工歷史拉鏈表數據時，結果數據入庫方便，直接insert overwrite覆蓋分區30001231和20200201即可
• 方式3(使用start_day和end_day作為聯合分區鍵，start_day為父分區)：查詢最新數據時需要改變下SQL語句，不然無法走分區(比如當前日期是20200401，SQL語句需改為select * from table_name where start_day <= ‘20200401’ and end_day > '20200401'，即查詢某一天數據的寫法)；缺點是加工歷史拉鏈表數據時，end_day=30001231和end_day=20200201的結果數據都不方便入庫；而且分區數會越來越多，一年下來最多可能產生365*364/2=66430個分區；優點是查詢數據時start_day和end_day的限制條件都可以走分區
• 方式4(使用start_day和end_day作為聯合分區鍵，end_day為父分區)：缺點同方式3，但加工歷史拉鏈表數據時，結果數據入庫相對方便(首先將結果數據存入臨時表，然后清空拉鏈表的分區end_day=30001231和end_day=20200201，最后將臨時表數據以insert into方式入庫)；優點同方式3

綜上所述，分區方式可在2和4中選擇。

選擇方式2，需要考慮隨著時間的推移，查詢某一天的維度狀態數據，消耗的計算資源會越來越多。可考慮刪除或者備份部分歷史數據至其他地方。

選擇方式4，需要考慮隨著時間的推移，分區數量會越來越多。可考慮定期重構歷史拉鏈表，比如在每個月月初強制重新開始做歷史拉鏈表(比如在20200401時，先將end_day=30001231的數據修改為end_day=20200401，再基于最新全量快照表生成一份start_day=20200401，end_day=30001231的數據)。

注意點

設計歷史拉鏈表時，需要移除變化頻率高的維度屬性，不然生成新拉鏈的概率會很高，導致無法達到節省存儲的目的。

總結

以上是生活随笔為你收集整理的hive 分区_Hive下数据仓库历史拉链表如何加工，分区键该如何选择的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。