数仓笔记｜采购业务

---

本文结构

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

---

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

0、前言

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

你将收获到：

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

1、采购业务

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2、采购业务总线矩阵

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

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

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

3、缓慢变化维度技术

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

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

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

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

类型0：保留原始值

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

类型1:重写

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

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

类型2:增加新行

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

类型3:增加属性列

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

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

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

类型4:增加微型维度

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

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

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

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

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

4、拉链表深入思考

到底是什么场景下，才需要拉链表？

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

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

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

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

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

- END -