深刻講解拉鍊表，還怕面試官問？

時間  2021-01-07
標籤 git 程序員 github 面試 算法 數據庫 app ide oop 大數據 欄目 快樂工作 简体版
原文   原文鏈接


前言

          今天給你們分享一個面試中常常會被問到的拉鍊表，我在上篇文章中提出來一個需求若是不知道的請去→數倉緩慢變化維深層講解查看，好，廢話很少說咱們直接開始。提出的問題會在末尾講解。git

a8818b593774c01f9b30f751afeb16a8.jpg

1、拉鍊表介紹（百度百科）

         拉鍊表：維護歷史狀態，以及最新狀態數據的一種表，拉鍊表根據拉鍊粒度的不一樣，實際上至關於快照，只不過作了優化，去除了一部分不變的記錄，經過拉鍊表能夠很方便的還原出拉鍊時點的客戶記錄程序員

2、拉鍊表場景

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

  1. 表中的部分字段會被update，例如：用戶的地址，產品的描述信息，品牌信息等等;
  2. 須要查看某一個時間點或者時間段的歷史快照信息，例如：查看某一個產品在歷史某一時間點的狀態 查看某一個用戶在過去某一段時間內，更新過幾回等等
  3. 變化的比例和頻率不是很大，例如：總共有1000萬的會員，天天新增和發生變化的有10萬左右

3、商品數據案例

需求：商品表：面試

列名 類型 說明
goods_id varchar(50) 商品編號
goods_status varchar(50) 商品狀態（待審覈、待售、在售、已刪除）
createtime varchar(50) 商品建立日期
modifytime varchar(50) 商品修改日期

2019年12月20日的數據以下所示：算法

goods_id goods_status createtime modifytime
001 待審覈 2019-12-20 2019-12-20
002 待售 2019-12-20 2019-12-20
003 在售 2019-12-20 2019-12-20
004 已刪除 2019-12-20 2019-12-20

         商品的狀態，會隨着時間推移而變化，咱們須要將商品的全部變化的歷史信息都保存下來。如何實現呢？數據庫

方案一: 快照每一天的數據到數倉（圖解）

該方案爲：app

  • 每一天都保存一份全量，將全部數據同步到數倉中（我這裏就使用MySQL操做的）
  • 不少記錄都是重複保存，沒有任何變化

12月20日（4條數據）ide

goods_id goods_status createtime modifytime
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

12月21日（10條數據）oop

goods_id goods_status createtime modifytime
如下爲12月20日快照數據


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
如下爲12月21日快照數據


001   待售（從待審覈到待售） 2019-12-18 2019-12-21
002 待售 2019-12-19 2019-12-20
003 在售 2019-12-20 2019-12-20
004 已刪除 2019-12-15 2019-12-20
005（新商品） 待審覈 2019-12-21 2019-12-21
006（新商品） 待審覈 2019-12-21 2019-12-21

12月22日（18條數據）大數據

goods_id goods_status createtime modifytime
如下爲12月20日快照數據


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
如下爲12月21日快照數據


001 待售（從待審覈到待售） 2019-12-18 2019-12-21
002 待售 2019-12-19 2019-12-20
003 在售 2019-12-20 2019-12-20
004 已刪除 2019-12-15 2019-12-20
005 待審覈 2019-12-21 2019-12-21
006 待審覈 2019-12-21 2019-12-21
如下爲12月22日快照數據


001 待售 2019-12-18 2019-12-21
002 待售 2019-12-19 2019-12-20
003 已刪除（從在售到已刪除） 2019-12-20 2019-12-22
004 待審覈 2019-12-21 2019-12-21
005 待審覈 2019-12-21 2019-12-21
006 已刪除（從待審覈到已刪除） 2019-12-21 2019-12-22
007 待審覈 2019-12-22 2019-12-22
008 待審覈 2019-12-22 2019-12-22

方案一: MySQL到，MySQL數倉代碼實現

MySQL初始化

  1. 在MySQL中zw庫和商品表用於到原始數據層
