【数据仓库】缓慢变化维介绍及其解决SCD问题
目录
介绍
举例说明
SCD问题的几种解决方案
保留原始值(不推荐)
改写属性值(不推荐)
增加维度新行(推荐)
增加维度新列(不推荐)
添加历史表(不推荐)
使用拉链表保存历史快照思路
拉链表
12月20日商品拉链表的数据(全量数据同步):
12月21日商品拉链表的数据(增量数据同步)
12月22日商品拉链表的数据(增量数据同步)
拉链表存储历史快照代码实现
操作步骤:
MySQL&Hive表初始化
全量导入2019年12月20日数据
增量导入2019年12月21日数据
查询拉链表
介绍
缓慢变化维,简称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`
selectgoods_id, -- 商品编号goods_status, -- 商品状态createtime, -- 商品创建时间modifytime, -- 商品修改时间modifytime as dw_start_date, -- 生效日期'9999-12-31' as dw_end_date -- 失效日期
from`demo`.`ods_product_2`
wheredt = '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层拉链表中的失效时间
selectt1.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` t1left join(select * from `demo`.`ods_product_2` where dt='2019-12-21') t2on t1.goods_id = t2.goods_id;
合并当天最新的数据和历史数据覆盖到hive中
insert overwrite table `demo`.`dw_product_2`
selectt1.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_dateend as dw_end_date -- 更新生效日期(需要重新计算)
from`demo`.`dw_product_2` t1left join(select * from `demo`.`ods_product_2` where dt='2019-12-21') t2on t1.goods_id = t2.goods_id
union all
selectgoods_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;
【数据仓库】缓慢变化维介绍及其解决SCD问题相关推荐
- 解决缓慢变化维—拉链表
什么是缓慢变化维(SCD). 1.缓慢变化维简介 缓慢变化维,简称SCD(Slowly Changing Dimensions) 一些维度表的数据不是静态的,而是会随着时间而缓慢地变化(这里的缓慢是相 ...
- 数仓缓慢变化维SCD深度讲解
维度缓慢变化维SCD(Slowly Changing Dimensions)一些维度表的数据不是静态的,而是会随着时间而缓慢地变化(这里的缓慢是相对事实表而言,事实表数据变化的速度比维度表快,如果还不 ...
- 缓慢变化维解决方案——拉链表实现详解
缓慢变化维--拉链表实现 1.概述 1 缓慢变化维简介 缓慢变化维,简称SCD(Slowly Changing Dimensions) 一些维度表的数据不是静态的,而是会随着时间而缓慢地变化(这里的缓 ...
- 数据仓库缓慢变化维度SCD?你想知道的都在这里
点击上方蓝色字体,选择"设为星标" 回复"资源"获取更多资源 大数据技术与架构 点击右侧关注,大数据开发领域最强公众号! 大数据真好玩 点击右侧关注,大数据真好 ...
- blog-数据仓库维度建模系列--缓慢变化维(SCD)的思考(一)
缓慢变化维(Slowly Changing Dimensions) 缓慢变化维是维度技术中用于描述维度变化情况的一种分类. 什么是SDC? 在现实的实施中 先说一下缓慢变化维的概念.缓慢变化维(Slo ...
- 3 关于数据仓库维度数据处理的方法探究系列——缓慢变化维概述和原理
缓慢变化维 Slowly Changing Dimensions( A typical slowly changing dimension is a product dimension in whic ...
- 5 关于数据仓库维度数据处理的方法探究系列——缓慢变化维处理——全历史记录...
全历史记录是缓慢变化维中最为强大的一种加载方式.它将可以完全实现覆盖方式能实现的加载方式,且可以实现对数据的历史记录,可以记录下每一个数据的细微变化. 3.3.2 全历史记录( Type 2 Dime ...
- 大数据学习(三十一)数据仓库如何处理缓慢变化维
以下内容结合了<大数据之路-阿里巴巴大数据实践>书中的内容,就如何处理缓慢变化维话题进行展开. 前言:维度的属性也是会发生变化的,只不过相较于事实表而言,变化的速度是极其缓慢的,那我们是否 ...
- 数据仓库之维表-缓慢变化维
数据仓库的重要特点之一是反映历史变化,所以如何处理维度的变化是维度设计的重要工作之一.缓慢变化维的提出是因为在现实世界中,维度的属性并不是静态的,它会随着时间的流逝发生缓慢的变化 .与数据增长较为快速 ...
最新文章
- Centos下 ffmpeg 和opencv一起配合处理视频
- IE8不支持jQuery问题
- InnoDB发展历史
- DDK nmake : error 解决方法
- NDCG、AUC介绍
- BZOJ 1565: [NOI2009]植物大战僵尸
- 历史上水平最高的三十首七律
- 一文读懂长非编码RNA(lncRNA)的分类、功能及测序鉴定方法
- Java对接谷歌身份验证器
- 腾讯云主机SSH连接不上如何解决
- vmvare打开虚拟机时报错:vmx文件已损坏
- C++ scanf()函数
- Vue之 解决下拉框默认选中的是数字key 不是汉字value值
- E - Obstacle Course的详细解答
- 【Python】将xmind写的测试用例转成禅道可导入的excel格式
- Cocos Creator Effect 高斯模糊 (带算法)
- 爬取百度地图 商店铺联系电话地址定位
- 2021年金属非金属矿山(地下矿山)安全管理人员考试试卷及金属非金属矿山(地下矿山)安全管理人员试题及解析
- asp毕业设计——基于asp+access的校园新闻发布管理系统设计与实现(毕业论文+程序源码)——新闻发布管理系统
- win x64平台驱动测试数字签名