微盟离线数仓模型建设与治理实践

2.1 业务调研   

在 WOS 系统重构的时候，微盟业务从之前的快速扩张阶段进入相对稳定的发展阶段，业务发展进入成熟期。由于业务很多且复杂，这里主要简述一下大致流程。从上图可以看出，业务流程主要分两大块，商业化前和商业化后。商业化前是指微盟客户还未成为微盟商户之前一系列的业务动作，商业化后是指微盟客户成为微盟商户之后的一系列的业务动作。按照这个思路把每个业务环节可能产生的数据以及数据对应的系统梳理清楚，方便后续数仓的建设。          

2.2.数据域划分  

• 划分原则：按数据类型进行划分。比如导购订单的数据，那应该是按订单进行划分到对应的数据域，而不是按导购进行划分到对应的数据域，导购在这类数据只是一个维度。
• 划分范围：数据域划分范围是指数仓DWD、DWS、DIM层。
• 命名规则：一共划分为数据域和数据子域两层，优先对数据子域命名。数据子域命名规则：
• 按业务过程命名或者业务过程总称：比如交易流程中，常见的下单、支付等业务过程。该数据对应的数据子域就直接叫下单、支付。
• 按实体对象命名：比如商品名称、编码图片等商品属性信息，这类数据对应的数据子域就直接叫商品。
• 按业务名称命名：比如在做工单分析、数据治理或者体量很小的业务需求的时候，这类数据就没必要严格按照业务过程或者实体对象去细化数据子域，故这类数据就直接按治理、工单直接命名数据子域。

数据子域命名结束可以对数据域取一个适当的总称（没有具体规则）。

2.3.数仓分层架构  

• ODS（贴源层）：把OLTP的数据几乎无处理的存放在数据仓库系统中，一般采用增量或全量同步，需要关注源系统的性能和重复存储的成本。
• DWD（明细层）：使用维度建模方法，采用维度退化手法将维度退化至事实表，对业务过程进行重新建模，构建符合需求细粒度的明细层事实表。提升数据易用性方便上层数据的加工和计算。明细粒度事实层通常分为三种：事务事实表、周期快照事实表和累积快照事实表。因为具有通用性，需要关注数据的易用性、稳定性。
• DWS（汇总层）：公共汇总粒度事实层以分析的主题对象作为建模驱动，基于ADS上层的应用和产品的指标需求构建公共粒度的汇总指标事实表。沉淀共用指标、减少重复计算，保证指标口径统一。因为具有通用性，需要关注数据的易用性、稳定性。
• DIM（维度层）：基于维度建模理念思想，建立整个企业的一致性维度。降低数据计算口径和算法不统一风险。公共维度层的表通常也被称为逻辑维度表，维度和维度逻辑表通常一一对应。
• ADS（集市层）：分析上层应用，按照业务角度组织数据，快速响应业务需求，可以关联一些维度表进行补充维度。需要关注研发效率、口径一致性、稳定性。注意：该层尽量不要有指标计算逻辑。
• OUTPUT（导出层）：基于ads计算好的结果，推送到下游数据库，可以做一些数据的过滤。因为涉及跟外部系统关联，需要关注目标系统的性能、任务稳定性。注意：该层禁止出现指标加工、维度补充逻辑。

2.4.模型建设  

四种常见的建模方法：

1. 维度建模：维度建模从分析决策的需求出发而构建模型，为分析需求服务。因为重点关注用户如何快速的完成数据分析，可以直观的反应业务模型中的业务问题，需要大量的数据预处理、数据冗余，有较好的大规模复杂查询的响应性能。
2. 范式建模：即实体关系（ER）模型，数据仓库之父 Immon 提出的，从全企业的高度设计一个 3NF 模型，用实体加关系描述的数据模型描述企业业务架构，在范式理论上符合 3NF。此建模方法，对建模人员的能力要求非常高。
3. Data Vault模型：DataVault由Hub（关键核心业务实体）、Link（关系）、Satellite（实体属性） 三部分组成 ，是Dan Linstedt发起创建的一种模型方法论，它是在 ER 关系模型上的衍生，同时设计的出发点也是为了实现数据的整合，并非为数据决策分析直接使用。
4. Anchor模型：高度可扩展的模型，所有的扩展只是添加而不是修改，因此它将模型规范到6NF，基本变成了K-V 结构模型。

维度建模  

