数仓建模
一、概念
数据建模简单来说就是基于对业务的理解，将各种数据进行整合和关联，并最终使得这些数据可用性，可读性增强，让使用方能快速的获取到自己关心的有价值的信息并且及时的作出响应。
二、目的
大数据的数仓建模是通过建模的方法更好的组织、存储数据，以便在 性能、成本、效率和数据质量之间找到最佳平衡点。一般主要从下面四点考虑：
- 高性能：能够快速查询所需的数据，减少数据I/O
- 低成本：减少不必要的数据冗余和重复计算，实现计算结果数据复用，降低存储成本和计算成本。
- 高效率：改善用户应用体验，提高使用数据的效率。
- 高质量：改善数据统计口径的不一致性，减少数据计算错误的可能性，提供高质量的、一致的数据访问平台。
三、数据建模的几种方式
1.ER模型(范式建模)
- 1NF：属性不可再分割（例如不能存在5台电脑的属性，坏处：表都没法用）
- 2NF：不能存在部分函数依赖（例如主键（学号+课名）–>成绩，姓名，但学号–》姓名，所以姓名部分依赖于主键（学号+课名），所以要去除，坏处：数据冗余）
- 3NF：不能存在传递函数依赖（学号–》宿舍种类–》价钱，坏处：数据冗余和增删异常）
MySQL关系模型：关系模型主要应用与OLTP系统中，为了保证数据的一致性以及避免冗余，所以大部分业务系统的表都是遵循第三范式的。
Hive 维度模型：维度模型主要应用于OLAP系统中，因为关系模型虽然冗余少，
但是在大规模数据，跨表分析统计查询过程中，会造成多表关联，这会大大降低执行效率。
所以HIVE把相关各种表整理成两种：事实表和维度表两种。所有维度表围绕着事实表进行解释。
2.维度建模
维度建模的分类
维度建模按数据组织类型划分可分为星型模型、雪花模型、星座模型
星型模型（事实表+一级维度表），雪花（事实表+多级维度），星座模型（星型模型+多个事实表）
维度表
一般是对事实的描述信息。每一张维表对应现实世界中的一个对象或者概念。 例如：用户、商品、日期、地区等。
事实表
事实表作为数据仓库维度建模的核心，紧紧围绕着业务过程来设计。其包含与该业务过程有关的维度引用（维度表外键）以及该业务过程的度量（通常是可累加的数字类型字段）。
事实包含业务的度量，是定量的数据，如销售价格、销售数量、距离、速度、重量等是事实。
事实表分类：
- 事务型事实表: 事务事实表用来记录事务层面的事实（例如交易流水值、销售数量等），它保存的是各业务过程的原子操作事件，即最细粒度的操作事件。其数据在事务发生后发生，粒度为每一行数据。一旦数据写入成功，数据就不再进行更改，其更新方式为增量更新。
- 周期型快照事实表: 周期快照事实表以具有规律性的、可预见的时间间隔来记录事实，主要用于分析一些存量型（例如商品库存，账户余额）或者状态型（空气温度，行驶速度）指标。
- 累积型快照事实表: 累计快照事实表用于跟踪业务事实的变化。累计快照事实表是基于一个业务流程中的多个关键业务过程联合处理而构建的事实表，例如，数据仓库中可能需要累积或者存储订单从下订单开始，到订单商品被打包、运输、和签收的各个业务阶段的时间点数据来跟踪订单声明周期的进展情况。当这个业务过程进行时，事实表的记录也要不断更新。
事实类型：
此处的事实类型是指度量值的类型，而非事实表的类型。事实（度量值）共分为三类，分别是可加事实，半可加事实和不可加事实。
- 可加事实
可加事实是指可以按照与事实表相关的所有维度进行累加，例如事务型事实表中的事实。
- 半可加事实
半可加事实是指只能按照与事实表相关的一部分维度进行累加，例如周期型快照事实表中的事实。以上述各仓库中各商品的库存每天快照事实表为例，这张表中的库存事实可以按照仓库或者商品维度进行累加，但是不能按照时间维度进行累加，因为将每天的库存累加起来是没有任何意义的。
- 不可加事实
不可加事实是指完全不具备可加性，例如比率型事实。不可加事实通常需要转化为可加事实，例如比率可转化为分子和分母。
| 特点 | 事务型事实表 | 周期快照事实表 | 累积快照事实表 |
|---|---|---|---|
| 时间/时期 | 离散事务时间点 | 有规律、可预测的间隔产生快照 | 时间跨度不确定的不断变化的工作流 |
| 粒度 | 每行代表实体的一个事务 | 每行代表一个时间周期的某个实体 | 每行代表实体的一个业务周期 |
| 事实表加载 | 新增 | 新增 | 新增和修改 |
| 事实表更新 | 不更新 | 不更新 | 业务过程变更时更新 |
| 时间维 | 业务日期 | 时期末 | 相关业务过程事实和时间间隔事实 |
| 事实 | 事务事实 | 累计事实 | 限定多个业务阶段内的绩效 |
| 举例 | 交易流水 | 每个时间段的库存数据 | 交易流程中下单、支付、发货、确认收货业务过程 |
维度表和事实表的区别
- 事实表就是你要关注的内容。
- 维度表就是你观察该事务的角度，是从哪个角度去观察这个内容的。
例如，某地区商品的销量，是从地区这个角度观察商品销量的。事实表就是销量表(指标)，维度表就是地区表(维度)。
同步策略：
- 维度表，每日全量或者每月（更长时间）全量
- 事务型事实表：每日增量
- 周期性事实表：拉链表(或者全量表)
3.Data Vault模型
Data Vault Dan Linstedt 发起创建的一种模型，它是模型的衍生，其设计的出发点也是为了实现数据的整合，但不能直接用于数据分析决策。它强调建立一个可审计的基础数据层，也就是强调数据的历史性、可追溯性和原子性，而不要求对数据进行过度的一致性处理和整合；
同时它基于主题概念将企业数据进行结构化组织，并引入了更进一步的范式处理来优化模型，以应对源系统变更的扩展性。Data Vault 型由以下几部分组成。
• Hub ：是企业的核心业务实体，由 实体 key 、数据仓库序列代理键、装载时间、数据来源组成。
• Link ：代表 Hub 之间的关系。这里与 模型最大的区别是将关系作为一个独立的单元抽象，可以提升模型的扩展性。它可以直
接描述 1:1 1:n n:n 的关系，而不需要做任何变更。它由 Hub 的代理键、装载时间、数据来源组成。
• Satellite ：是 Hub 的详细描述内容， 一个 Hub 可以有多个 Satellite它由 Hub 的代理键、装载时间、来源类型、详细的 Hub 描述信息组成。
Data Vault 模型比 ER 模型更容易设计和产出，它的 ETL 加工可实现配置化。
4.Anchor模型
四、四种建模方法总结
以上为四种基本的建模方法，当前主流建模方法为： ER模型、维度模型
- ER模型常用于OLTP数据库建模，应用到构建数仓时更偏重数据整合， 站在企业整体考虑，将各个系统的数据按相似性一致性、合并处理，为 数据分析、决策服务，但并不便于直接用来支持分析。缺陷：需要全面梳理企业所有的业务和数据流，周期长，人员要求高。
- 维度建模是面向分析场景而生，针对分析场景构建数仓模型；重点关注快 速、灵活的解决分析需求，同时能够提供大规模数据的快速响应性能。针对性 强，主要应用于数据仓库构建和OLAP引擎低层数据模型。优点：不需要完整的梳理企业业务流程和数据，实施周期根据主题边界而定，容易快速实现demo
- 数仓模型的选择是灵活的，不局限于某一种模型方法
- 数仓模型的设计也是灵活的，以实际需求场景为导向
- 模型设计要兼顾灵活性、可扩展，而对终端用户透明性
- 模型设计要考虑技术可靠性和实现成本
五、模型分层
数据仓库一般分为三层，自上而下分别为数据贴源层（ODS，Operation Data Store）、数据公共层（CDM，Common Data Model）和数据应用层（ADS，Application Data Service）。
1. ods层
- 保持数据原貌不做任何修改，起到备份数据的作用。
- 数据采用压缩，减少磁盘存储空间（例如：原始数据100G，可以压缩到10G左右）
- 创建分区表，防止后续的全表扫描
2. cdm层
维度建模一般按照以下四个步骤： 选择业务过程→声明粒度→确认维度→确认事实
数据公共层CDM（Common Data Model，又称通用数据模型层），包括DIM维度表、DWD,DW和DWS，由ODS层数据加工而成。主要完成数据加工与整合，建立一致性的维度，构建可复用的面向分析和统计的明细事实表，以及汇总公共粒度的指标
- 公共维度层（DIM）：基于维度建模理念思想，建立企业一致性维度。降低数据计算口径和算法不统一风险。 公共维度层的表通常也被称为逻辑维度表，维度和维度逻 辑表通常一一对应。
- 明细粒度事实层（DWD）：对数据进行规范化编码转换，清洗，统一格式，脱敏等，不做横向整合
- 主题宽表层(DW) ：对dwd各种信息进行整合，输出主题宽表(面 向业务过 程，不同业务过程的信息不冗余建设，采用外键形式)
- 公共汇总粒度事实层（DWS）：以分析的主题对象作为建模驱动，基于上层的应用和产品的指标需求，构建公共粒度的汇总指标事实表，以宽表化手段物理化模型。构建命名规范、口径一致的统计指标，为上层提供公共指标，建立汇总宽表、明细事实表。
公共汇总粒度事实层的表通常也被称为汇总逻辑表，用于存放派生指标数据。
3. ads层
数据应用层ADS（Application Data Service）：面向业务需求定制开发，存放数据产品个性化的统计指标数据。
六、业务设计流程
选择业务过程→声明粒度→确认维度→确认事实。
六、分层的好处
- 清晰数据结构：每一个数据分层都有它的作用域，这样我们在使用表的时候能更方便地定位和理解。
- 数据血缘追踪：简单来讲可以这样理解，我们最终给业务呈现的是一张能直接使用的张业务表，但是它的来源有很多，如果有一张来源表出问题了，我们希望能够快速准确地定位到问题，并清楚它的危害范围。
- 减少重复开发：规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算。
- 把复杂问题简单化：将一个复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤，比较简单和容易理解。而且便于维护数据的准确性，当数据出现问题之后，可以不用修复所有的数据，只需要从有问题的步骤开始修复。
