目前开始更新 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内容如下：
执行结果如下所示：
写入的内容如下所示：
写入的内容如下所示：
执行结果如下图所示：
如果我们查询所有数据，可以看到对应的内容：