一、概述
1.1 概念定义：
本质上是一个数据管理系统，
主要功能：
1）整合多源数据
2）提供分析接口
1.2 架构
涉及框架：
传输：DataX，MaxWell，Flume，Kafka
存储：Hadoop
分析：Hive
调度：DolphinScheduler
报表展示：Superset
二、 建模概述
2.1 意义
1）高性能：快速查询
2）低成本：减少重复计算
3）高效率：提高用户使用数据的效率
4）高质量：减少计算错误可能性
2.2 建模方法论
-
ER模型
实体关系(Entity Relationship, ER)，符合3NF
ER模型举例 1）实体关系模型
实体：对象
关系：两个实体之间的关系
出发点：整合数据，减少冗余2）数据库规范化
目的：减少数据冗余，增强数据一致性
六范式：1NF，2NF，3NF，BCNF，4NF，5NF3）三范式
①函数依赖
完全函数依赖 (X ==> Y) && (X' !==> Y)
部分函数依赖 (X ==> Y) && (X' ==> Y)
传递函数依赖 (X ==> Y) && (Y !==> X) && (Y ==> Z)
②第一范式 1NF
原则：属性不可切割（原子属性）
解释：每一个元素必须拆解至不能再拆解
③第二范式 2NF
原则：不能存在 部分函数依赖
解释：元素必须只能与主键一一对应，
④第三范式 3NF
原则：不能存在 传递函数依赖
解释：-
维度模型
事实：业务过程（不可拆分的行为事件）
维度：业务过程发生时所处的环境
优点：简洁，清晰
出发点：数据分析
维度模型举例
三、维度建模理论--事实表
3.1 事实表概述
- 数仓维度建模核心
- 围绕业务过程设计
- 包含：与业务过程有关的维度引用（维度表外键）以及业务过程的度量（数字类型字段）
- 事实表特点
列少，行多，行增长快速 - 事实表分类
事务事实表、周期快照事实表、累积快照事实表
3.2 事务型事实表
- 概述：保存各业务过程的原子操作事件，最细力度的操作事件
- 设计步骤：
1、选择业务过程：一个业务过程对应一个事务型事实表
2、声明粒度：为每个业务声明粒度（定义每行数据的具体含义，应尽可能最细）
3、确认维度：确认与本表相关的维度（环境信息，尽量丰富）
4、确认事实：确定业务的度量值 - 不足：存量型指标、多事务关联统计
3.3 周期性快照事务表
- 概述：以规律、可预见的时间间隔记录事实，用于分析存量型、状态型指标
- 设计步骤：
1、确定粒度：周期（通常选每日）、维度
2、确认事实：业务过程、指标 - 事实（度量值）类型
1、可加事实：可按照所有相关维度进行累加
2、半可加事实：只能按照一部分相关维度进行累加
3、不可加事实：没有可加性
3.4 累积型快照事实表
- 概述：一个业务流程中多个关键业务过程联合处理，一般具有多个日期字段，主要用于分析业务过程之间的时间间隔等需求
- 设计流程
1、选择业务过程：一个业务流程中的多个关键业务过程（里程碑），多个关键业务过程对应一个累计型快照事实表
2、声明粒度：定义每行数据的具体含义，应尽可能最细
3、确认维度：选择与每个业务过程相关的维度，至少需要一个日期维度
4、确认事实：各业务过程的度量值
四、维度建模理论--维度表
4.1 维度表概述
- 维度建模基础
- 围绕业务过程所处的环境设计
- 包含：一个主键，各种维度字段（维度属性）
4.2 维度表设计步骤
- 确定维度（表）
维度唯一性：若多个事实表与同一维度相关，应保证维度唯一性（只创建一张维度表）
维度退化：某维度表属性很少，此表可省略不创建，将该表的属性直接增加到相关的事实表中 - 确定主维表和相关维表
指业务系统中与某维度相关的表，分主次（一大类表中的“主键”===>主表） - 确定维度属性
1）尽量丰富：表内高维
2）尽量不编码：文字说明+编码
3）尽量沉淀出通用的维度属性：将获取复杂的维度属性沉淀到维度表中
4.3 维度设计
- 规范化、反规范化
规范化：范式设计，减少冗余，但表数量增加。（雪花模型❄）
反规范化：多表整合，减少join，提高查询性能（星型模型⭐）
两种模型的对比 - 维度变化
目的：反映历史变化
问题点：如何保存维度的历史状态
1）全量快照表：每天保存一次全量的维度数据。
优点：简单，有效。
缺点：浪费存储空间（FNNDP，硬盘能值几个钱？？）
2）拉链表：记录每条信息的生命周期
适用场景：数据会变化，但频率不高的维度（缓慢变化维）
使用方式：start<=某日期 && end >=某日期，即可获得某日期的具体数据全量切片 - 多值属性
某属性同时有多个值
1）多值属性放入同一字段：(key1,value1),(key2,value2)……
2）多值属性放入多个字段：只适用于个数固定的情况
五、数据仓库设计
5.1 数仓分层规划
ODS（Operation Data Store）原始数据层：同步（全量、增量）、结构化（非结构化转为结构化）、保存历史数据、清洗数据
CDM（Common Data Model）公共数据层：
数据加工与整合、建立一致性维度、汇总公共粒度的指标、构建明细事实表
包含以下三个层次
-1. DWD（Data Warehouse Detail）明细数据层：存放事实表，保存最小粒度的业务过程
-2. DIM（Dimension）公共维度层：存放维度表，建立一致性维度
-3. DWS（Data Warehouse Summary）汇总数据层：构建命名规范、口径一致的统计指标，建立汇总宽表-
ADS（Application Data Service）数据应用层：存放指标统计结果分层规划
-
数据流向：
如下图所示。ODS层和DWD层会放在数据中间件中，供下游订阅使用。而DWS层和ADS层的数据通常会落地到在线存储系统中，下游通过接口调用的形式使用。
数据流向 层次调用规范
ADS应用层优先调用数据仓库公共层数据。如果已经存在CDM层数据，不允许ADS应用层跨过CDM中间层从ODS层重复加工数据。CDM中间层应该积极了解应用层数据的建设需求，将公用的数据沉淀到公共层，为其他数据层次提供数据服务。同时，ADS应用层也需积极配合CDM中间层进行持续的数据公共建设的改造。避免出现过度的ODS层引用、不合理的数据复制和子集合冗余。总体遵循的层次调用原则如下：
1、ODS层数据不能直接被应用层任务引用。如果中间层没有沉淀的ODS层数据，则通过CDM层的视图访问。CDM层视图必须使用调度程序进行封装，保持视图的可维护性与可管理性。
CDM层任务的深度不宜过大（建议不超过10层）。
2、一个计算刷新任务只允许一个输出表，特殊情况除外。
3、如果多个任务刷新输出一个表（不同任务插入不同的分区），DataWorks上需要建立一个虚拟任务，依赖多个任务的刷新和输出。通常，下游应该依赖此虚拟任务。
4、CDM汇总层优先调用CDM明细层，可累加指标计算。CDM汇总层尽量优先调用已经产出的粗粒度汇总层，避免大量汇总层数据直接从海量的明细数据层中计算得出。
5、CDM明细层累计快照事实表优先调用CDM事务型事实表，保持数据的一致性产出。
6、有针对性地建设CDM公共汇总层，避免应用层过度引用和依赖CDM层明细数据。
5.2 数仓构建流程
数据调研
-1. 业务调研：
①熟悉业务流程：明确每个现实业务的具体流程，拆分为抽象的业务过程（不可拆分的行为事件）
②熟悉业务数据：将数据与业务过程对应起来，明确每个业务过程对哪些表的数据产生哪些影响（具体到对表、数据条目的操作逻辑）
-2. 需求分析：
明确需求所需的业务过程及维度
考虑三个问题，帮助分析
-业务数据是根据什么（维度、粒度）汇总的，衡量标准是什么？例如，成交量是维度，订单数是成交量的度量。
-明细数据层和汇总数据层应该如何设计？公共维度层该如何设计？是否有公共的指标？
-数据是否需要冗余或沉淀到汇总数据层中？划分数据域
数据域是指面向业务分析，将业务过程或者维度进行抽象的集合。
目的：便于数据的管理和应用
划分依据：业务过程（一个业务过程只能属于一个数据域）、部门构建业务总线矩阵
包含所有事实（业务过程）及维度，以及两者之间的关系。
矩阵的行是业务过程，列是维度。
一个业务过程对应一张事务型事实表，一个维度则对应一张维度表。明确统计指标
1、原子指标 = 业务过程 + 度量值 + 聚合逻辑
2、派生指标 = 原子指标 + 统计周期 + 业务限定（修饰词） + 统计粒度（groupBy）
3、衍生指标 = 在一个或多个派生指标的基础上计算而来
4、 指标体系意义：
大多数需求都之间或间接对应一个或多个派生指标，那么，当需求足够多时，必然出现部分统计需求对应的派生指标相同的情况。这种情况下，考虑将公共的派生指标保存下来，减少重复计算，提高数据的复用性。
公共的平派生指标统一保存在数仓的DWS层维度模型设计
构建业务总线矩阵的过程就是设计维度模型的过程。但是需要注意的是，总线矩阵中通常只包含事务型事实表，另外两种类型的事实表需单独设计。
事实表存储在DWD层
维度表存在DIM层汇总模型设计
汇总模型的设计参考上述整理出的指标体系（主要是派生指标）即可。
汇总表与派生指标的对应关系是：一张汇总表通常包含业务过程相同、统计周期相同、统计粒度相同的多个派生指标。