1. 业务过程是组织完成的操作型活动，比如订单下单、处理售后订单、营销活动创建等。业务过程中事件建立或获取度量，并转换为事实表中的事实。这里需要关注重点是业务过程，并非是某个业务部门。确保某个业务过程的核心数据只被抽取一次，保证数仓中业务数据一致性。
2. 声明粒度是维度建模重要步骤。粒度是用于确定事实表中行表示声明。在业务过程获取的数据时，原子粒度是最低级别的粒度。建议从原子粒度设计开始，因为原子粒度才能满足对汇总粒度的数据最好解释，也能够满足用户对数据的最细粒度分析需求。在同一个事实表中不要把不同粒度的数据放到一起。
3. 维度是对某一个业务过程事件所涉及到的谁、何处、何时等背景。维度在数仓非常可以称为“灵魂”。因为维度是数仓BI系统业务分析的入口。
4. 事实是业务过程事件的度量，大多数是数量值表示。事实表中一行跟按事实表的粒度描述的度量事件是一对一的关系。在事实表里面，我们只允许与声明的粒度保持一致。

模型分层设计原则   

数仓建模主要是指DWD、DWS、DIM，而ADS主要是分析业务需求，通过新建模型或者复用数仓现有模型，组装成宽表形式，推送给下游使用。

1. 只选择与业务过程相关的事实。
2. 分解不可加性事实为可加的组件。
3. 在选择维度和事实之前必须先声明粒度。
4. 在同一个事实表中不能有多种不同粒度的事实。
5. 事实的单位要保持一致。
6. 标准化处理Null值（或者空字符串）、异常值、离散值。
1. Null值处理：如果字段类型为数字型，Null赋予-88888，如果字段类型为字符串类型，Null赋予unknown。
2. 异常值：如果确认是异常值，需要处理掉。
3. 离散值：如果个别值不应该出现，比如下单时间是1970年，这种也必须处理掉。
7. 使用退化维度提高事实表的易用性。
   例如：订单号也是一种维度，退化到下单模型事实表中。

1. 由于各业务方去重指标计算口径和维度都不一样，故 DWS 基于上层的应用和产品的指标需求，对 DWS 各业务过程进行轻度汇总，构建多维度+可累加的指标+用于去重指标计算的字段(各业务方在基于结果再出固定维度的 DWS 模型)。以宽表化手段物理化模型，构建命名规范、累计指标口径一致的统计指标，为上层提供公共指标，建立轻度汇总事实表。
2. 聚集是不跨越事实的。聚集是针对原始模型进行的汇总。为获取和查询与原始模型一致的结果，聚集的维度和度量必须与原始模型保持一致，因此聚集是不跨越事实的。
3. 聚集会带来查询性能的提升，但聚集也会增加 ETL 维护的难度。当维度发生变更时，先前存在的、已经被汇总到聚集表中的数据需要被重新调整。
4. 统计不跨数据域。数据域是在较高层次上对数据进行分类聚集的抽象。数据域通常以业务过程进行分类，例如交易统一划到交易域下， 商品的新增、修改放到商品域下。
5. 区分统计周期。在表的命名上要能说明数据的统计周期。
6. 标准化处理Null值（或者空字符串）、异常值、离散值。
1. Null值处理：如果字段类型为数字型，Null赋予-88888，如果字段类型为字符串类型，Null赋予unknown。
2. 异常值：如果确认是异常值，需要处理掉。
3. 离散值：如果个别值不应该出现，比如下单时间1970年，这种也必须处理掉。

1. 维度表信息不易过大。
2. 维表和其他表关联，建议走Map Join。
3. 静态维表不用每日更新，可以按需更新。
4. 维表中数据的稳定性，业务系统如果有逻辑删除，维度表的数据需要保留下来，不能直接逻辑剔除掉。
5. 维表是否需要垂直拆分。如果一个维表存在大量属性不被使用，或由于承载过多属性字段导致查询变慢，则需要考虑对字段进行拆分，创建多个维表。
6. 维表是否需要水平拆分。如果记录之间有明显的界限，可以考虑拆成多个表或设计成多级分区。
7. 核心维表的产出时间应该有严格监控。
8. 标准化处理Null值（或者空字符串）、异常值、离散值。
1. Null值处理：如果字段类型为数字型，Null赋予-88888，如果字段类型为字符串类型，Null赋予unknown。
2. 异常值：如果确认是异常值，需要处理掉。
3. 离散值：如果个别值不应该出现，比如下单时间1970年，这种也必须处理掉。

3.实践结果  

3.1.数仓分层结果  

3.2.数据域划分结果  

3.3.模型设计案例  

案例A：DWD设计  

案例B：DWS设计  

案例C：DIM设计  

         

3.4模型分层分布实践结果  

4.1.实践遇到的问题  

