目錄
-
介紹
緩慢變化維，簡稱SCD（Slowly Changing Dimensions）
一些維度表的數據不是靜態的，而是會隨着時間而緩慢地變化（這裏的緩慢是相對事實表而言，事實表數據變化的速度比維度錶快）
這種隨着時間發生變化的維度稱之爲緩慢變化維
把處理維度表數據歷史變化的問題，稱爲緩慢變化維問題，簡稱SCD問題
-
舉例說明
用根據用戶維度，統計不同出生年份的消費金額佔比。（80後、90後、00後）。
而期間，用戶可能去修改用戶數據，例如：將出生日期改成了 1992年。此時，用戶維度表就發生了變化。當然這個變化相對事實表的變換要慢。但這個用戶維度表的變化，就是緩慢變化維。
|
用戶ID |
用戶名 |
出生日期 |
住址 |
|
114 |
張三 |
1988-09-08 |
北京市朝陽區 |
這個用戶的數據不是一直不變，而是有可能發生變化。例如：用戶修改了出生日期、或者用戶修改了住址。
-
SCD問題的幾種解決方案
保留原始值（不推薦）
某一個屬性值絕不會變化。事實表始終按照該原始值進行分組。例如：出生日期的數據，始終按照用戶第一次填寫的數據爲準
改寫屬性值（不推薦）
對其相應需要重寫維度行中的舊值，以當前值替換。因此其始終反映最近的情況。
當一個維度值的數據源發生變化，並且不需要在維度表中保留變化歷史時，通常用新數據來覆蓋舊數據。這樣的處理使屬性所反映的中是最新的賦值。
修改前：
|
用戶ID |
用戶名 |
出生日期 |
住址 |
|
114 |
張三 |
1988-09-08 |
北京市朝陽區 |
修改後：
|
用戶ID |
用戶名 |
出生日期 |
住址 |
|
114 |
張三 |
1992-09-08 |
北京市海淀區 |
這種方法有個前提，用戶不關心這個數據的變化
這樣處理，易於實現，但是沒有保留歷史數據，無法分析歷史變化信息
增加維度新行（推薦）
數據倉庫系統的目標之一是正確地表示歷史記錄。典型代表就是拉鍊表。保留歷史的數據，並插入新的數據。
修改前：
|
用戶ID |
用戶名 |
出生日期 |
住址 |
|
|
9527 |
114 |
張三 |
1988-09-08 |
北京市朝陽區 |
修改後：
|
編號 |
用戶ID |
用戶名 |
出生日期 |
住址 |
|
9527 |
114 |
張三 |
1988-09-08 |
北京市朝陽區 |
|
9528 |
114 |
張三 |
1992-09-08 |
北京市海淀區 |
增加維度新列（不推薦）
用不同的字段來保存不同的值，就是在表中增加一個字段，這個字段用來保存變化後的當前值，而原來的值則被稱爲變化前的值。總的來說，這種方法通過添加字段來保存變化後的痕跡。
修改前：
|
編號 |
用戶ID |
用戶名 |
出生日期 |
住址 |
|
9527 |
114 |
張三 |
1988-09-08 |
北京市朝陽區 |
修改後：
|
編號 |
用戶ID |
用戶名 |
出生日期 |
住址 |
現住址 |
|
|
9527 |
114 |
張三 |
1988-09-08 |
1992-09-08 |
北京市朝陽區 |
北京市海淀區 |
添加歷史表（不推薦）
另外建一個表來保存歷史記錄，這種方式就是將歷史數據與當前數據完全分開來，在維度中只保存當前最新的數據。
用戶維度表：
|
編號 |
用戶ID |
用戶名 |
出生日期 |
住址 |
|
9527 |
114 |
張三 |
1992-09-08 |
北京市海淀區 |
用戶維度歷史表：
|
編號 |
用戶ID |
用戶名 |
出生日期 |
住址 |
|
9537 |
114 |
張三 |
1988-09-02 |
北京市朝陽區 |
|
9527 |
114 |
張三 |
1992-09-08 |
北京市海淀區 |
這種方式的優點是可以同時分析當前及前一次變化的屬性值，缺點是隻保留了最後一次變化信息並且後期查詢時候可能需要關聯多張表。
-
使用拉鍊表保存歷史快照思路
拉鍊表
拉鍊表不存儲冗餘的數據，只有某行的數據發生變化，才需要保存下來，相比每次全量同步會節省存儲空間
能夠查詢到歷史快照
額外的增加了兩列（dw_start_date、dw_end_date），爲數據行的生命週期
12月20日商品拉鍊表的數據（全量數據同步）：
|
goods_id |
goods_status |
createtime |
modifytime |
dw_start_date |
dw_end_date |
|
001 |
待審覈 |
2019-12-18 |
2019-12-20 |
2019-12-20 |
9999-12-31 |
|
002 |
待售 |
2019-12-19 |
2019-12-20 |
2019-12-20 |
9999-12-31 |
|
003 |
在售 |
2019-12-20 |
2019-12-20 |
2019-12-20 |
9999-12-31 |
|
004 |
已刪除 |
2019-12-15 |
2019-12-20 |
2019-12-20 |
9999-12-31 |
12月20日的數據是全新的數據導入到dw表
dw_start_date：表示某一條數據的生命週期起始時間，即數據從該時間開始有效（即生效日期）
dw_end_date：表示某一條數據的生命週期結束時間，即數據到這一天（不包含）（即失效日期）
dw_end_date爲9999-12-31，表示當前這條數據是最新的數據，數據到9999-12-31才過期
12月21日商品拉鍊表的數據（增量數據同步）
|
goods_id |
goods_status |
createtime |
modifytime |
dw_start_date |
dw_end_date |
|
001 |
待審覈 |
2019-12-18 |
2019-12-20 |
2019-12-20 |
2019-12-21 |
|
002 |
待售 |
2019-12-19 |
2019-12-20 |
2019-12-20 |
9999-12-31 |
|
003 |
在售 |
2019-12-20 |
2019-12-20 |
2019-12-20 |
9999-12-31 |
|
004 |
已刪除 |
2019-12-15 |
2019-12-20 |
2019-12-20 |
9999-12-31 |
|
001（變） |
待售 |
2019-12-18 |
2019-12-21 |
2019-12-21 |
9999-12-31 |
|
005（新） |
待審覈 |
2019-12-21 |
2019-12-21 |
2019-12-21 |
9999-12-31 |
|
006（新） |
待審覈 |
2019-12-21 |
2019-12-21 |
2019-12-21 |
9999-12-31 |
拉鍊表中沒有存儲冗餘的數據，（只要數據沒有變化，無需同步）
001編號的商品數據的狀態發生了變化（從待審覈 → 待售），需要將原有的dw_end_date從9999-12-31變爲2019-12-21，表示待審覈狀態，在2019/12/20（包含） - 2019/12/21（不包含）有效
001編號新的狀態重新保存了一條記錄，dw_start_date爲2019/12/21，dw_end_date爲9999/12/31
新數據005、006、dw_start_date爲2019/12/21，dw_end_date爲9999/12/31
12月22日商品拉鍊表的數據（增量數據同步）
|
goods_id |
goods_status |
createtime |
modifytime |
dw_start_date |
dw_end_date |
|
001 |
待審覈 |
2019-12-18 |
2019-12-20 |
2019-12-20 |
2019-12-21 |
|
002 |
待售 |
2019-12-19 |
2019-12-20 |
2019-12-20 |
9999-12-31 |
|
003 |
在售 |
2019-12-20 |
2019-12-20 |
2019-12-20 |
2019-12-22 |
|
004 |
已刪除 |
2019-12-15 |
2019-12-20 |
2019-12-20 |
9999-12-31 |
|
001 |
待售 |
2019-12-18 |
2019-12-21 |
2019-12-21 |
9999-12-31 |
|
005 |
待審覈 |
2019-12-21 |
2019-12-21 |
2019-12-21 |
9999-12-31 |
|
006 |
待審覈 |
2019-12-21 |
2019-12-21 |
2019-12-21 |
9999-12-31 |
|
003（變） |
已刪除 |
2019-12-20 |
2019-12-22 |
2019-12-22 |
9999-12-31 |
|
007（新） |
待審覈 |
2019-12-22 |
2019-12-22 |
2019-12-22 |
9999-12-31 |
|
008（新） |
待審覈 |
2019-12-22 |
2019-12-22 |
2019-12-22 |
9999-12-31 |
003編號的商品數據的狀態發生了變化（從在售→已刪除），需要將原有的dw_end_date從9999-12-31變爲2019-12-22，表示在售狀態，在2019/12/20（包含） - 2019/12/22（不包含）有效
003編號新的狀態重新保存了一條記錄，dw_start_date爲2019/12/22，dw_end_date爲9999/12/31
新數據007、008、dw_start_date爲2019/12/22，dw_end_date爲9999/12/31
-
拉鍊表存儲歷史快照代碼實現
操作步驟：
1.在原有dw層表上，添加額外的兩列
生效日期（dw_start_date）
失效日期（dw_end_date）
2.只同步當天修改的數據到ods層
3.拉鍊表算法實現
編寫SQL處理當天最新的數據（新添加的數據和修改過的數據）
編寫SQL處理dw層歷史數據，重新計算之前的dw_end_date
4.拉鍊表的數據爲：當天最新的數據 UNION ALL 歷史數據
MySQL&Hive表初始化
MySQL創建商品表
-- 創建數據庫
CREATE DATABASE IF NOT EXISTS demo;
-- 創建商品表
CREATE TABLE IF NOT EXISTS `demo`.`t_product_2`(
goods_id VARCHAR(50), -- 商品編號
goods_status VARCHAR(50), -- 商品狀態
createtime VARCHAR(50), -- 商品創建時間
modifytime VARCHAR(50) -- 商品修改時間
);
Hive ODS層建表
因爲我們是模擬拉鍊表存儲的實現，所以我們直接創建兩個表來表示ODS層到DW層的過程
-- 創建表
create database if not exists `demo`;
-- 創建ods層表
create table if not exists `demo`.`ods_product_2`(
goods_id string, -- 商品編號
goods_status string, -- 商品狀態
createtime string, -- 商品創建時間
modifytime string -- 商品修改時間
)
partitioned by (dt string)
row format delimited fields terminated by ',' stored as TEXTFILE;
Hive dw層創建拉鍊表
-- 創建拉鍊表
create table if not exists `demo`.`dw_product_2`(
goods_id string, -- 商品編號
goods_status string, -- 商品狀態
createtime string, -- 商品創建時間
modifytime string, -- 商品修改時間
dw_start_date string, -- 生效日期
dw_end_date string -- 失效日期
)
row format delimited fields terminated by ',' stored as TEXTFILE;
全量導入2019年12月20日數據
MySQL數據庫導入12月20日數據（4條數據）
insert into `demo`.`t_product_2`(goods_id, goods_status, createtime, modifytime) values
('001', '待審覈', '2019-12-18', '2019-12-20'),
('002', '待售', '2019-12-19', '2019-12-20'),
('003', '在售', '2019-12-20', '2019-12-20'),
('004', '已刪除', '2019-12-15', '2019-12-20');
使用Kettle進行全量同步MySQL數據到Hive ods層表
編寫SQL從ods導入dw當天最新的數據
-- 從ods層導入dw當天最新數據
insert overwrite table `demo`.`dw_product_2`
select
goods_id, -- 商品編號
goods_status, -- 商品狀態
createtime, -- 商品創建時間
modifytime, -- 商品修改時間
modifytime as dw_start_date, -- 生效日期
'9999-12-31' as dw_end_date -- 失效日期
from
`demo`.`ods_product_2`
where
dt = '2019-12-20';
增量導入2019年12月21日數據
MySQL數據庫導入12月21日數據（6條數據）
UPDATE `demo`.`t_product_2` SET goods_status = '待售', modifytime = '2019-12-21' WHERE goods_id = '001';
INSERT INTO `demo`.`t_product_2`(goods_id, goods_status, createtime, modifytime) VALUES
('005', '待審覈', '2019-12-21', '2019-12-21'),
('006', '待審覈', '2019-12-21', '2019-12-21');
使用Kettle開發增量同步MySQL數據到Hive ods層表
編寫SQL處理dw層歷史數據，重新計算之前的dw_end_date
-- 重新計算dw層拉鍊表中的失效時間
select
t1.goods_id, -- 商品編號
t1.goods_status, -- 商品狀態
t1.createtime, -- 商品創建時間
t1.modifytime, -- 商品修改時間
t1.dw_start_date, -- 生效日期（生效日期無需重新計算）
case when (t2.goods_id is not null and t1.dw_end_date > '2019-12-21')
then '2019-12-21'
else t1.dw_end_date -- 小的是以前修改的，不用修改，只修改9999-12-31的數據
end as dw_end_date -- 更新生效日期（需要重新計算）
from
`demo`.`dw_product_2` t1
left join
(select * from `demo`.`ods_product_2` where dt='2019-12-21') t2
on t1.goods_id = t2.goods_id;
合併當天最新的數據和歷史數據覆蓋到hive中
insert overwrite table `demo`.`dw_product_2`
select
t1.goods_id, -- 商品編號
t1.goods_status, -- 商品狀態
t1.createtime, -- 商品創建時間
t1.modifytime, -- 商品修改時間
t1.dw_start_date, -- 生效日期（生效日期無需重新計算）
case when (t2.goods_id is not null and t1.dw_end_date > '2019-12-21')
then '2019-12-21'
else t1.dw_end_date
end as dw_end_date -- 更新生效日期（需要重新計算）
from
`demo`.`dw_product_2` t1
left join
(select * from `demo`.`ods_product_2` where dt='2019-12-21') t2
on t1.goods_id = t2.goods_id
union all
select
goods_id, -- 商品編號
goods_status, -- 商品狀態
createtime, -- 商品創建時間
modifytime, -- 商品修改時間
modifytime as dw_start_date, -- 生效日期
'9999-12-31' as dw_end_date -- 失效日期
from
`demo`.`ods_product_2` where dt='2019-12-21' -- 只有新增和修改的數據
order by dw_start_date, goods_id;
查詢拉鍊表
查詢dw_product_2表
select * from dw_product_2;
