数据仓库建模流程

发表于 更新于 分类于 Waline：

模型设计的三个阶段：

  • 概念模型
  • 逻辑模型
  • 物理模型

概念模型

概念模型需要确定系统的核心以及划清系统范围和边界，主要是指通过分析和归纳，将业务划分成几个主题，并确定主题之间的关系

比如：
电影行业：影院、影片、影人、用户、订单、渠道、发行等
出行行业：司机、乘客、订单、支付、车辆等
电商行业：订单、支付、售后、物流、流量等
保险行业：客户、渠道、理赔、核保、团体、风控、人管等

概念模型阶段重点:

  • 注重全局的理解而非细节
  • 在概念模型阶段，即需要对整体架构做思考概念模型通常是自上而下的模式，通过会议等模式反复沟通，澄清需求
  • 在此阶段，应粗略地估算出整个项目需要的时间以及项目计划草案
  • 根据计划粗略地估算出项目的费用
  • 是数据模型工程师与客户沟通的破冰之旅，使他们在此期间达成共识并奠定未来良好的沟通基础以及私人关系
  • 出品的概念模型可以帮助划定系统边界以及避免方向性的错误
  • 商业主导，相比技术专家而言，更需要商业专家
  • 是未来逻辑模型的沟通基础，以及逐步求精的依据

概念模型交付品通常具备如下特点：

  • 与客户（业务需求方）一致的商业语言
  • 尽量一页纸描述清楚整个模型
  • 通常用实体关系型图表示，但不需添加实体的属性
  • 允许多对多的关系存在

这个阶段一般由架构师，项目负责人，项目经理主导，与业务需求方人员开会讨论，确定需求。

逻辑模型

逻辑模型需要梳理业务规则以及对概念模型的求精，在概念模型的基础上，定义数据仓库各种实体、属性、关系，指导后续的数据存储、组织和数据应用的开发。目前比较流行的建模理论为Inmon提出的自下而上（EDW-DM）的范式建模理论和Kimball的从上而下的（DM-DW）的维度建模理论。逻辑模型建模的工作量占到数据建模的整体工作量的60%-70%，是最重要的一个环节。

范式建模

  • 第一范式：属性不可分割
  • 第二范式：存在主键，每行数据具备唯一性
  • 第三范式：不存在传递依赖

维度建模

  • 星型模型：由一一个事实表和一组维表组成，每个维表都有一个维度作为主键，事实表居中，多个维表呈辐射状分布于其四周，并与事实表连接，形成一个星型结构。
  • 雪花模型：在星型模型基础上，基于范式理论进一步层次化，将某些维表扩展成事实表，最终形成雪花状结构。
  • 星座模型：由多个事实表组合，维表是公共的，可以被多个事实表共享。

数据仓库大多数时候是比较适合使用维度建模的星型模型构建底层数据Hive表，通过大量的冗余来提升查询效率（反三范式），星型模型对OLAP的分析引擎支持比较友好，这一点在Kylin中比较能体现。

对比建筑设计图，逻辑模型阶段需要输出数据模型文件。

逻辑模型需要注意的问题：

  • 当实体数量超过100时，需要定义术语表
  • 规范化
  • 先规范化再逆规范化，不可一步到位
  • 不可缺少约束的定义
  • 使用CASE工具做逻辑模型
  • 需要同级评审（Peer Review）
  • 确定可信赖数据源，关键属性需用真实数据验证
  • 应用成熟的建模模式（Pattern）
  • 定程度的抽象化，决定了未来模型的弹性
  • 高质量的模型定义
  • 重要关联关系需要强制建立
  • 与概念模型保持一致
  • 注意模型的版本管理
  • 非常非常注意细节
  • 数据库专家深度介入
  • 占据整个数据建模80%以上时间
  • 不要忽视属性的长度定义和约束定义
  • 不要忽视属性的默认值（Default Value）
  • 使用控制数据范围的域（Domain）

逻辑模型交付品特点：

  • 要像一本书，而非一页纸
  • 所有实体属性均需添加
  • 实体间关系要清晰描述
  • 使用术语表
  • 遵循命名规范
  • 采用CASE工具创建项目文件
  • 对各个实体必须有清晰描述
  • 对关键属性必须有清晰描述

逻辑模型阶段一般由项目负责人或者架构师，与开发人员进行详细沟通，把业务需求明确细化的传达给开发人员，具体建模流程由架构师主导，开发人员具体实施，并输出细节文档。

物理模型

物理模型需要从性能、访问、开发等多方面考虑，做系统的实现设计。
根据逻辑模型设计的结构为基础，设计数据对象的物理实现，比如表的命名规范、字段的命名规范、字段类型选择、分区设置、存储设置，更行方式等等。

物理模型需要注意的问题：

  • 使用CASE工具由逻辑模型自动生成
  • 应用术语表自动转换生成字段名称
  • 对表空间、索引、视图、物化视图、主键、外键等都有命名规则逆规范化在逻辑层完成，而非本层
  • 数据库DBA深度介入，需要DBA的评审（Peer Review）
  • 和数据库的DDL保持一致
  • 注意版本管理
  • 注意开发、测试、生产三个不同版本的模型管理
  • 注意性能
  • 估算数据规模
  • 考虑数据归档
  • 充分考虑未来使用数据库的优点和缺点

物理建模交付品的特点

  • 自动生成基础库表结构，之后适度手动调整
  • 与未来要使用的数据库类型息息相关
  • 生成数据字典并发布
  • 可直接用于生成DDL
  • DDL中注意注释的生成

物理模型即开发人员的最终的输出，是整个建模过程中最后的落地实现。