• 依赖不规范：比如数据研发接收到业务需求，然后 OUTPUT 任务直接依赖 ODS，没有进行模型建设。
• 模型重复建设：比如A开发组建设了商户权益模型，后来B开发组又建设了商户权益模型。
• 模型过度设计：比如A开发组新来一个需求，只需要在B开发组的模型增加一个字段就可以满足需求，但是B由于某些原因没接受该需求，导致A开发组基于B开发组的模型又设计一个新的模型来支持新的需求。
• 表命名不规范：由于各个开发人员开发习惯不一样，导致表名在命名上千奇百怪。
• 表描述不规范：由于之前系统未强制要求写表描述，导致有些模型没有表的描述，以至于后续盘点数据资产就会大大增加时间成本。
• ADS逻辑未下沉到公共层：由于项目开发时间紧急，导致一些公共逻辑未沉淀到存量DWS、DWD模型或者新增的DWS、DWD模型。

4.2.治理方案  

事前  

1. 通过产品系统化标准管理，把数仓规划、维度建模、数据指标、数据标准等这些标准定义内容植入系统中，使得增量模型规范化，提高模型规范度。
2. 数据建模最终是体现在以表的物理形式存在，通过对表创建详细管理，有利于模型日常运维管理和降低数据资产盘点成本。在创建表的时候需要选择模型分层，在选择dwd\dim\dws分层会出现子数据域，选择ads分层会出现主题域（各业务线根据数据应用在数据建模-->数仓规划-->主题域，添加对应主题域）。除此之外还需要补充数据归属业务线、该表的自定义信息（通过下拉词根选择）、表的汇总(明细)形式。

事中  

1. 项目/需求名称：本需求文档是哪个项目或者是某个需求。
2. 需求背景/场景描述：需求是由啥原因产生的。
3. 需求内容/目的：需求要解决啥问题，达到啥目的。
4. 需求价值：主要衡量是否个性化需求或者通用需求。
5. 需求优先级：需求在一个迭代版本中优先级。
6. 迭代模块：需求要改哪块内容。
7. 指标口径：需求涉及的指标口径算法是什么。
8. 数据输出展示格式特别说明：数据需要输出展示的时候，数据格式是否有要求。

1. 需求梳理：主要输出需求维度\指标\口径。
2. 数仓分层设计数据流向图：主要输出模型分层及模型数据流向。
3. 数仓逻辑模型设计说明：主要输出模型主要的属性\维度\事实指标及模型之间的关系
4. 数仓物理模型设计概要说明：主要输出模型所属分层、库名、表名、中文名等概要信息。
5. 数仓物理模型设计详细说明：主要输出模型分区、字段名、字段名称等表结构详细信息

1. 数据完整性检查：数据每一项都应该被记录，可以通过对字段进行为空或者为空字符串进行检查。
2. 数据唯一性检查：数据是否存在重复，每条数据是否是唯一的，可以通过对主键或者自定义复合字段检测是否重复。
3. 数据一致性检查：即数据在迁移或者加工前后是否一致，可以通过数仓各层进行的数据量验证，也可以通过报表跟其他报表/业务系统数据验证。
4. 数据准确性检查：准确性是指该数据是否能反映业务的内容，可以对数据的某些字段的总和检测、平均值检测、最大最小值检测是否与业务状况相似。
5. 数据有效性检查：有效性是指该数据是否符合规则，如日期字段的数据是否符合统一的日期格式，金额的字段数值范围是否合理，身份证字段数据是否合规等。

1. 上线前准备具体事项、依赖、时间、负责人、验证人、验证状态。
2. 发布阶段具体事项、依赖、时间、负责人、验证人、验证状态。
3. 线上验证具体事项、依赖、时间、负责人、验证人、验证状态。
4. 回滚前准备具体事项、依赖、时间、负责人、验证人、验证状态。
5. 回滚阶段具体事项、依赖、时间、负责人、验证人、验证状态。
6. 回滚后具体事项、依赖、时间、负责人、验证人、验证状态。

事后  

1. 模型覆盖度是指数仓中(DWS、ADS、OUTPUT总任务数)-(DWS、ADS、OUTPUT直接引用ODS数据的任务数)/DWS、ADS、OUTPUT总任务数*100%；
2. 模型复用度是指数仓中DWD、DWS、DIM被下游任务复用次数/DWD、DWS、DIM的任务数。一个模型被一个任务复用计算一次，被多个任务复用则累加。

4.3.治理效果  

       

• 通过优化数据资产大盘，方便研发人员快速查找现有模型，进而进行复用。
• 通过数据建模，对新的模型进行维度管理，新增模型纳入审批流程，减少模型重复建设。
• 通过对开发任务代码进行分段扫描，分析出不合理的重复代码，纳入治理中心进行专项治理。