1.概述
方法论的核心：从业务架构设计到模型设计，从数据研发到数据服务，做到数据可管理、可追溯、可规避重复建设。
1.1 定位及价值
- 统一、规范化的数据接入层（ODS）和数据中间层（DWD 和 DWS）
- 提供标准化、共享的数据服务能力
- 降低数据互通成本，释放计算、存储、人力等资源
1.2 体系架构
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ruVWiiac-1650718679685)(.\20220424\微信截图_20220423194919.png)]
业务板块：业务生态庞大，可以根据业务属性划分几个相对独立的业务板块。
规范定义：数据规范命名体系。
模型设计：维度建模。
2.规范定义
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-V2yLt6gc-1650718679686)(.\20220424\微信截图_20220423195233.png)]
2.1 名词解释
数据域：面向业务过程，将业务过程或者维度进行抽象的集合。抽象提炼，长期维护更新，不轻易变动。
业务过程：业务活动事件，例如下单、支付、退款，不可拆分的行为事件。
时间周期：用于明确数据统计时间范围或时间点。
修饰类型：对修饰词的抽象划分，例如访问终端类型。
修饰词：除了统计维度以外指标的业务场景限定抽象，隶属于一种修饰类型，例如 PC 端、无线端。
度量/原子指标：不可拆分，具有明确的业务含义，例如支付金额。
维度：度量的环境，反映业务的一类属性，属性的集合构成维度，例如时间维度、地理维度。
维度属性：隶属于一个维度，例如地理维度里面的国家名称。
派生指标：一个原子指标+多个修饰词+时间周期。例如最近 1 天海外买家支付金额。
2.2 指标体系
略。根据每个公司自己的标准命名。
3.模型设计
3.1 指导理论
维度建模理论，基于维度数据模型总线架构。
3.2 模型层次
分为三层：
- 操作数据层（ODS）：操作系统数据几乎无处理地存放到数据仓库。
- 公共维度模型层（CDM）：存放明细事实数据、维度数据及公共指标汇总数据。CDM 层又细分为明细数据层（DWD）和汇总数据层（DWS）。采用维度建模方法，维度退化手法，将维度退化至事实表，减少事实表和维表的关联，提高明细数据的易用性。汇总数据层加强指标的维度退化，采用宽表化构建公共指标数据层，提高复用性，减少重复加工。
- 应用数据层（ADS）：存放个性化的统计指标数据。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-RMKDB4zb-1650718679687)(.\20220424\微信截图_20220423202456.png)]
3.3 基本原则
- 高内聚和低耦合
- 业务特性：业务相近和相关、粒度相同的数据设计为一个逻辑或物理模型
- 访问特性：高概率同时访问的数据放一起，低概率同时访问的数据分开
- 核心模型于扩展模型分离
- 核心模型：字段支持核心业务，做到简洁、可维护
- 扩展模型：字段支持个性化或少量应用
- 公共处理逻辑下沉及单一
- 底层公用的处理逻辑在底层进行封装与实现
- 不应让应用层实现
- 不应让公共逻辑多出同时存在
- 成本于性能平衡：不宜过度冗余
- 数据可回滚：多次运行，将结果不变
- 一致性：相同字段在不同表中命名相同
- 命名清晰、可理解
4.模型实施
4.1 业界常用模型实施过程
4.1.1 Kimball 模型实施过程
- 高层设计：定义业务过程维度模型的范围，每种星形模型的技术和功能描述；
- 详细模型设计：每个星形模型添加属性和度量信息；
- 模型审查、再设计、验证
- 产生详细设计文档，提交 ETL 设计和开发
4.1.2 Inmon 模型实施过程
分三个层次：ERD（Entity Relationship Diagram，实体关系图）层，DIS（Data Item Set，数据项集）层，物理层（Physical Model，物理模型）。
采用螺旋式开发，迭代方式完成多次需求。
4.1.3 其他模型实施过程
- 业务建模：解决业务层面的分解和程序化。
- 领域建模：对业务模型进行抽象处理。
- 逻辑建模：将领域模型的概念实体以及实体之间的关系进行数据库层次的逻辑化。
- 物理建模：针对不同关系数据库的物理化、性能等技术问题。
4.2 阿里的实施过程
- 数据调研：业务调研（业务系统的业务），需求调研（分析师运营人员）
- 架构设计：数据与划分（面向业务分析，将业务过程和维度进行抽象）
- 构建总线矩阵：业务过程所属数据域，业务过程与维度的关系
- 明确统计指标：原子指标，派生指标
- 规范定义：构建一致性逻辑维度及维度属性，构建一致性度量及指标
- 模型设计
