数仓维度模型设计方法论概述

Table of Contents

1. 框架确立

在框架确立前，首先知道当前场景的痛点和特征，依据这些因素调整通用的方法论。没有方法论能够在各种场景一成不变，也没有万金油的方法论，只有最适合的方法论。
一旦方向目标有了，就确认分部分项需要完成的内容，建模的每一步都是串联、互相依赖的，开工后不可再做步骤上的调整，也不可返工回头做修改。

业务调研分为系统调研、业务流程调研、业务域调研、库表调研、数据调研，由粗到细，宏观到微观，如果治理人员对业务完全没有接触，需要在这个基础上再加上业务定义调研。

从业务系统上能明确看到产品对当前业务的划分，也就是部分业务域，从业务系统上能够大体了解到业务如何流转，核心内容集中在哪些业务单元。

业务流程是串联整个业务板块的链路，由哪个业务单元开始，经过哪个，再到哪个。给业务单元排序的同时，更有助于对业务的理解。

业务域不一定体现在产品上，这一点需要和产品再做确认，部分线下的业务并不由产品直接管理。做全域的数仓设计，一定要保证业务域全面了解。

库表调研，也就是元数据调研，治理人员即数据专员，归根到底还是用数据描述、用数据说话。通过库表元数据，能够了解到各个业务存储位置、在业务模型中的定位和关系，且为后续数据流提供参考。

最后是数据调研，数据治理的核心问题在落地，很少能够有一套组织架构能提供完整的支持来推动数据治理，所以在业务输入不足的前提下，通过数据能够提高自身对业务的判断，元数据佐以数据，对部分业务进行推测。

在有了以上业务调研成果后，需要凭借经验和判断，找到高频的业务数据、及核心的业务单元。确认核心内容后，围绕着这部分对数仓进行设计。

数据域是OneData建模的第一步，把不同的业务动作抽象成不同的集合，把业务板块划分成不同的几个分组，例如：人员域。

业务过程是各个数据域的元素，数据域由多个不同的行为动作组成，业务过程即一个个不可拆分的动作，例如：个人信息登记。

有个业务过程，就需要把不同的业务表、业务单元，归纳到各个过程中，识别出哪些表格是事实，哪些表是支撑事实描述事实的维度。

根据数据域和每个数据域的公共维度，钩织成二维的矩阵，解析出每一个业务过程，分别能够从哪些公共维度进行分析。总线矩阵是模型设计的指导、也是数据应用的概览，体现出该域数据分析的价值。

根据业务过程，制定事实表和维度表。退化关联表和部分小维表，消除间接关联。通过数据标准对模型及字段、备注进行规范化命名，使用代码字典规范枚举值和代码值。总体原则是方便下游分析及使用。数据库的设计要综合考虑技术架构和产品形态，尽可能贴近并耦合。

模型设计后，为评估模型的适用性、易用性和业务相关性，需要业务、需求方共同参与评审会议，在模型设计流程和成果上做讲解达成共识，并吸收各方意见。后续根据评审意见进行模型调整和迭代，在调整幅度较大时，有必要进行二次评审。