-- 建立數據庫
create database if not exists zw;
-- 建立商品表
create table if not exists `zw`.`t_product`(
goods_id varchar(50), -- 商品編號
 goods_status varchar(50), -- 商品狀態
 createtime varchar(50), -- 商品建立時間
 modifytime varchar(50) -- 商品修改時間
);
  1. 在MySQL中建立ods和dw層 模擬數倉
-- ods建立商品表
create table if not exists `zw`.`ods_t_product`(
goods_id varchar(50), -- 商品編號
 goods_status varchar(50), -- 商品狀態
 createtime varchar(50), -- 商品建立時間
 modifytime varchar(50), -- 商品修改時間
cdat varchar(10)   --模擬hive分區
)default character set = 'utf8'; ;
-- dw建立商品表
create table if not exists `zw`.`dw_t_product`(
goods_id varchar(50), -- 商品編號
 goods_status varchar(50), -- 商品狀態
 createtime varchar(50), -- 商品建立時間
 modifytime varchar(50), -- 商品修改時間
 cdat varchar(10)  -- 模擬hive分區
)default character set = 'utf8'; ;

增量導入12月20號數據

  1. 原始數據導入12月20號數據（4條）
insert into `zw`.`t_product`(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');

注意：因爲我這裏使用的MySQL來模擬的數倉在這裏偷個懶直接使用insert into的方式導入數據，在企業中可能會使用hive來作數倉使用kettle 或者sqoop或datax等來同步數據

# 從原始數據層導入到ods 層
insert into zw.ods_t_product
select *,'20191220' from zw.t_product ;
# 從ods同步到dw層
insert into zw.dw_t_product
select * from zw.ods_t_product where cdat='20191220';

增量導入12月21數據

  1. 原始數據層導入12月21日數據（6條數據）
UPDATE `zw`.`t_product` SET goods_status = '待售', modifytime = '2019-12-21' WHERE goods_id = '001';
INSERT INTO `zw`.`t_product`(goods_id, goods_status, createtime, modifytime) VALUES
('005', '待審覈', '2019-12-21', '2019-12-21'),
('006', '待審覈', '2019-12-21', '2019-12-21');
  1. 將數據導入到ods層與dw層
# 從原始數據層導入到ods 層
insert into zw.ods_t_product
select *,'20191221' from zw.t_product ;
# 從ods同步到dw層
insert into zw.dw_t_product
select * from zw.ods_t_product where cdat='20191221';
  1. 查看dw層的運行結果
select * from zw.dw_t_product where cdat='20191221';

增量導入12月22日數據

  1. 原始數據層導入12月22日數據（6條數據）
UPDATE `zw`.`t_product` SET goods_status = '已刪除', modifytime = '2019-12-22' WHERE goods_id = '003';
UPDATE `zw`.`t_product` SET goods_status = '已刪除', modifytime = '2019-12-22' WHERE goods_id = '006';
INSERT INTO `zw`.`t_product`(goods_id, goods_status, createtime, modifytime) VALUES
('007', '待審覈', '2019-12-22', '2019-12-22'),
('008', '待審覈', '2019-12-22', '2019-12-22');
  1. 將數據導入到ods層與dw層
# 從原始數據層導入到ods 層
insert into zw.ods_t_product
select *,'20191222' from zw.t_product ;
# 從ods同步到dw層
insert into zw.dw_t_productpeizhiwenjian
select * from zw.ods_t_product where cdat='20191222';
  1. 查看dw層的運行結果
select * from zw.dw_t_product where cdat='20191222';

從上述案例，能夠看到：

     表天天保留一份全量，每次全量中會保存不少不變的信息，若是數據量很大的話，對存儲是極大的浪費         

      能夠講表設計爲拉鍊表，既能知足反應數據的歷史狀態，又能夠最大限度地節省存儲空間。

方案二: 使用拉鍊表保存歷史快照(思路/圖解)

  • 拉鍊表不存儲冗餘的數據，只有某行的數據發生變化，才須要保存下來，相比每次全量同步會節省存儲空間
  • 可以查詢到歷史快照
  • 額外的增長了兩列（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

         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
  • 新數據00五、00六、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

         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
  • 新數據00七、00八、dw_start_date爲2019/12/22，dw_end_date爲9999/12/31

方案二: 拉鍊錶快照代碼實現

操做流程：

  1. 在原有dw層表上，添加額外的兩列
  2. 只同步當天修改的數據到ods層
  3. 拉鍊表算法實現
  4. 拉鍊表的數據爲：當天最新的數據 UNION ALL 歷史數據

代碼實現：

  1. 在MySQL中zw庫和商品表用於到原始數據層
-- 建立數據庫
create database if not exists zw;

-- 建立商品表
create table if not exists `zw`.`t_product_2`(
goods_id varchar(50), -- 商品編號
goods_status varchar(50), -- 商品狀態
 createtime varchar(50), -- 商品建立時間
 modifytime varchar(50) -- 商品修改時間
)default character set = 'utf8';
  1. 在MySQL中建立ods和dw層 模擬數倉
-- ods建立商品表
create table if not exists `zw`.`ods_t_product2`(
goods_id varchar(50), -- 商品編號
 goods_status varchar(50), -- 商品狀態
 createtime varchar(50), -- 商品建立時間
 modifytime varchar(50), -- 商品修改時間
cdat varchar(10)   -- 模擬hive分區
)default character set = 'utf8';
-- dw建立商品表
create table if not exists `zw`.`dw_t_product2`(
goods_id varchar(50), -- 商品編號
 goods_status varchar(50), -- 商品狀態
 createtime varchar(50), -- 商品建立時間
 modifytime varchar(50), -- 商品修改時間
 dw_start_date varchar(12), --  生效日期
 dw_end_date varchar(12), -- 失效時間
 cdat varchar(10)  -- 模擬hive分區
)default character set = 'utf8'; 

全量導入2019年12月20日數據

  1. 原始數據層導入12月20日數據（4條數據）
insert into `zw`.`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');
  1. 將數據導入到數倉中的ods層
insert into zw.ods_t_product2
select *,'20191220' from zw.t_product_2 where modifytime >='2019-12-20'
  1. 將數據從ods層導入到dw層
insert into zw.dw_t_product2
select goods_id, goods_status, createtime, modifytime, modifytime,'9999-12-31', cdat from zw.ods_t_product2 where cdat='20191220'

增量導入2019年12月21日數據

  1. 原始數據層導入12月21日數據（6條數據）
UPDATE `zw`.`t_product_2` SET goods_status = '待售', modifytime = '2019-12-21' WHERE goods_id = '001';
INSERT INTO `zw`.`t_product_2`(goods_id, goods_status, createtime, modifytime) VALUES
('005', '待審覈', '2019-12-21', '2019-12-21'),
('006', '待審覈', '2019-12-21', '2019-12-21');
  1. 原始數據層同步到ods層
insert into zw.ods_t_product2
select *,'20191221' from zw.t_product_2 where modifytime >='2019-12-21';
  1. 編寫ods層到dw層從新計算 dw_end_date

注意：我這裏直接將結果的SQL語句放在這裏語句 由於須要將覆蓋寫入到數據庫中我這裏就沒有寫了，可是不影響咱們結果。12月22 號的操做流程跟21 同樣我就裏就不寫了

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__date end as end ,
       t1.cdat
from zw.dw_t_product2 t1
left join (select * from zw.ods_t_product2 where cdat='20191221')t2 on t1.goods_id=t2.goods_id
union
select goods_id, goods_status, createtime, modifytime, modifytime,'9999-12-31', cdat from zw.ods_t_product2 where cdat='20191221'
  1. 查詢結果498b831e9740823c6017929397ed96d2.jpg

總結

         到這裏咱們終於將拉鍊表實現完了，雖然實現拉鍊表這個功能有點複雜有點繞，可是它真的幫助咱們節省不少的資源，以公司層面難道不選它嗎，也就爲何面試數倉的時候基本上都會問拉鍊表的緣由。不少小夥伴對dw_start_date與ds_end_date有疑惑咱們能夠在評論區一塊兒討論。信本身，努力和汗水總會能獲得回報的。我是大數據老哥，咱們下期見~~~

獲取Flink面試題，Spark面試題，程序員必備軟件，hive面試題，Hadoop面試題，Docker面試題，簡歷模板等資源請去GitHub自行下載 https://github.com/lhh2002/Framework-Of-BigData

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程