通俗易懂講數據倉庫之【緩慢變化維】

寫在前面： 博主是一名軟件工程系大數據應用開發專業大二的學生，暱稱來源於《愛麗絲夢遊仙境》中的Alice和自己的暱稱。作爲一名互聯網小白，寫博客一方面是爲了記錄自己的學習歷程，一方面是希望能夠幫助到很多和自己一樣處於起步階段的萌新。由於水平有限，博客中難免會有一些錯誤，有紕漏之處懇請各位大佬不吝賜教！個人小站:http://alices.ibilibili.xyz/ , 博客主頁:https://alice.blog.csdn.net/
儘管當前水平可能不及各位大佬，但我還是希望自己能夠做得更好，因爲一天的生活就是一生的縮影。我希望在最美的年華，做最好的自己！

本篇博客，博主爲大家帶來的是關於數據倉庫中一個非常重要的知識點緩慢變化維的講解!

碼字不易，先贊後看

文章目錄

緩慢變化維

1. 什麼是緩慢變化維(SCD)

2. SCD問題的幾種解決方案

小結

緩慢變化維

1. 什麼是緩慢變化維(SCD)

1.1 緩慢變化維簡介

緩慢變化維，簡稱SCD（Slowly Changing Dimensions）
一些維度表的數據不是靜態的，而是會隨着時間而緩慢地變化（這裏的緩慢是相對事實表而言，事實表數據變化的速度比維度錶快）
這種隨着時間發生變化的維度稱之爲緩慢變化維
把處理維度表數據歷史變化的問題，稱爲緩慢變化維問題，簡稱SCD問題

1.2 舉例說明

例如：用根據用戶維度，統計不同出生年份的消費金額佔比。（80後、90後、00後）。

        而期間，用戶可能去修改用戶數據，例如：將出生日期改成了 1992年。此時，用戶維度表就發生了變化。當然這個變化相對事實表的變換要慢。但這個用戶維度表的變化，就是緩慢變化維。

        這個用戶的數據不是一直不變，而是有可能發生變化。例如：用戶修改了出生日期、或者用戶修改了住址。

2. SCD問題的幾種解決方案

以下爲解決緩慢變化維問題的幾種辦法：

保留原始值
改寫屬性值
增加維度新行
增加維度新列
添加歷史表

SCD解決方案 - 保留原始值

某一個屬性值絕不會變化。事實表始終按照該原始值進行分組。例如：
出生日期的數據，始終按照用戶第一次填寫的數據爲準。

SCD解決方案 - 改寫屬性值

對其相應需要重寫維度行中的舊值，以當前值替換。因此其始終反映最近的情況。
當一個維度值的數據源發生變化，並且不需要在維度表中保留變化歷史時，通常用新數據來覆蓋舊數據。這樣的處理使屬性所反映的中是最新的賦值。

例如：
用戶維度表

修改前：

修改後：

這種方法有個前提，用戶不關心這個數據的變化
這樣處理，易於實現，但是沒有保留歷史數據，無法分析歷史變化信息

SCD解決方案 - 增加維度新行

數據倉庫系統的目標之一是正確地表示歷史。典型代表就是拉鍊表。

保留歷史的數據，並插入新的數據。

例如：
用戶維度表

修改前：

修改後：

SCD解決方案 - 增加維度新列

用不同的字段來保存不同的值，就是在表中增加一個字段，這個字段用來保存變化後的當前值，而原來的值則被稱爲變化前的值。總的來說，這種方法通過添加字段來保存變化後的痕跡。

例如：
用戶維度表

修改前：
修改後：

SCD解決方案 - 使用歷史表

另外建一個表來保存歷史記錄，這種方式就是將歷史數據與當前數據完全分開來，在維度中只保存當前最新的數據。

用戶維度表

用戶維度歷史表

這種方式的優點是可以同時分析當前及前一次變化的屬性值，缺點是隻保留了最後一次變化信息。

3. 數倉項目-拉鍊表技術介紹

數據倉庫的數據模型設計過程中，經常會遇到這樣的需求：

表中的部分字段會被update，例如：

用戶的地址，產品的描述信息，品牌信息等等;

需要查看某一個時間點或者時間段的歷史快照信息，例如：

查看某一個產品在歷史某一時間點的狀態

查看某一個用戶在過去某一段時間內，更新過幾次等等

變化的比例和頻率不是很大，例如：

總共有1000萬的會員，每天新增和發生變化的有10萬左右

相信大家看到這裏，可能對拉鍊表技術已經實現的效果可能不太清楚，下面將通過一個案例爲大家進行演示實現拉鍊表的具體操作。

4. 商品歷史快照案例

需求：
有一個商品表：

2019年12月20日的數據如下所示：

商品的狀態，會隨着時間推移而變化，我們需要將商品的所有變化的歷史信息都保存下來。如何實現呢？

