解决缓慢变化维问题
Hive数仓缓慢变化维问题
- 什么是缓慢变化维（SCD)
-
- 1 缓慢变化维简介
- **2 举例说明**
- SCD问题的几种解决方案
- SCD解决方案 - 保留原始值
- SCD解决方案 - 改写属性值
- SCD解决方案 - 增加维度新行
- SCD解决方案 - 增加维度新列
- SCD解决方案 - 使用历史表
- 数据采集-拉链表技术介绍
- 商品历史快照案例
-
-
-
- 方案一：快照每一天的数据到数仓
- 方案一：MySQL到Hive数仓代码实现
- 方案二：使用拉链表保存历史快照
- 查询拉链表
- 方案二：拉链表存储历史快照代码实现
-
-
什么是缓慢变化维（SCD)
1 缓慢变化维简介
- 缓慢变化维，简称SCD（Slowly Changing Dimensions）
- 一些维度表的数据不是静态的，而是会随着时间而缓慢地变化（这里的缓慢是相对事实表而言，事实表数据变化的速度比维度表快）
- 这种随着时间发生变化的维度称之为缓慢变化维
- 把处理维度表数据历史变化的问题，称为缓慢变化维问题，简称SCD问题
2 举例说明
例如：用根据用户维度，统计不同出生年份的消费金额占比。（80后 90后 00后）。
而期间，用户可能去修改用户数据，例如：将出生日期改成了 1992年。此时，用户维度表就发生了变化。当然这个变化相对事实表的变换要慢。但这个用户维度表的变化，就是缓慢变化维。
| 用户ID | 用户名 | 出生日期 | 住址 |
|---|---|---|---|
| 114 | 张三 | 1988-09-08 | 北京市朝阳区 |
这个用户的数据不是一直不变，而是有可能发生变化。例如：用户修改了出生日期 或者用户修改了住址。
SCD问题的几种解决方案
以下为解决缓慢变化维问题的几种办法：
-
保留原始值：指标计算不符合最新维度数据
-
改写属性值：无法获取到历史状态
-
增加维度新行：拉链表
-
增加维度新列：成本太高
-
添加历史表：增加维护难度
对于历史数据会变化的以及还有新增数据的表同步到数仓中我们有两个要求：
1、 数据的历史状态我们要保存，
2、对于新增数据也保存
SCD解决方案 - 保留原始值
某一个属性值绝不会变化。事实表始终按照该原始值进行分组。例如：
- 出生日期的数据，始终按照用户第一次填写的数据为准
SCD解决方案 - 改写属性值
- 对其相应需要重写维度行中的旧值，以当前值替换。因此其始终反映最近的情况
- 当一个维度值的数据源发生变化，并且不需要在维度表中保留变化历史时，通常用新数据来覆盖旧数据。这样的处理使属性所反映的中是最新的赋值。
用户维度表
修改前：
| 用户ID | 用户名 | 出生日期 | 住址 |
|---|---|---|---|
| 114 | 张三 | 1988-09-08 | 北京市朝阳区 |
修改后：
| 用户ID | 用户名 | 出生日期 | 住址 |
|---|---|---|---|
| 114 | 张三 | 1992-09-08 | 北京市海淀区 |
- 这种方法有个前提，用户不关心这个数据的变化
- 这样处理，易于实现，但是没有保留历史数据，无法分析历史变化信息
SCD解决方案 - 增加维度新行
数据仓库系统的目标之一是正确地表示历史。典型代表就是拉链表。
保留历史的数据，并插入新的数据。
用户维度表
修改前：
| - | 用户ID | 用户名 | 出生日期 | 住址 |
|---|---|---|---|---|
| 9527 | 114 | 张三 | 1988-09-08 | 北京市朝阳区 |
修改后：
| 编号 | 用户ID | 用户名 | 出生日期 | 住址 |
|---|---|---|---|---|
| 9527 | 114 | 张三 | 1988-09-08 | 北京市朝阳区 |
| 9528 | 114 | 张三 | 1992-09-08 | 北京市海淀区 |
SCD解决方案 - 增加维度新列
用不同的字段来保存不同的值，就是在表中增加一个字段，这个字段用来保存变化后的当前值，而原来的值则被称为变化前的值。总的来说，这种方法通过添加字段来保存变化后的痕迹。
用户维度表
修改前：
| 编号 | 用户ID | 用户名 | 出生日期 | 住址 |
|---|---|---|---|---|
| 9527 | 114 | 张三 | 1988-09-08 | 北京市朝阳区 |
修改后：
| 编号 | 用户ID | 用户名 | 出生日期 | 住址 | 现住址 | |
|---|---|---|---|---|---|---|
| 9527 | 114 | 张三 | 1988-09-08 | 1992-09-08 | 北京市朝阳区 | 北京市海淀区 |
SCD解决方案 - 使用历史表
另外建一个表来保存历史记录，这种方式就是将历史数据与当前数据完全分开来，在维度中只保存当前最新的数据。
用户维度表
| 编号 | 用户ID | 用户名 | 出生日期 | 住址 |
|---|---|---|---|---|
| 9527 | 114 | 张三 | 1992-09-08 | 北京市海淀区 |
用户维度历史表
| 编号 | 用户ID | 用户名 | 出生日期 | 住址 |
|---|---|---|---|---|
| 9537 | 114 | 张三 | 1988-09-02 | 北京市朝阳区 |
| 9527 | 114 | 张三 | 1992-09-08 | 北京市海淀区 |
这种方式的优点是可以同时分析当前及前一次变化的属性值，缺点是只保留了最后一次变化信息。
数据采集-拉链表技术介绍
数据仓库的数据模型设计过程中，经常会遇到这样的需求：
- 表中的部分字段会被update，例如：
用户的地址，产品的描述信息，品牌信息等等; - 需要查看某一个时间点或者时间段的历史快照信息，例如：
查看某一个产品在历史某一时间点的状态
查看某一个用户在过去某一段时间内，更新过几次等等 - 变化的比例和频率不是很大，例如：
总共有1000万的会员，每天新增和发生变化的有10万左右
商品历史快照案例
需求：
有一个商品表：
| 列名 | 类型 | 说明 |
|---|---|---|
| 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 |
商品的状态，会随着时间推移而变化，我们需要将商品的所有变化的历史信息都保存下来。如何实现呢？
方案一：快照每一天的数据到数仓
该方案为：
- 每一天都保存一份全量，将所有数据同步到数仓中
- 很多记录都是重复保存，没有任何变化
12月20日（4条数据）
| 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条数据）
| 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到Hive数仓代码实现
MySQL&Hive初始化
1 在MySQL demo库中 创建表
-- 创建数据库
CREATE DATABASE demo DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
-- 创建商品表
create table if not exists `demo`.`t_product`(
goods_id varchar(50), -- 商品编号
goods_status varchar(50), -- 商品状态
createtime varchar(50), -- 商品创建时间
modifytime varchar(50) -- 商品修改时间
);
2 在Hive中 demo库创建表
-- 创建表
create database if not exists `demo`;
-- 创建ods层表
create table if not exists `demo`.`ods_product`(
goods_id string, -- 商品编号
goods_status string, -- 商品状态
createtime string, -- 商品创建时间
modifytime string -- 商品修改时间
)
partitioned by (dt string)
row format delimited fields terminated by ',' stored as TEXTFILE;
-- 创建dw层表
create table if not exists `demo`.`dw_product`(
goods_id string, -- 商品编号
goods_status string, -- 商品状态
createtime string, -- 商品创建时间
modifytime string -- 商品修改时间
)
partitioned by (dt string)
row format delimited fields terminated by ',' stored as TEXTFILE;
增量导入12月20日数据
1 MySQL数据库导入12月20日数据（4条数据）
2 使用Kettle将MySQL数据导出，并导入到分区HDFS位置
方案二：使用拉链表保存历史快照
拉链表
- 拉链表不存储冗余的数据，只有某行的数据发生变化，才需要保存下来，相比每次全量同步会节省存储空间
- 能够查询到历史快照
- 额外的增加了两列（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-20 |
| 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变为2019-12-21，表示待审核状态，在2019/12/20（包含） - 2019/12/21有效
- 001编号新的状态重新保存了一条记录，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-20 |
| 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-21 |
| 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 |
查询拉链表
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;
方案二：拉链表存储历史快照代码实现
操作步骤：
-
在原有dw层表上，添加额外的两列
- 生效日期（dw_start_date）
- 失效日期（dw_end_date）
-
只同步当天修改的数据到ods层
-
拉链表算法实现
-
编写SQL处理当天最新的数据
-
编写SQL处理dw层历史数据，重新计算之前的dw_end_date
-
拉链表的数据为：当天最新的数据 UNION ALL 历史数据
-
-
拉链表的数据为：当天最新的数据 UNION ALL 历史数据
代码实现：
1 MySQL&Hive表初始化
MySQL创建商品表2
-- 创建数据库
CREATE DATABASE demo DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
-- 创建商品表
create table if not exists `demo`.`t_product_2`(
goods_id varchar(50), -- 商品编号
goods_status varchar(50), -- 商品状态
createtime varchar(50), -- 商品创建时间
modifytime varchar(50) -- 商品修改时间
)ENGINE=InnoDB DEFAULT CHARSET=utf8 ;
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');