数据仓库模型评估的标准

面试中，肯定有数仓同学被问到：数据模型如何去评估、如何优化，那今天就聊一聊这个话题。

基本概念

模型：表达的是某一个主题、某一个业务过程，赋值业务价值，最终落地还是一个建表的过程

数仓模型：表赋予业务含义，简单来说还是表，可以理解成圆和球的关系

算法模型：输入数据集和样本集、训练超参，输出一系列参数，本质上就是数学公式

数据分析模型：通过看待业务不同角度去分析业务数据，本质上封装的是某个角度分析的策略

表：一个数字字典的结构体，比如：字段A、B、C没有实际业务含义，但是当表中字段是sku_id，sku_name以及相关维度信息，具备业务含义后就可以理解成一个sku的相关模型

ER模型：对三范式要求较高，强调的是实体关系，对数据冗余不太包容。需要基于整个业务梳理出所有的实体之间关系，这种方式好处就是没有数据冗余，但是成本较高，周期长

维度模型：对数据冗余相对宽容，基于事实和维度构建模型。基于需要分析的业务过程或者业务事实去划分事实和维度，根据看待的不同角度去划分维度

模型评估标准

高内聚，低耦合

在dwd层划划分主题域的过程中，可能一些业务过程比较复杂，层层抽离出实体对象到最细粒度的一个动作，比如：下单、支付等等，这样做主要是建设一个细粒度模型，降低业务过程之间的耦合度，模型更加灵活 ，减少不同模型之间对相同业务的依赖，尽量把这种细粒度的业务流程汇聚到一个模型中，减少依赖。

核心模型和扩展模型分离

一些重要的数据作为核心模型产出（典型的就是一些大宽表）

一些不是很边缘的业务数据在不影响核心模型的情况下其实可以合并到核心模型，保证核心模型不会太重，不影响产出时效

公共逻辑下沉

出现相同逻辑的时候可以在dwd或者做个中间层收口，万一口径发生变化，只需要在最底层修改逻辑，上层只需要回溯验证数据即可，而不是说到处修改用到的地方

成本和性能平衡

成本：宽表不能过大，存储成本

性能：产出时效性

提倡建设公共层，减少逻辑的重复加工（将数据武装到每个人都可以兼容装备）

数据可回滚

确保一些经常变化的维度可以回滚，比如：当下游每天产出指标的时候，突然今天的指标值和昨天的差异性很大，这个时候我们就要去回滚昨天的数据，看今天数据是否异常还是逻辑错误等等

规范

主要是一些数仓的研发规范，如表命名规则：dwd_部门_一级主题域_最小业务流程_业务流程缩写_全量/增量缩写（数仓笔记语雀中详细记载）

枚举值的一致性

优化：主要分为两个方面合并和拆

合并

为什么合并：可能存在相似的业务流程，有一些小模型，彼此之间还存在对相同业务过程的依赖

合并原则：在不破坏核心模型的简洁性和产出时效方面，可以进行合并，减少对这些不是很边缘业务的关联

拆分

影响到核心模型的产出时效、维护难，可读性差，比如：用户购物这个业务流程，显然不可能把订单和商品的一些信息放在一起的