最先回答
做过,我之前做过一个缓慢变化维表的模型设计优化
第一步讲:为什么做?
- 数据仓库的重要特点之一是反映历史变化,所以如何处理维度的变化是维度设计的重要工作之一。缓慢变化维的提出是因为在现实世界中,维度的属性并不是静态的,它会随着时间的流逝发生缓慢的变化,与数据增长较为快速的事实表相比,维度变化相对缓慢。
- 如果维度的历史信息不需要保存,那么每天直接覆盖是不是就可以了呢?但是,大多数场景下,历史维度信息都需要保存下来,供业务分析使用。此时,如何更好地处理缓慢变化维就显的至关重要。
第二步讲:别人怎么做?
分区全量表:开发简单;取数简单;浪费存储
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
QUALIFY row_number() over(partition by id order by dt_start desc) = 1
第二天新增两条数据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就可以实现这个能力,用户可以通过最新的快照来访问表的最新数据,同时可以通过时间旅行,访问表的过去状态。