4.1 使用拉鍊表保存歷史快照思路

拉鍊表不存儲冗餘的數據，只有某行的數據發生變化，才需要保存下來，相比每次全量同步會節省存儲空間。
能夠查詢到歷史快照
額外的增加了兩列（dw_start_date、dw_end_date），爲數據行的生命週期

12月20日商品拉鍊表的數據：

12月20日的數據是全新的數據導入到dw表

dw_start_date表示某一條數據的生命週期起始時間，即數據從該時間開始有效（即生效日期）

dw_end_date表示某一條數據的生命週期結束時間，即數據到這一天（不包含）（即失效日期）

dw_end_date爲9999-12-31，表示當前這條數據是最新的數據，數據到9999-12-31才過期

12月21日商品拉鍊表的數據

可以發現：

拉鍊表中沒有存儲冗餘的數據，（只要數據沒有變化，無需同步）
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日商品拉鍊表的數據

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

4.2 拉鍊表存儲歷史快照代碼實現

操作步驟：

在原有dw層表上，添加額外的兩列

生效日期（dw_start_date）
失效日期（dw_end_date）

只同步當天修改的數據到ods層
拉鍊表算法實現

編寫SQL處理當天最新的數據（新添加的數據和修改過的數據）

編寫SQL處理dw層歷史數據，重新計算之前的dw_end_date

拉鍊表的數據爲：當天最新的數據 UNION ALL 歷史數據

4.3 具體實現

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層建表

-- 創建表
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日數據

1、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');

2、使用Kettle進行全量同步MySQL數據到Hive ods層表

關於如何使用Kettle同步數據的操作博主已經在上面一篇博客大數據實戰【千億級數倉】階段二詳細說明了，感興趣的朋友可以去看看。

創建Hive分區

-- 創建分區
alter table `demo`.`ods_product_2` add if not exists partition (dt='${dt}');

表輸入

SELECT
*
FROM t_product_2
where modifytime <= '${dt}'

3、編寫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日數據
1、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');

2、使用Kettle開發增量同步MySQL數據到Hive ods層表

Hive創建分區

-- 創建分區
alter table `demo`.`ods_product_2` add if not exists partition (dt='${dt}');

表輸入讀取MySQL數據

SELECT
*
FROM t_product_2
where modifytime = '${dt}'

3、編寫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

4、合併當天最新的數據和歷史數據到dw層

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;

到這裏，我們的拉鍊表的操作就完了，接下來讓我們來進行一些查詢來驗證效果。

查詢拉鍊表

1、獲取2019-12-20日的歷史快照數據

select * from demo.dw_product_2 where dw_start_date <= '2019-12-20' and dw_end_date > '2019-12-20' order by goods_id;

2、獲取最新的商品快照數據

select * from demo.dw_product_2 where dw_end_date = '9999-12-31' order by goods_id;

感謝看到這裏的朋友，爲你們的學習精神點贊👍

小結

本篇博客爲大家詳細介紹了大數據數據倉庫中一個非常重要的概念——緩慢變化維，以及講述了一個簡單的入門案例。

如果以上過程中出現了任何的紕漏錯誤，煩請大佬們指正😅

受益的朋友或對大數據技術感興趣的夥伴記得點贊關注支持一波🙏

通俗易懂講數據倉庫之【緩慢變化維】

文章目錄

緩慢變化維

1. 什麼是緩慢變化維(SCD)

1.1 緩慢變化維簡介

1.2 舉例說明

2. SCD問題的幾種解決方案

SCD解決方案 - 保留原始值

SCD解決方案 - 改寫屬性值

SCD解決方案 - 增加維度新行

SCD解決方案 - 增加維度新列

SCD解決方案 - 使用歷史表

3. 數倉項目-拉鍊表技術介紹

4. 商品歷史快照案例

4.1 使用拉鍊表保存歷史快照思路

4.2 拉鍊表存儲歷史快照代碼實現

4.3 具體實現

小結

MySQL 核心模塊揭祕 | 18 期 | 鎖在內存里長什麼樣*

使用perf工具生成火焰圖

HttpSecurity 是如何組裝過濾器鏈的

數說海南——近6年海南各市縣人口簡單看

長序列中Transformers的高級注意力機制總結

WebStorm 創建 Vue 項目

大齡程序員思考

響應式界面控件DevExtreme * 更強的數據分析和可視化功能

【學點數據結構和算法】06-二叉堆和優先隊列

大數據【企業級360°全方位用戶畫像】基於USG模型的挖掘型標籤開發

【學點數據結構和算法】05-樹

大數據【企業級360°全方位用戶畫像】之USG模型和決策樹分類算法

【學點數據結構和算法】03-棧和隊列

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

linux以太網驅動總結