c

chaojie

V1

2022/05/08阅读:19主题:极简黑

数仓笔记|采购业务


本文结构

  1. 前言
  2. 采购业务下,对于事务事实表设计的思考
  3. 采购业务的总线矩阵
  4. 缓慢变化维度技术类型0~7
  5. 对于拉链表的思考

大家好,我是超杰,数仓系列总共 20 篇,这是我数仓笔记系列的第三篇文章。

0、前言

这篇文章主要聊聊在数仓工作中,我们去设计一个事务事实表要考虑到哪些问题,聊聊缓慢变化维度技术(SCD)的使用场景,以及我对于拉链表的思考。

你将收获到:

  • 设计事务事实表需要考虑的三个因素
  • 进一步了解缓慢变化维度技术
  • 通过不同场景,深入了解拉链表设计的巧妙

1、采购业务

我们通过零售业务得知,我们想要拿到理想的利润率,可以通过获得好渠道的低价格,合理定价,品牌溢价等形式达到目的。

一个产品的价格成本,是由原材料的价格决定的。产品制造商想要节省开销,往往会减少供应商数量,并且与合适的供应商签合同。

最终达到目的,用实惠的价格,拿到优质原材料的。

以下是本篇文章采购的业务线

这条业务线,有六个业务过程。

采购清单,主要是与原材料供应商沟通谈判,原材料的交易价格,并且会签署合同确定。

购买订单,是在我们与供应商定好价格之后,跟供应商下单购买原材料。

货运通知,是供应商通过第三方运输公司将原材料运输到我们制造商这里。

仓库收据,则是对到货的原材料,进行验收入库的一个行为。

发票和支付,收到货物后,对供应商索要发票,以及支付原材料的价格。

如果我们不去仔细针对每个业务过程去细化分析,我们模型设计,可能是这样的。

以事务日期、产品、供应商、合同条款和采购食物类型的采购事务作为主键维度的粒度行。

这种做法,将多个事务类型整合到一张事务事实表,这种是多事务事实表,如果不对业务过程去调研,将来会有不少隐患。

在我们建模的时候,需要全面的了解业务需求。

我们在考虑使用单事务事实表还是多事务事实表的时候,我们需要从业务上考虑以下三个因素。

  • 不同业务过程的主键标识是否一致? 如果不同,放在一起,则不合理。比如采购清单的清单号与仓库收据的收据单没有关系,是互不干扰,独立的主键标识
  • 多个源系统获取同样粒度的度量吗? 购买系统负责采购清单和采购订单,仓库系统负责发货通知和仓库清单,账户支付系统负责发票和付款。业务过程来自三个源系统,粒度基本基本都不同,即便来自同个系统的业务,他们的度量也不同,应该使用单事务事实表
  • 维度是否一致? 像采购清单这个业务就没有仓库维度,也没有运输公司维度,应该使用单事务事实表

进行模型设计前,一定不能忽略维度模型设计的四步过程。我在分享零售业务中有详细讲解。

采用单事务事实表的好处,易实现且易管理。如果采用多事务事实表,就需要考虑到以上三个因素。

2、采购业务总线矩阵

以上是采购业务的总线矩阵,通过矩阵,可以帮助我们找到哪些是共享维度(也叫一致性维度),哪些是一致性事实(可以理解为一致性的院原子指标)

如果我们有监督整个业务流水线效率的需求,可以考虑使用累计周期快照。

关于累计周期快照,我在第一篇数仓笔记,库存业务中有讲解。感兴趣可以去看看。

3、缓慢变化维度技术

如果维度属性值发生变化,我们要如何维护?这事缓慢变化维度技术要解决的问题。

比如,公司产品对应的考核部门,每年一换。我们要保留历史吗,还是不保留?

如果要进行不同部门运营比较,那是不是必须保留历史了,下一个问题又来了,要如何保留?

接下来,向大家介绍5种解决方案,分为类型0~4

类型0:保留原始值

当我们设计维度时,给维度表,设置成类型0。基本维度表初始化一次,就再也不会去变更。比如:游戏场景里,玩家的原始积分。

类型1:重写

类型1,比较好理解。直接重写当前存在的值。比如产品的考核部门调整,且不需要分析产品之前考核部门的运营情况。

这种维度表的设计,设置为类型1,直接覆盖重写数据即可。

类型2:增加新行

跟拉链表类似,特点是能保留历史数据,可以进行部门变更前后的分析。

类型3:增加属性列

类型3的使用场景特别少,如果遇到不可预则的属性变化,这种类型行不通。

如果业务需求,只要我们保留一个历史属性值就可以使用该类型。

比如政府机构需要保留曾用名的场景,我们改名字,只保留一个曾用名即可。

类型4:增加微型维度

当我们访问用户信息表时,一条数据代表一个人,如果用户有上千万,查询性能就是一个问题。

如果我们的业务需求不是看具体的某个客户,二是对人口特征分析。而微型维度可以研究一下,它的特点是区间范围。

通过查阅资料发现,采用微型维度的工程师不多。

一是微型维度是事先用所有可能值的组合加载的,需要考虑每个属性的基数,且必须是枚举值。很多属性可能是非枚举型,比如数值类型,如 VIP 分数、信用分数等;时间类型,如上架时间、下架时间、变更时间等。

二是需要实现代理键,ETL逻辑复杂,开发维护成本高;

4、拉链表深入思考

到底是什么场景下,才需要拉链表?

这是我最近思考的问题。我总结出一句话:如果是分析历史变化的需求,才需要用到拉链表。

很典型的一个例子,产品的部门更换,领导想看今年双十一某个产品的销售情况,在部门更换前,是否有所增长?

只有这种场景的时候,我们才需要将维度表维护拉链表,也就是上面提到的类型2。

基于这种场景延伸,如果出现一张用户信息表(维度表),有多个属性经常变更,并且我有业务场景需要分析不同时间的属性。

那么,我们需要在新维护一张拉链表,这张表专门用于维护,有着历史变化分析需求的属性字段。

- END -

分类:

后端

标签:

大数据

作者介绍

c
chaojie
V1