2数据仓库生命周期_数据路线（读书笔记）

数据路径

4.1维度建模

• 分析收集到的业务访谈需求，画出详细的业务流程图，确定命名约定。

• 根据业务需求、业务流程图，分析得到业务过程涉及的维度、事实，建设一致性维度，建设数据仓库总线矩阵，确立数据架构。

• 从总线举证派生初始图形模型，确定设计范围、明确事实表粒度，明确每个事实表的主要维度，明确所有需要补充调查的问题，得到高层模型图。然后针对每个表进行组装，并向下钻取到定义、数据源、关系、数据质量问题和所需的转换。

• 最后，与业务方审查和验证模型。通过多次测试直到模型满足业务需求，则完成设计。

• 关键提交物：高层模型图、属性和度量列表、详细维度设计工作表、问题列表。

4.1.1关键提交物

得到的设计文档包括：

• 业务过程简要描述。

• 高层数据模型图。

• 属性和度量列表

• 每个维度表和事实表的详细维度设计工作表

• 公开问题列表，突出标识尚未解决的问题

4.1.2组件建模团队

有效控制风险和工作量的key point：

4.1.3维度模型建模步骤

1.选取业务过程

2.声明粒度

3.识别维度

4.识别事实

4.1.4建设高层维度模型

高层模型显示了一个给定的业务过程的具体事实和维度表。便于和业务人员、干系人沟通、讨论，是详细设计的切入点。

1.召开设计会议：

2.直接目标是创建高层维度模型图，对业务过程中的维度表和事实表的图形描述，接着为维表创建初始属性列表、为事实表创建度量。

3.为高层模型图编制文档：

4.识别维度和度量：

完成高层模型后，开始维度和度量的识别。按照4步骤推动设计，对业务过程的维度属性进行初始化，接着是事实表的度量。

得到初始维度和度量清单：

4.1.5建设详细维度模型

详细的维度模型设计阶段，填补高层模型缺失的信息，解决设计问题，不断测试模型是否满足业务需求。从每张表、每一列定义详细的维度模型。每次只关注1~2张表。从维度表开始，然后处理事实表。建议从简单、易懂的维度开始，例如日期维度。

1.识别元数据：

找出适用于填充目标设计模型的源数据。

2.了解候选数据源：

为每个维度和事实表明确数据源。了解候选数据源，从需求中、总线矩阵中识别数据源，得到候选数据源列表。

3.数据探查和选定数据源

根据候选数据源列表，评估每个数据源，确定最佳数据源。收集并审查可用的源系统文档，如数据模型、文件定义、记录格式、书面文档和源系统程序。基本数据源的选择参考：数据可访问性、数据供给的持久性、数据准确性。

数据探查是对数据源内容的系统分析，涉及的范围从计算字节数、检查基数到检查数据是否满足DW/BI的要求等更为深入的分析。数仓迭代过程中，每个数据源都需要进行详细的数据探查，且探查结果有助于选择最优源系统。数据探查是一系列的测试：

• 对单个字段的探查，检查内容是否和基本数据定义及定义域声明一致，有多少行赋有空值或背离定义域的内容。

• 调查不同字段间的关系，使用结构筛选法，显示数据表中的键，与高层的多对多关系形成的层级。

• 检查键值的唯一性。

• 检查表和表之间的关系，主键和外键间的关系，是否出现没有子类的父类。

• 检查企业中特有的复杂业务规则。

数据探查的结果：

• 确认候选数据可行/不可行。

• 在数仓建设前发现并修复源系统的问题。

• 从源系统抽取数据时，通过ETL过程修正数据质量问题。

• 发现未预料到的业务规则、层次结构和外键-主键关联。

4.确定一致性维度

在详细设计中，定义关键的一致性维度。对企业各部门的表及属性命名、描述和定义达成共识，便于后期用户对维度模型的理解和接受。

5.确定基本事实和导出事实

根据业务需求，定义度量、整理事实信息文档，包括基本事实、导出事实，导出事实中的可加事实、非可加事实（累积事实、比率）。

在ETL过程设计前，定义完所有基本事实。

对于导出事实，明确支持导出事实计算所需要的基本事实，并记录在文档中。

6.为详细表设计编制文档

详细建模阶段的关键提交物是详细设计工作表。

• 每个维度和事实表都对应一个单独的详细表设计。包括属性/事实名、描述、样值，每个维度属性都对应一个缓慢变化维类型标识。

