先去看這篇文章：
首先，下面的user表沒有用到。。而且貌似也沒有用，文章中為什麼要user表我也搞不懂。。明明user的拉鍊表可以就包含了user全量表的資料了。。
由於hdfs和hive的底層因素，不支援修改操作。所以修改資料只能先把資料查詢出來，修改完後再覆蓋原本的資料。
我對上述insert sql的理解：
先查詢拉鍊表的資料，修改相關資料為舊的歷史記錄，把每日更新表資料作為新的歷史記錄。然後把結果覆蓋回拉鍊表。
union聯合的兩個select的理解：
1、第乙個select:
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 a
left join ods.user_update b
on a.user_num = b.user_num
我對這個select理解：
（1）條件a.t_end_time = '9999-12-31' ：表示拉鍊表中的舊的有效記錄
（2）dws.user_his a left join ods.user_update b，並且b.user_num is not null ：表示拉鍊表中的該記錄存在與每日更新表中，該記錄的有效日期應該被修改為昨日日期。
總：拉鍊表中的有效記錄 與每日更新表關聯，如果資料存在關聯的，則把該關聯的資料中的t_end_time改為昨日（這裡是：'2017-01-01' ），表示該記錄在昨天失效。。。而新的有效資料則由下乙個select中匯入。
所以，第乙個select是修改拉鍊表舊資料，根據每日更新表的資料，把有效截止日期改為昨日。
2、第二個select
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
根據第乙個select可以知道：已經把原拉鍊表的舊資料有效日期根據每日更新資料一一修改了。
所以當前select就是把每日更新資料作為新的有效資料匯入拉鍊表。
資料倉儲 緩慢漸變維 拉鍊表
緩慢漸變維 維度會隨著時間發生緩慢的變化。處理方式 全量快照 拉鍊表全量快照很簡單，今天我們來看看拉鍊表。拉鍊表是處理緩慢漸變維的一種方式，它區別於正常的表而言，會多兩個字段，start date和end date，代表這條資料的起始時間和結束時間。如 james同學哪天想不開了，他從男的變成了女的...
資料倉儲歷史資料儲存 拉鍊表
假如我們有乙個賬號account表，我們需要在hive中儲存 資料是從線上mysql讀取binlog同步來的，是有明細變化的 account表結構 account id,username,followers count,modified at我們經常使用的儲存方式有快照表和流水表。快照表就是以時間為...
資料倉儲ETL演算法之拉鍊演算法
目錄 拉鍊定義 拉鍊表資料儲存方式 拉鍊的意義 拉鍊演算法詳解 歷史儲存資料的倆種方式 下面用一組業務資料來解釋倆者區別 業務系統2014年1月1日的資料 賬戶id 戶名餘額 001張三 2000 業務系統2014年1月15日的資料 賬戶id 戶名餘額 001張三 2000 業務系統2014年2月1...