大数据-245 离线数仓 - 电商分析缓慢变化维与拉链表 SCD Slowly Changing Dimensions

点一下关注吧！！！非常感谢！！持续更新！！！

Java篇开始了！

目前开始更新 MyBatis，一起深入浅出！

目前已经更新到了：

Hadoop（已更完）
HDFS（已更完）
MapReduce（已更完）
Hive（已更完）
Flume（已更完）
Sqoop（已更完）
Zookeeper（已更完）
HBase（已更完）
Redis （已更完）
Kafka（已更完）
Spark（已更完）
Flink（已更完）
ClickHouse（已更完）
Kudu（已更完）
Druid（已更完）
Kylin（已更完）
Elasticsearch（已更完）
DataX（已更完）
Tez（已更完）
数据挖掘（已更完）
Prometheus（已更完）
Grafana（已更完）
离线数仓（正在更新…）

章节内容

上节我们完成了如下的内容：

电商核心交易 ODS层
数据库结构数据加载 DataX

在这里插入图片描述

缓慢变化维

缓慢变化维（SCD，Slowly Changing Dimensions），在现实世界中，维度的属性随着时间的流失发生缓慢的变化（缓慢是相对事实表而言，事实表数据变化的速度比维度表快）。
处理维度表的历史变化信息的问题称为处理缓慢变化维的问题，简称SCD问题，处理缓慢变化维的方法有以下几种常见方式：

保留原值
直接覆盖
增加新属性列
快照表
拉链表

缓慢变化维（slowly varying dimension）是数据仓库领域中维度数据的一种特性，用于描述随着时间推移，某些属性会发生变化的维度。然而，这些变化通常是相对缓慢和不频繁的，因此称之为“缓慢变化维”（SCD, Slowly Changing Dimensions）。处理缓慢变化维是数据仓库设计中的一个重要部分，因为它直接影响数据的历史记录保存和版本控制。

缓慢变化维主要用于记录维度的属性随时间变化的情况，例如客户的地址、雇员的职位或产品的价格等。在实际应用中，为了满足业务需求，通常会根据变化记录需求的不同，采用不同的技术实现。

缓慢变化维的类型

缓慢变化维常被分为以下几种类型：

SCD 类型 0：不处理变化

特点：属性变化时，不记录变化，只保留最新值。
适用场景：维度的属性对历史分析无影响。
优点：实现简单。
缺点：无法保存历史信息。

SCD 类型 1：覆盖变化

特点：属性变化时，直接覆盖旧值。
适用场景：只需要保留最新的维度信息，历史数据无关紧要。
优点：占用存储空间小，查询效率高。
缺点：无法追溯历史信息，丢失数据变更记录。
示例：客户地址发生变化，仅更新地址字段。

SCD 类型 2：保留历史记录

特点：为每一次变化创建一条新记录，同时可以通过标识字段或时间戳区分当前数据和历史数据。

实现方式：

增加版本号：新增一个版本号字段表示记录版本。
增加有效时间区间：新增开始和结束时间字段表示记录的有效期。
适用场景：需要保留所有历史信息，支持基于时间的回溯查询。
优点：完整记录历史变化。
缺点：数据量增加，查询复杂度可能提高。
示例：客户地址发生变化，保留旧地址记录，新建一条记录保存新地址。

SCD 类型 3：有限的历史记录

特点：为变化的属性设置额外的字段，仅保留有限的历史信息（如最近一次变化）。
适用场景：只需要保存一部分历史信息，对存储空间要求较低。
优点：减少数据量，存储需求低。
缺点：历史记录有限，无法满足更复杂的回溯分析。
示例：添加“旧地址”和“当前地址”两个字段。

SCD 类型 4：历史表

特点：将历史记录存储在单独的历史表中，主表中只保留当前数据。
适用场景：需要完整保存历史信息，同时希望主表保持精简。
优点：主表数据简单，查询当前值效率高。
缺点：需要额外的历史表，查询历史信息时复杂度增加。
示例：主表存储客户的最新地址，历史表存储地址变更记录。

SCD 类型 6：混合型

