开发者学堂课程【智能数据建模训课程 ：数仓建模理论与规范（三）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1223/detail/18308
数仓建模理论与规范
六、数据模型设计的流程
1、流程
数据模型设计一般会分阶段。首先是需求调研阶段，该阶段更多的是在于之前提到的业务方法；第二阶段是规范定义，对于维度建模，很重要的一部分是维度是什么，事实是什么，以及观测的指标有哪些等，在该环节会做出规范的定义；最后进行模型设计，也就是具体的表的设计。
2、相关名词术语
（1）原子指标
观测指标时所观测的原子指标是指在一个业务动作下的度量，如下单的金额，构成原子指标所谓的下单金额，其实是业务过程加度量，业务过程是下单，度量是金额。
（2）时间周期
针对原子指标，可能还会观测最近一天或当月的支付金额或者下单金额，“最近一天”或“从月初到当前时间”都是时间周期。时间周期是指观测指标的时间范围。
（3）修饰词
是对业务的限定。2014年 app 端开始兴起，从那时起所有的指标的拆解，不仅要观测 PC 端，更多地会观测 APP端，要对下单金指标做拆解，此时 APP 端以及 PC 端就是对所用观测指标的业务限定。
（4）度量
在原子指标中提到过，度量包括金额、价数、单数等量词。
（2）派生指标
原子指标+修饰词+时间周期构成派生指标，如最近30天（时间周期）PC端（业务限定-修饰词）的下单金额（原子指标）整个构成派生指标。这些概念在 DataWorks 的产品中有具体的体现。
（3）维度
是指在看待业务时，我们要从哪写视角去看业务的表现。如观测某个会员在某个时间段的情况，时间是维度，会员是维度。
（7）粒度
粒度其实是最小的业务，表示最小的业务细节，如订单就是一个粒度。
3、需求调研环节
（1）业务调研
该实操过程的输入物是调研模板，经过对产品运营者、分析师的调研，在文件夹进行总结归纳，产出业务过程及数据域。
首先对业务系统进行调研，如到某电商公司建设数仓，我们会对业务系统以及业务需求展开调研，之后了解其业务系统的功能模块，如会员系统，包括注册、登录会员系统，再如商家后台，商家后台主要进行对商品的管理，如商品管理模块、物流模块等，这部分相对复杂，如商品模块包括商品的上下架、商品的属性、商品的价格等属性的修改等，这些都在业务过程功能模块中完成。根据这些业务动作总结归纳出业务过程，再根据业务过程归纳出数据域。
（2）需求分析
除了需求调研之外，还会进行需求分析，包括以上调研的结果，此外还会调研现有的报表以及数据体系，然后提供给分析师、运营师，向其提供一些输入模板让其填写现有的数据。如交易域的业务过程，观测的指标，观测指标的视角（维度）以及计算逻辑等。这些都是需要收集的非常重要的信息。没有的数据可以一起讨论确定口径指标。
（3）总线矩阵
经过调研产出整个的总线矩阵，它可以明确数据域与数据域含有的业务过程以及业务过程相关维度，即一致性维度，如商家、商品等。
4、规范定义
分为几部分内容，第一部分维度建模是非常重要的内容，因此在规范定义时要将其定义清楚。
（1）一致性维度
①维度即维度属性
首先维度必须归属于某个数据域的，无论是商家或是商品，商家属于商家域的，商品属于商品域，即维度是有其维度属性的。如商品包括其价格、颜色等属性。商品属性除了来源于源系统之外，还可能是经过认为挖掘得来的，如最近一次的支付时间。
②特殊属性
如交易状态，以及最近一次支付时间实际上是一种行为维度。
③维度的整合和拆分
整合是指将同一业务板块下的同维度的不同属性做信息的整合，如会员，除包含会员的基础属性，如性别、年龄等，也包含一些特殊的属性，如会员在平台上的星级，若该会员是商家，其商家等级属性等。除此之外，不同板块的同维度属性的也可以根据需要进行整合，如天猫有会员相应的会员体系，优酷也有会员体系，据此可以对会员属性进行整合，如基于 ID 实体进行整合。
除了整合，还会进行一些维度的拆分。至于何时进行拆分，在维度设计的时候会去做相应的取舍。同维度下不同分类的属性差异比较大的可以进行拆分，如商品具有一些主属性，包括商品的价格、颜色等，此外还有一些扩展属性，如商品是否带电等，所谓的带电是因为在物流环节商品可能无法运到某些国家，其业务属性要依据海关的一些业务要求决定是否可以运输。还有一些商品在业务层面做了一些动作，如中国迈向欧洲的跨境十日达，实际跨境物流时长较长，可以“十日达”其实是对业务做了一定的圈选，进行了特殊的一些业务设计。这些业务层面的维度属性可能会放到扩展表中，进行维度的拆分，拆分方法等会在后面的维度模型设计中具体讲到。
④命名规范
可能会对其做一些英文简写，如商品、商家、买家等，这些在标准化时是比较重要的定义，它决定了后面使用模型时的规范程度，以下是淘系最常使用的维度规范化的简写：
（2）度量
其必然属于某业务过程，一般是数值，如金额的内容是“多少钱”，它是度量值，在定义方面一般是数字类型的，它分为可加性度量、半可加性度量和不可加性度量，如 UV（纯用户数）不可累加，PV（浏览量）可累加，单量可加，“率”不可加，如今日商品的占比是多种形式，其不可累加。我们在做模型设计时，尽量将不可加性度量设计为可加性度量，如占比，在模型中只存分子分母而不存比率。度量也有命名规范，如数量（cnt）、金额（amt）等。
（3）指标定义
指标最终看业务属性，刚才已经提到了原子指标和派生指标，这里主要对其命名规范进行说明，可结合以下案例进行理解：
观察左图逻辑结构板块，可知业务过程+度量构成原子指标，原子指标+修饰词+时间周期构成派生指标。而维度是我们观测业务的视角，也就是说在维度下看指标才有真正的业务意义。这里的属性是指维度的属性。
右图表示淘特一天的交易金额、支付单量，业务过程“支付”的时间周期是“最近一天”，其原子指标“支付单量”，业务限定是来源于淘宝特价版的订单，维度属性是订单id。
以下是根据命名规范在表设计时候的命名：
如业务板块简写为eb，交易域是trade，这里简写为trd。其中包含了一些规范的简写以作借鉴。
5、模型设计
（1）设计原则
包括高内聚、低耦合、支持多次回刷，以及在成本上的平衡，稳定性、可扩展性的保障，公共层的逻辑下沉块，考虑在应用层有哪些指标或模型可以沉淀到的公共层。
（2）维度表设计
维度建模中维度表的设计是很重要的环节，其过程（业务动作）包括确定维度，确定维度的属性以及做一些父维度属性的冗余。前面我们介绍了范式建模和维度建模的区别，其中我们提到在做维度建模时，会做一些维度属性的反范式建模的设计，即不同于范式建模和 Kimball 推行的建模的思想，他们会严格的去按照范式做文件设计，规范化很高，在存储方面具有特殊优势，但在使用时会存在很大的瓶颈。因为在分析业务时，我们一定是在某一时间维度下去观测某些指标，此时势必会关联很多的维度。如要关联商品、商家、流量的转化渠道等维度。在写任务代码时，逻辑会十分复杂，取数的成本很高，尤其在大数据的今天，我们更会去考虑做一些反范式建模的设计，在也是我们在建模时不选择维度建模的原因之一，因为会把很多维度都冗余到事实表中，或者在维度表中也会冗余一些父维度属性。这就是一种反范式化的设计。
在做维度表时，需要考虑以下几点：①缓慢变化维，在 Kimball 的处理方法中有3种方式，即重写，插入新记录，和扩展维度列。而阿里采用的是一种极限存储，Hive 也有极限存储的概念，极限存储是处理缓冲变化维的一种方式方法；②维度的一致性，在不同的物理表中，字段的命名、名称、以及类型内容必须是一致的，如性别等，在内容上是要做规划处理；③维度的组合拆分，是在模型设计时必然要考虑的一点，而对于会员的不同的属性是否要在一张表中进行设计或者是否要拆分，这要视具体的业务场景而定。如会员的星级等一些基础属性等是否要整合，以及同维度的商品，其属性差异较大的是否要做拆分，如航旅的商品与淘宝的商品，其属性有很多的差异，则会对其属性进行拆分。至于是否进行拆分要进行综合考虑，如产出的实效、其应用性质、是否稳定等经常性地做评估。
在模型设计时一定要强调命名，包括维度字段的命名以及表名（dim_{业务 BU/pub}_{数据域}_{维度定义}{_{自定义命名标签}}），BU 业务板块，如淘宝 tb，数据域，如商家 slr，维度的定义，如商家属性 slr，如商品的扩展、itm_extend。
（3）维度表设计案例
比如说淘宝的商品表，以下为具体的表模型：
dim_tb_itm，数据域为商品，维度自定义的命名商品扩展名。除淘宝的主订单之外，淘宝的扩展信息表，作为扩展表，里面包含商品的维度，维度属性有商品标题、金额、颜色、主图等，且含有一些冗余的属性（反范式模型的设计，若是范式化的标准的设计的话，会有一张商品的尾表和一张类目的尾表，且商品的尾表里一定没有类目的一些属性），出于牺牲一些存储换取的计算的考虑，其中会聚合一些冗余类目的属性。
以下为商品属性扩展维度表 dim_tb_itm_extend：
从商品维度表中拆分了一个商品扩展的维度表的原因在于：扩展要经过喜多计算，如“十日达”是要经过一系列的计算才可以承诺给消费者，否则就会带来了许多时效产出的问题，因此在模型设计时这一系列计算不会放在主维度中进行。要让主维度更早地产出（如三四点产出主维度表，但扩展表要到五六点才能产出）这是模型设计的一个参考标准。
（4）事实表的设计
事实表的类型主要包括以下几类：事务型的事实表、周期型快照事实表、累积快照事实表。不同的事实表具有不同的特点，如下图所示：
事务型的事实表是指每个实体发生一个事物动作，它插入以后不做更新，时期是离散的的事物的变化的时间段，日期的维度是事务的日期，如8月3号下了一笔订单，事件的粒度是ord_id，在8月3号做了下单动作，则整个事务性事实的描述；累积快照事实表主要是对实体的生命周期内的变化状态的表达；周期型快照事实表是对对当前累积的状态的表达。
（5）事实表类型的区别与选择：
事务型的事实表包括单事务事实表和多事务型事实表，前者仅包含一个业务过程，后者则要将多个业务过程设计在一张表中。
首先要识别业务过程，如是下单还是支付，再确定事实表的类型是事务型事实表，还是周期型快照事实表、累积快照事实表等，再确定维度以及粒度是子订单粒度还是父订单粒度等，接下来在事实表中添加度量（订单金额、年龄等），最后进行反范式化的设计增加冗余维度，维度的类型取决于预设的需求，如要分析某些行业下的订单，就会添加行业维度，若要从某些卖家、买家的维度去看订单情况，则会添加买卖家的一些维度属性。设计的基本原则就是完整性，要尽可能地把所有的业务过程相关的事实都设计进来，同时要遵循高内聚低耦合的原则，同样在同一张事实表中粒度必须是唯一的，最后还要在成本和性能之间进行平衡，即反范式化的设计，即以牺牲存储冗余维度减少表表之
间的关联以提升应用性。
①单事务的事实表
以下图片以淘宝的下单为例展示单事务的事实表：
适用于单业务过程的情况下，如淘宝双十一当天成交额、成交单量，而不会做多事务的表里找下单量，否则计算任务更为复杂。该单事务事实表的业务过程是“下单”，确定完业务过程“订单的创建”，然后确定粒度为“子订单粒度”，再添加一些需要的度量的，如订单创建时的创建金额，以及一些维度属性的冗余，如冗余商品的属性、会员的属性等以支持我们整个实施表的设计过程。然后 ds= ＂20211111＂即下单的业务日期。
②多事务的事实表
以下图片以淘宝的下单为例展示多事务的事实表：
将多个业务过程的冗余进来，其有特定的适用场景，如要分析从下单、支付到完结的转化，假设没有这项多事务，则要去下单表、支付表、完结表中统计，三者之间的指标关系较为复杂的。对于这种设计有其自身的好处，多业务过程包括下单、支付、完结，它的粒度其实是子订单的粒度，度量值包括创建金额、支付金额等，冗余的属性同上，对于存储，事务事实表仅插入不更新，即每个分区存储的是每个实体的最新的业务状态，即每个订单的最新状态，如双十一当晚下单，则当晚创建了一条订单 id，而11月13日这笔订单仍停留在创建环节，还未支付，则存的最新的状态还是创建环节，是11日的订单，在14日进行了支付，则会在14日时做支付的动作，就会有支付的标识标识订单处于已支付状态。因此，在多事务物的事实表中可以其中有几个标识，标记当天下单，是否当天支付，是否当天确认收货，然后将这些业务动作去做一些标签，方便取数。如想查询双十一当天下单的，只要 ds=＂20211111＂即可，并且表示 is_create=Y；要查询双十一当天成交金额，则查询 is_pay=Y。综上，多事务物的事实表适用于一次去分析多个业务过程的场景，比单事物的取数更方便，如双十一当天下单和支付的订单，只要取双十一当天的日期，is_create=y 并且 is_pay=y。
③累计快照事实表
以下图片以淘宝的下单为例展示累计快照事实表（全流程）：
如果要查看订单的支付时长进而分析下单到支付、从支付到完结平均时长，进而通过优化整个链路的各个环节来实现，如从下单到支付比日常慢了很多，运营部门就会检测到这种情况进而及时进行业务分析。也就是说在该业务场景下，累计快照事实表设计会更适合，在该过程会将表中的业务过程进行累积表达出来。订单从创建到支付到完结，所有的业务数据都在一张表中，并且其存储的方式是每天都会更新，且在一张表中每个实体只会存储一条记录，这点不同于多事物事实表（存储多条，因为其分区存储状态，如果发生变化，都会进行存储）。而累计快照只会存储一条，并进行数据联合进行分析，如多个业务过程完成时长的分析，如近七天订单从下单到支付的表现：
select sum(pay_time-create time) / count
(order_id) from tbcdm.dwd_tb_trd_ord_flow_di where pay_tim
e> $ {bizdate-7} and (ds> $ {bizdate-7 or ds = '30001231')，pay_time 是近七天支付，分区是近七天的分区数据加最大的分区，ds = '30001231'中 ds 是指存储历史所有完结的订单的日期，“3000”指最大的分区，所有未完结的订单都会在该分区中存储。而所有的完结的订单都根据其完结日期存储到对应的分区。从存储方式的角度，它比多事务事实表的存储简洁了很多，存储资源也省了很多；从分析的角度，它在分析多个业务过程的场景也更便捷。
④周期型快照事实表
除了会员的等级会用到周期型快照之外，我们建造的更多的是 dws 表作为周期型快照的设计。其设计要遵循以下原则：其一，公用性，即把下游使用的多个逻辑抽象出来，并把公共的部分沉淀到汇总层，当下游有多个场景待分析时，将相应的指标做相应的汇总层的设计，同时，在中间层的设计过程中，它不会进行跨域存储。如针对于交易过程，需要观测交易域的指标，其放在交易域内，此外可能还需要观测一些日志域的指标，放在日志域内，这些在做模型设计时要重点考虑。其命名规则：dws_{业务 BU 缩写/ pub}_{数据域缩写}_{数据域粒度缩写}[_{自定义表命名标签缩写}]_{统计时间周期范围缩写}，其中说明了所处法人的业务状态，数据域如何，如日志域，最后还注明了统计的周期。
以下图片以淘宝的下单为例展示累计周期型快照事实表：
以上显示的是商品域的卖家粒度的汇总指标，根据在命名规范中提到的内容，dws 是表头，tb 是业务域，itm 是数据域，slr 是统计粒度，即观测数据的维度，这里的维度是商家域，td是时间周期的表达，表示迄今为止的指标。据此做模型设计时，可以确定其基本特征包括粒度（商家 id）、业务周期（迄今为止每天）、数据存储（其统计的数据时迄今为止每天的数据变化，因此该分区更新的频次是每天）。也就是说，在查看汇总数据时，不需要每次都从明细中查询，这是不现实的，尤其是对于时间周期跨度较大的，因此，对于实体当前的状态会进行汇总层的加工，如查看商家截止到当前历史共上线的商品数量，就可以从该表中查询到历史截止当日的商品数。关于 itm_cnt_ord_009 是按照原来的命名体系命名的，其前前缀是限定词以及时间周期，但其限定词被系统吞并后生成了数字的表达，可能是三位的数字表达，如上图中的086、009等。在某种意义上，该名称不十分易于解读，这是目前还有待优化的内容，也是DataWorks做数据建模模块的原因之一,这一点在后面演示产品时会有所体现。
模型设计很重要的一部分内容是命名规范，以下是常用的从 ODS 到 CDM 层的命名规范：
其中包括了按天增量存或按天全量存及使用小时表或日表的选择，在中间层表的命名也可以以此为参照，包括临时表、汇总表等的命名。
除命名规范之外，还有一个很重要的环节：生命周期的规范设计。
在学习到数据治理对存储进行相关设计时，生命周期规范的合理设计与之有很强的相关性。
