1 数据仓库概述
1.1 数据仓库概念
● 数据仓库：一个为数据分析而设计的企业级数据管理系统。
● 可集中、整合多个信息源的大量数据。
1.2 数据仓库核心架构
2 数据仓库建模概述
2.1 数据仓库建模的意义
● 生活引入：如果把数据看作图书馆的数，我们希望看到他们在书架上分门别类地放置。
● 数据模型就是数据组织和存储方法，它强调从业务、数据存储和使用角度合理存储数据。
● 优点：高性能、低成本、高效率、高质量
2.2 数据仓库建模方法论
| 关系建模 | 维度建模 |
侧重点 | 写的强一致性和消除冗余存储 | 方便基于业务查询 |
特征 | 强调数据的治理（惊喜） | 将业务数据分为事实表和维度表 |
强调数据的整合 | 基于事实表将所有的维度表降维后直接关联在事实表上 | |
保证消除数据的冗余和保证数据强一致性 | | |
弊端 | 查询全部信息，需要进行多次关联 | 范式遵循上不严格 |
场景 | RDMS | 大数据分析 |
2.2.1 ER模型
● 实体关系（Entiy Relationship）模型将复杂的数据抽象为两个概念——实体和关系
● 实体：表示一个对象
● 关系：实体之间的关系
2.2.2 维度模型
● 维度模型：将复杂的业务通过事实和维度两个概念进行呈现。
● 事实 — 通常对应业务过程
● 维度 — 通常对应业务过程所处的环境
3 维度建模理论之事实表
3.1 事实表概述
● 数据仓库维度建模的核心：事实表
● 特点：“细长”— 列少，行多，行增速快。（如：订单表，来一个订单就得加一行）
● 分类：事务事实表、周期快照事实表、积累快照事实表。
3.2 事务型事实表
3.2.1 概述
● 事务型事实表：将一个业务流程中的事实环节拆分出来，且以最细粒度记录每个事实环节。
3.2.2 设计流程
● 四个步骤：选择业务过程 —> 声明粒度 —> 确认维度 —> 确认事实
3.2.3 不适用场景
① 存量型指标
② 多事务关联统计
3.3 周期型快照事实表
3.3.1 概述
● 周期型快照事实表：以具有规律性的、可预见的时间间隔来记录事实，主要用于计算存量型指标（商品库存、账户余额）或状态行指标（空气温度，形式速度）。
3.3.2 设计流程
① 确定粒度：确定周期时间和维度
② 确认事实：确定事务描述和度量
3.3.3 事实类型
● 此处的事实类型是指度量值的类型，而非事实表的类型。
● 事实（度量值）分为三类：可加事实、半可加事实、不可加事实。
3.4 累积型快照事实表
3.4.1 概述
● 累积型快照事实表：主要用于统计一个业务体系中，多个事实环节的时间间隔类型的指标。
【举例】在青少年发育的关键时间点记录一个人身高生长的事实。
NAME | 3岁 | 11岁 | 17岁 | 22岁 | 25岁 | 30岁 |
jack | 40 | 70 | 170 | NULL | NULL | NULL |
tom | 50 | 70 | 171 | NULL | NULL | NULL |
查询java的身高变化情况：select * from xx where name="jack"
将一个事实的状态进行积累，并且可以方便地查看状态的变化趋势，这类表为积累型快照实时表。
3.4.2 设计流程
● 四个步骤：选择业务过程 —> 声明粒度 —> 确认维度 —> 确认事实
4 维度建模理论之维度表
4.1 维度表概述
● 围绕业务过程所处的环境进行设计。
● 主要包含一个主键和各种维度字段，维度字段称为的维度属性。
4.2 维度表设计步骤
① 确定维度
例如：订单表+退单表 ——> 收货地址（维度表）
维度退化：
● 如果某些维度表的维度属性很少，例如只有一个名称，则可不创建该维度表，而把该表的维度属性直接增加到与之相关的事实表中。
例如：对性别维度，只有男，女
② 确定主维度表和辅助维度表
● 维度表的粒度通常与主维表相同
③ 确定维度属性
● 尽可能生成丰富的维度属性
● 尽量不使用编码，而使用明确的文字说明，一般可以编码和文字共存
● 尽量沉淀出通用的维度属性
4.3 维度设计要点
4.3.1 维度建模常见模型
● 星型模型（反规范化）：
直接关联在事实表上，当查询某个维度时，最多只需要关联一次。维度建模中使用的最多的模型。
● 雪花模型（规范化）：
间接关联在事实表上。当查询某个维度时，可能需要关联多次，大数据查询场景中效率低。
4.3.2 如何处理维度的变化
全量快照表
● 每周期（天）保存一份全量的维度数据
● 优点：简单有效，开发和维护成本低，方便理解和使用。
● 缺点：浪费存储空间，尤其是当数据的变化频率比较低时。
拉链表
● 拉取（查询），链（数据的一种形态，链条状）
● 用于监控缓慢变化（update）的维度的变化记录
● 拉链表的制作核心是为每天导入的数据，生成start_date和end_date
4.3.3 多值维度
● 多值维度：事实表中有一条记录在某个维度表中有多条记录与之对应。
● 例如：下单事实表中，一条记录为一个订单，一个订单包含多个商品。
解决方法： （粒度下降）
4.3.4 多值属性
● 多值属性：维表中的某个属性同时有多个值。
5 数据仓库设计
5.1 数据仓库分层规划
● 合理的分层，能够使数据体系更加清晰，使复杂问题简单化、减少重复开发、脱敏，隔离原始数。
分层介绍
分层 | 名称 | 特征 |
ODS (original 原始) | 原始数据层 | 采集的数据不做处理，直接导入 |
DWD （detail明细） | 明细数据层 | 将ODS层的事实表经过ETL（去脏，除NULL），脱敏后将明细展开 |
DIM （dimension 维度） | 维度数据层 | 将ODS层的维度表进行分类，降维（维度表数量下降） |
DWS （summary 服务） | 概要数据层 | 按ADS层的要求对事实进行概况（聚合）汇总 |
ADS （application 应用） | 应用数据层 | 为APP提供所需的数据 |
数仓的思想
5.2 数据仓库构建流程
● 构建数据仓库的完整流程图
5.2.1 数据调研
① 业务调研 —— 主要目标：熟悉业务流程、熟悉业务数据
② 需求分析 —— 明确所需的业务过程及维度
③ 总结 —— 保证每个需求都能找到与之对应的业务过程及维度
5.2.2 明确数据域
● 意义：便于数据的管理和应用
数据域 | 业务过程 |
交易域 | 加购、下单、取消订单、支付成功、退单、退款成功 |
流量域 | 页面浏览、启动应用、动作、曝光、错误 |
用户域 | 注册、登录 |
互动域 | 收藏、评价 |
工具域 | 优惠券领取、优惠券使用（下单）、优惠券使用（支付） |
5.2.3 构建业务总线矩阵
业务总线矩阵 —— 包含所有事实(业务过程)、维度，各业务过程与各维度的关系。
● 行 —— 一个个业务过程
● 列 —— 一个个的维度
● 行与列的交点 —— 业务过程与维度的关系
● 后续的DWD层和DIM层的搭建需参考业务总线矩阵
5.2.4 明确统计指标
● 明确统计指标：深入分析需求、构建指标体系（意义：指标定义标准化，避免指标歧义和重复定义）。
指标体系相关概念
(1) 原子指标
● 定义：某一业务过程中不可再拆解的度量值指标
● 三要素：业务过程、度量值、聚合逻辑
(2) 派生指标
● 派生指标基于原子指标，其与原子指标的关系如下图所示。
(3) 衍生指标
● 衍生指标是在一个或多个派生指标的基础上，通过各种逻辑运算复合而成的。例如比率、比例等类型的指标。衍生指标也会对应实际的统计需求。
指标体系对于数仓建模的意义
● 指标定义标准化：统计需求，都可以使用原子指标、派生指标以及衍生指标这套标准去定义。
● 避免重复定义：多个需求对应的相同的派生指标，称为公共指标，这部分指标可以保存在DWS层。
5.2.4 维度模型设计
● 事实表存储在DWD层
● 维度表存储在DIM层
5.2.5 汇总模型设计
● 汇总模型的设计参考上述整理出的指标体系（主要是派生指标）即可。
● 汇总表与派生指标的对应关系是，一张汇总表通常包含业务过程相同、统计周期相同、统计粒度相同的多个派生指标。
6 数仓环境准备
6.1 数据仓库运行环境
6.1.1 Hive引擎简介
6.1.2 Yarn环境配置
6.2 数据仓库开发环境
6.3 模拟数据准备
7 数仓开发之ODS层
8 数仓开发之DIM层
8.1 DIM层设计要点
要点 | 说明 |
设计依据 | 维度建模理论 （DIM层存储维度模型的维度表） |
存储格式 | orc列式存储 + snappy压缩 |
命名规范 | dim_表名_全量表 或 拉链表标识（full/zip） |
8.2 DIM层导数思路
① 从ODS层根据维度主题找到和当前主题相关的所有维度表
② 从DIM层维度表中区分主维度表和相关维度表
方法：根据DIM层维度表的粒度或名称或id(Mysql中的主键)区分
③ 确定DIM表中的字段来源,并以子查询的方式从对应表中查询所需要的字段
④ 使用主维度表 left join
8.3 复杂类型的构造和使用
【案例1】array
【案例2】struct
【案例3】named_struct
【案例3】map
【案例】
▶和判断相关的函数
【案例1】if
【案例2】nvl
【案例3】coalesce
【案例4】case...when...then...else...end
