维度模型-层次划分规范

1. 背景：

10几年重构过很多数据仓库，很多都是层次不清导致不完整，重复加工导致失败。

2. 目标：

定义规范，划分一下ods，dwd，dws之间的边界。 简单，好落地。

个人主观定义规范，无所谓对不对，只有合适不合适 ，有没有遵守。

3. 错误案例：

之前公司结果一个非常极端的订单dws表， 在现有dwd基础上union all 了一部分从ods来的订单然后进行聚合出来汇总数据。

4. 导致的问题：

1）完整性： 订单dwd表不完整。没有描述清楚订单这个业务过程。

2）一致性： 其他地方需要对订单进行聚合时，都得复制一下union all 这个逻辑， 极大可能引入不一致。

3）重复开发：其他人忍受不了就得单独开发一个订单表， 对下游用户来说就存在多个订单表。

5. 规范：

ods：增量或者全量抽取业务数据，原封不动。

dwd：每个业务过程 0-2 的 事务事实表， 0-2个周期快照事实表，0-1个累计快照事实表。为什么是2 和1，后面说。

dws： 单指标来说只是对dwd进行sum group by和连接维度表 等简单加工（因为dws也会对多个dwd进行横向钻取） ， 如果涉及了明细处理，说明dwd加工不完整，给dwd提需求。

6. 举例

库存物料进出事务事实表： 每有一次物料进去记录一行。

库存每日快照表： 每天每种物料有一行记录。

库存每日存量+每日销量+其他业务过程的融合事实表。

一个本业务过程的快照表， 一个融合其他业务过程的快照表。 没想到啥情况事务事实表融合其他业务过程。本想说订单，但是从订单维度来说，订单是订单的每日快照，太绕了。

所以一个业务过程，在dwd最多会有3种表，每种表最多会有2个表：本业务过程，融合其他业务过程。

累计快照本身就是融合其他业务过程，所以最多会有一个。

7. 疑问

问：为什么库存是对事务的聚合，算dwd。

答：不是简单的聚合，为了每天每种物料有一条记录，至少要有左连接。参见规范5里对dws的定义。 库存快照是对库存事务的一个补充，从另一个角度对库存进行说明，不是为了性能的简单聚合。 而且从钻取角度来说， 如果把周期快照算作dws表， 不见得就能简单的钻取到事务明细， 尤其在周期快照在事务明细基础上计算了很多指标的情况下。

同理融合事实表虽然也有数据汇总，也算作dwd。

补充：维度建模建议从原子粒度进行设计，快照我们也从最细的粒度进行快照。

8. 结尾

总结起来就一句话： dws只做sum等简单计算， dwd让dws能只做sum等简单计算

最终， 每个业务过程dwd每种类型几个表，做到什么程度， dws 代码格式都有法可依。