特点：结合类型 1、2 和 3，既保留最新值，又保留有限的历史信息，还可以保存完整的历史记录。
适用场景：需要兼顾历史记录和当前值查询效率。
优点：兼具多种类型的优点。
缺点：实现较为复杂。
示例：主表记录最新信息，同时增加版本号和时间戳以追溯历史。

保留原始值

维度属性值不做更改，保留原始值。
如商品上架售卖时间：一个商品上架售卖后由于其他原因下架，后来又再次上架，此种情况产生了多个商品上架售卖时间，如果业务重点关注的是商品首次商家售卖时间，则采用该方式。

直接覆盖

修改维度属性为最新值，直接覆盖，不保留历史信息。
如商品属于哪个品类：当商品品类发生变化时，直接重写为商品类。

增加新属性列

在维度表中新增加新的一列，原先属性列存放上一版本的属性值，当前属性列存放当前版本属性值，还可以增加一列记录变化的事件。
缺点：只能记录最后一次变化的信息。

在这里插入图片描述

快照表

每天保留一份全量数据，简单高效。
缺点是信息重复，浪费磁盘空间。
适用的维表不能太大，但是使用场景多，范围广，一般而言维表都不会很大。

拉链表

拉链表适用于：表的数据量大，而且数据会发生新增和变化，但是大部分是不变的（数据发生变化的百分比不大），且是缓慢变化的（如电商用户信息表中的某些用户属性不可能每天都变化），主要目的是为了节省空间。

适用的场景：

表的数据量大
表中部分字段会被更新
表中记录变量的比例不高
需要保留历史信息

维表拉链表应用案例

在这里插入图片描述

创建表

注意：这里的操作是在Hive中
对应的SQL内容如下：

CREATE DATABASE test;
-- 用户信息
DROP TABLE IF EXISTS test.userinfo;
CREATE TABLE test.userinfo(userid STRING COMMENT '用户编号',mobile STRING COMMENT '手机号码',regdate STRING COMMENT '注册日期')
COMMENT '用户信息'
PARTITIONED BY (dt string)
row format delimited fields terminated by ',';-- 拉链表（存放用户历史信息）
-- 拉链表不是分区表；多了两个字段start_date、end_date
DROP TABLE IF EXISTS test.userhis;
CREATE TABLE test.userhis(userid STRING COMMENT '用户编号',mobile STRING COMMENT '手机号码',regdate STRING COMMENT '注册日期',start_date STRING,end_date STRING)
COMMENT '用户信息拉链表'
row format delimited fields terminated by ',';

执行结果如下所示：
在这里插入图片描述

数据文件

vim /opt/wzk/userinfo.dat

写入的内容如下所示：

001,13551111111,2020-03-01,2020-06-20
002,13561111111,2020-04-01,2020-06-20
003,13571111111,2020-05-01,2020-06-20
004,13581111111,2020-06-01,2020-06-20
002,13562222222,2020-04-01,2020-06-21
004,13582222222,2020-06-01,2020-06-21
005,13552222222,2020-06-21,2020-06-21
004,13333333333,2020-06-01,2020-06-22
005,13533333333,2020-06-21,2020-06-22
006,13733333333,2020-06-22,2020-06-22
001,13554444444,2020-03-01,2020-06-23
003,13574444444,2020-05-01,2020-06-23
005,13555554444,2020-06-21,2020-06-23
007,18600744444,2020-06-23,2020-06-23
008,18600844444,2020-06-23,2020-06-23

写入的内容如下所示：
在这里插入图片描述

加载数据

-- 动态分区数据加载：分区的值由输入数据确定
-- 创建中间表(非分区表)
DROP TABLE IF EXISTS test.tmp1;
CREATE TABLE test.tmp1 AS
SELECT * FROM test.userinfo;-- 设置 tmp1 非分区表的字段分隔符为 ','（原始默认分隔符为 '\001'）
ALTER TABLE test.tmp1 SET SERDEPROPERTIES('field.delim' = ',');-- 向中间表加载数据
LOAD DATA LOCAL INPATH '/opt/wzk/userinfo.dat' INTO TABLE test.tmp1;-- 启用非严格模式的动态分区
SET hive.exec.dynamic.partition.mode = nonstrict;-- 从中间表向分区表加载数据
INSERT INTO TABLE test.userinfo
PARTITION (dt)
SELECT * FROM test.tmp1;