维度建模基本流程总结

一、维度建模基本流程图

数据RD进行业务调研和数据现状调研，产出符合相关模版规范的业务知识文档和数据现状文档。数据PM也会调研相关业务产出需求设计文档，三方参与需求评审，评审通过后基建数据RD进行需求拆解，产出技术方案，三方进行技术方案评审，如果技术方案评审通过进入基建需求池、排期、开发、上线并做相关数据运营动作。

二、维度建模流程详情

详细流程主要介绍每个步骤的参与方、行动详情、产出结果并明确相关的check机制。

2.1 业务调研

关键动作

业务调研主要是业务方、数据PM、数据RD参与，数据RD具体动作如下：

1.理解业务环境，通过和业务方代表交流发现需求，用于理解他们基于关键性能指标、竞争性商业问题、决策制定过程、支持分析需求的目标。

2.梳理业务过程，通过和源系统专家交流信息、业务方的描述信息梳理业务过程，业务过程是一个不可拆分的行为事件。

3.分析关键业务和核心问题，分析关键业务及其动作是什么，明确业务现阶段所关注的核心问题，对核心问题的理解有助于我们覆盖业务场景。

核心成果

业务调研完成后，需要编写业务知识文档，此文档可以按照如下思路整理

1.业务简介，源系统业务简单概述，明确决策过程和分析目标等。

2.统一业务概念，将源数据（即业务系统）中隐含的、有歧义的概念进行清晰化。

3.业务流程介绍，重点关注源系统的ER模型，整理业务流程图，梳理业务基本动作等。

4.总结业务对数据的需求，重点梳理业务指标。

业务调研步骤可重可轻，重：基建层面从质量、效率、成本和扩展性长远考虑需要深入调研并理解。①质量: 通过数据集成和一致性建设，提升数据指标的一致性及及时性；②效率：提升计算、存储、查询效率，提升用户体验；③成本：减少不必要的数据冗余、提升模型复用度，降低存储、计算以及维护开发、降低成本。④扩展：屏蔽业务及上游系统的变更影响，能灵活快速兼容业务变更以及支撑新业务。

轻：根据需求紧急程度，结合原有调研的相关知识，快速支持业务需求。

2.2 数据现状调研

关键动作

数据现状调研主要是数据PM、数据RD参与，关键动作如下：

1.数据PM需要梳理历史定义的数据指标口径，这部分口径解决什么问题（随着时间推移历史指标口径不明确，解释不清等）。

2.从数据RD角度需要梳理之前产出的模型、看板、数据产品，不同的交付方式所对应的模型是否相同，有没有口径不统一的风险。同时将这部分涉及的底表列出来，还没有接入的提前接入。

核心成果

1.数据RD明确指标如何使用：主要是通过表格描述清楚之前的看板和产品使用的模型、模型对应的指标。

2.历史指标及其口径，从数据PM角度需要了解之前定义的数据指标口径，这部分口径解决什么问题。

3.初步给出一些优化改进建议，比如重复逻辑下沉、重复开发优化等。

2.3 主题抽象&总线矩阵

关键动作

主要由数据RD完成，关键动作如下：

1.明确数仓建设的相关分层和命名规范。

2.明确数据域的抽象划分。

3.明确主题、业务过程及其对应关系。

4.明确业务过程和一致性维度关系。

核心成果

产出相关文档，主要包含①主题、词根和主题对应业务过程关系表；②主题和一致性维度矩阵，方便从宏观认识整个数仓；③每个主题下业务过程和一致性维度关系矩阵。

2.4 数据需求设计

关键动作

主要由数据PM完成，关键动作如下：

1.明确背景和业务价值。

2.如果是涉及到产品化的项目需要明确产品或报表工具，设计相关原型图。如果只提供数据集，需要明确指标如何使用，作用的结果。

3.定义清楚维度和指标（偏应用层指标）

4.明确期望交付时间、交付结果，数据回刷范围等。

关键产出就是需求文档（PRD）。

需求PRD产出后需要组织业务方、数据RD和PM进行需求评审，主要check 需求评审文档，是否符合既定规范，价值描述清晰、维度和指标口径，数据范围、交付时间等。

2.5 数据需求拆解

关键动作

主要由数据RD完成，关键动作如下：

事实表设计：

1.选择业务过程：选择主题域明确主题下的业务过程，选择具体的业务过程（在主题域内根据情况会抽象新增/合并业务过程）开始拆解。

2.确定事实表，根据需求设计合适的事实表类型，事务事实表、周期快照事实表、累积快照事实表。

3.声明粒度，在从给定的业务过程中获取数据时，原子粒度是最低级别的粒度，建议优先关注原子粒度数据开始设计，原子粒度数据能承受无法预期的用户查询，然后根据针对业务公共问题和性能出发设计上卷汇总粒度数据表。

