最先回答

做过，我之前做过一个缓慢变化维表的模型设计优化

第一步讲：为什么做？

• 数据仓库的重要特点之一是反映历史变化，所以如何处理维度的变化是维度设计的重要工作之一。缓慢变化维的提出是因为在现实世界中，维度的属性并不是静态的，它会随着时间的流逝发生缓慢的变化，与数据增长较为快速的事实表相比，维度变化相对缓慢。
• 如果维度的历史信息不需要保存，那么每天直接覆盖是不是就可以了呢？但是，大多数场景下，历史维度信息都需要保存下来，供业务分析使用。此时，如何更好地处理缓慢变化维就显的至关重要。

第二步讲：别人怎么做？

分区全量表：开发简单；取数简单；浪费存储

dt=0305(第一天)

id    status
1001    1
1002    1
1003    1

dt=0306(新增两条数据1004和1005，并且修改一条数据1001和删除一条数据1002)

id    status
1001    2
1003    1
1004    3
1005    1

第三步讲：我怎么做？

拉链表：开发难度大；取数难理解；节约存储

第一天初始化一级分区和二级分区

dt_start=0305  dt_end=9999
id    status
1001    1
1002    1
1003    1

如果需要查询0305当天数据，查询语句如下：

select * 
from table
where dt_start <= 0305 and dt_end > 0305

第二天新增两条数据1004和1005，并且修改一条数据1001和删除一条数据1002，需要做如下操作：

dt_start=0305  dt_end=9999
id    status
1003    1

dt_start=0305  dt_end=0306
id    status
1001    1
1002    1

dt_start=0306  dt_end=9999
id    status
1001    2
1004    3
1005    1

如果需要查询0306当天数据，查询语句如下：

select *
from table
where dt_start <= 0306 and dt_end > 0306

第四步讲：带来的收益

使用拉链表这种方式对xx维表优化后，减少了5GB的存储，占用磁盘存储降低了50%

第五步讲：未来的思考（开始吹牛）

paimon表：开发简单；取数简单；节约存储；涉及技术架构迭代

这个关乎到数仓整体架构的优化，如果将paimon作为整个数仓的底层存储架构，那么我们就不需要像拉链表那样去维护不同时刻的版本，paimon的snapshot就可以实现这个能力，用户可以通过最新的快照来访问表的最新数据，同时可以通过时间旅行，访问表的过去状态。