• 详细事实表设计要明确外键关系、恰当的退化维和每个事实的规则，规则说明事实是可加、半可加、不可加。

• 在详细设计过程中，捕捉用户所期望的属性和事实，发掘在初期没有发现的属性和事实。

• 将设计过程中做好记录，包括发现的问题、定义、转换规则和数据质量问题、使用到的特殊设计方法（杂项维、小型维、桥接表）。

7.更新总线矩阵识别和解决建模问题

详细建模过程中，会发现业务过程新的信息，可能引入新事实、维度，维度的分割或组合灯。因此在设计过程中，要及时更新总线举证，便于与其他人员沟通时使用的总线矩阵是符合实际的最新信息。

8.识别和解决建模问题

详细设计中发现的问题，可能会导致高层模型的修改，对源系统的分析可以揭示出原先没有发现的有利因素和约束，可能会产生一些维度的设计决策，可能导致事实表粒度的改变或者产生新的事实表，也可能会发现一些新的业务需求。

在建模过程中发现问题时，应该及时对这些问题进行跟踪并找出相关的解决方案。及时记录问题，并确认问题的分配。

4.1.6审查和验证模型

完成详细设计后，金融模型审查和验证阶段。设计团队需要与三个团体进行讨论：

1. 源系统开发人员、数据库管理人员；

数据模型审查，与对源系统业务过程属性的IT同事共同进行。

• 第一，要明确维度建模分析与实务处理的不同，解释维度建模相关理念。

• 第二，审查总线矩阵，了解项目范围和全局数据架构，论证一致性维度，给出业务过程优先级，解释高层模型。

• 第三，逐个检查维度表和事实表。

• 第四，审查尚未解决的问题。

2. 没有直接参与模型开发的核心业务用户；

基本过程与IT讨论类似，核心用户关注模型的业务细节，小型机构中可以与IT讨论一起完成。

3. 向业务用户介绍；

基本过程与IT讨论类似。此外，通过实例问题，一步步向业务人员介绍维度模型如何支持业务需求。

4.2物理设计

由于项目、平台之间的差异，物理实现的细节也会有所差异，项目的数据量是主要的驱动因素之一，尽管业务需求和逻辑设计都是相同的，但是完成一个TB数据量的数据仓库的物理设计远比设计一个GB数据量的数据库更复杂。

4.2.1关键提交物

• 物理数据模型

• 最终的源到目标映射表

• 初步的索引方案

• OLAP数据库设计

• 聚集方案

• 分区方案

4.2.2团队建设

保证质量的关键：

4.2.3制定标准

DW/BI系统中的各个组件，需要在全系统内制定统一标准并遵守统一标准。包括：

• 统一命名约定

• 字段是否为空&处理方式

• 设置登台表

• 制定文件位置标准

• 对用户访问的表使用代用名或者视图

• 确定主键数据类型与生成规则

4.2.4设计物理数据模型&创建开发数据库

• 设计物理数据结构

• 确定源到目标的映射

• 使用数据建模工具

• 进行初步的规模估计

• 创建开发数据库

4.2.6设计处理数据存储

其他类型的表作为整个BI系统的一部分来进行设计和部署：

• 支持ETL系统的登台表

• 用于ETL处理和数据质量的审计表

• 用于监视用户访问情况的访问监视表

• 安全表

4.2.7设计初始索引方案

• 为维度表建立索引。主键建立唯一索引，常用作筛选条件的属性列建立位图索引或row header。不支持位图索引的可以建立b树索引。为每个用于链接、筛选的列或列分组建立单独的索引。

• 为事实表建立索引。事实表首选索引是建立在主键上的B-tree索引或聚簇索引。

• 为装载数据建立索引。保证系统装载和维护周期尽可能的短。

• 为OLAP建立索引。创建维度关系数据库，作为OLAP输入针对维度关系数据库上执行的用于维度处理、完全多维数据集处理和增量多维数据集处理的查询，为关系数据仓库添加索引，使之支持OLAP处理。

• 装载后分析表和索引，对表和索引进行分析便于设计高效的查询方案。

4.2.8设计聚集

聚集就是通过执行含有Group by字句的SQL查询生成的汇总表。

• 通过监视查询，确定聚集设计的内容，将聚集的规模与使用情况相平衡。

• 维护聚集。创建完成后，随时时间的推移维护聚集。

4.2.9设计物理存储结构

• 计算表和索引的大小

• 设计分区方案

• 设置数据存储方案。

4.3ETL设计和开发

• 维度表转储处理

• 事实表转储处理