4.确认维度：维度是度量的环境，用来反映业务的一类属性，这类属性的集合构成一个维度，也可以成为实体对象。在实际工作中好的维度设计可以层次递进的反应业务情况

5.确认事实（指标）：事实就是度量，一般是对某个业务事件的衡量，通常为数字，如定单量，订单金额等。尽可能包含业务过程下所有原子指标，只选择和业务过程相关的原子指标，统一同类指标的单位。根据规范对指标拆解：①确定原子指标：基于某一业务时间行为下的度量，是业务定义中不可再拆分的指标（比率等指标除外），具有明确业务含义和业务完整定义的名词。原子指标=业务过程（动作）+度量，比如推单量，下单金额，支付金额；②确定派生指标：派生指标=一个原子指标+多个修饰词（可选）+时间周期。可以理解为对原子指标业务统计范围的圈定。比如昨日新用户下单量

6.梳理具体业务过程下的指标维度矩阵。

维表表设计

1.选择实体

维度表设计首先要选择实体，也就是维度表所要描述的抽象对象。如，互联网电商在交易过程中涉及到的实体有：买家、卖家、订单、广告等等，当然还有一些在不同业务场景下衍生出来的一些业务抽象实体，如优惠券、活动、商圈等都可以作为维度实体。 实体的选择主要是结合业务流程，在需要建模的业务流程环节涉及到了哪些参与者，这些不同的参与者便是维度表描述的实体对象，维度表中的属性，就是用来区分不同实体的特性。

2.确定主维表

确定主维表，主要是识别出维度表的主要数据来源。通常，业务系统中也会将相同类型业务实体进行统一存储（即一张表），亦或是在大型企业有建设业务中台会提前做同类业务实体的数据融合（如，商品中心、用户中心等）。但在没有类似业务中台可以直接获取全量维度实体数据的情况下，就需要自行确定业务实体数据的来源，并做融合。一般情况会将常规主要业务流程中产生的业务系统数据做为主维度表，因为其一般是维度表的主要数据来源，并且数据准确、丰富。

3.确定辅维表

辅维表存在的目的有两方面。一方面是补全主维表在维度实体的数据；另一方面是为了寻找维度表所表示的业务实体的一些其他属性描述辅助表，这些辅维表用来丰富维度表的属性描述，增强维度表的表现性，同样也能扩展维度表的分析能力。

4.识别维度属性

维度表的维度属性一般可以分为相对稳定的“固化属性”和变动频繁“动态属性“。由于“固化属性”和“动态属性”的变更周期差异巨大，一般会在维度表的构建过程中结合具体的场景进行拆分，一方面是保证维度表能够高效的产出，另一方面也是为追溯历史数据提供合理的技术实现。

注意点：增加文字描述（枚举和中文对应关系）；统一单位；统一标志值（0/1，Y/N）等。

关键结果

产出业务过程下的指标维度矩阵。

2.6 技术方案设计和评审

主要由数据RD完成技术方案设计，然后组织PM和RD进行技术方案评审，关键动作如下：

1.原则上遵循公司数仓建模规范或数据仓库工具箱相关规范。

2.编写技术方案，背景部分主要阐述业务痛点和目标；需求梳理主要是明确我们开发的指标维度矩阵；核心模型设计即数仓整体架构设计（服务规范）和表详情设计，表详情设计部分主要明确三个部分①表的中英文名称②指标名和口径③指标加工逻辑和相关数据调研；最后技术方案中明确上线事项和分工排期。

关键结果

产出技术方案，技术方案可以分如下几个模块①项目背景，附上相关PRD和说明文档链接，介绍清楚背景收益等；②问题和风险，对于存在的问题和风险（业务风险、技术风险）应当有对应的方案，如存在风险或问题情况下，仍按需求进行，需要明确相关责任人。③项目计划，明确相关责任人和具体开发排期。④需求调研，调研需求的指标、维度和相关接口。⑤详细设计，第一部分给出整体的设计架构图；第二部分接口设计详情；第三部分数仓模型设计；⑥技术选型，重点关注查询引擎，查询量级，QPS等；⑦上线事项：测试case、上线顺序、上线Check List、承诺产出时间，稳定性保障、降级策略（数据延迟、集群异常等兜底方案是否可以使用T+2的数据，前端进行banner文案提示“数据暂不可用”，对外提供接口方式，应当与数据使用方商定出现无数据情况的后端兜底或者前端兜底。数据内容本身的错误和BUG无法进行兜底，责任由数仓RD来进行负责并处理。）

2.7 数据交付&运营

对相关指标进行绑定录入，编写使用文档等。