Hive之数仓的分层及建模理论
一、数据仓库的用途
- 整合公司所有业务数据，建立统一的数据中心
- 产生业务报表，用于作出决策
- 为网站运营提供运营上的数据支持
- 可以作为各个业务的数据源，形成业务数据互相反馈的良性循环
- 分析用户行为数据，通过数据挖掘来降低投入成本，提高投入效果
- 开发数据产品，直接或间接地为公司盈利
二、数仓运行架构图
三、数据集市与数仓的区别
数据集市（Data Market）：是一种微型的数据仓库，它通常有更少的数据，更少的主题区域，以及更少的历史数据，因此是部门级的，一般只能为某个局部范围内的管理人员服务。
数据仓库（Data Warehouse）：数据仓库是企业级的，能为整个企业各个部门的运行提供决策支持手段。
四、数仓分层
1. 分层原因
- 把复杂问题简单化：将复杂的任务分解成多层来完成，每一层只处理简单任务，方便定位问题。
- 减少重复开发：规范数据分层，通过中间层数据，能够减少大量的重复计算，增加一次计算结果的复用性。
- 隔离原始数据：不论是数据的异常还是数据的敏感性，使真实数据与统计数据解耦开。
2. 基本分层模型
ODS（数据源层，原始数据） – ETL --> DWD（数据明细层） – hive sql --> DWS（数据汇总） – sqoop --> ADS（数据应用：报表、用户画像）
3. 数据仓库分层
3.1 数仓分层概述
在阿里巴巴的数据体系中，建议将数据仓库分为三层，自下而上为：
数据引入层ODS（Operation Data Store）：存放未经过处理的原始数据至数据仓库系统，结构上与源系统保持一致，是数据仓库的数据准备区。主要完成基础数据引入到MaxCompute的职责，同时记录基础数据的历史变化。
数据公共层CDM（Common Data Model，又称通用数据模型层）:包括DIM维度表、DWD和DWS，由ODS层数据加工而成。主要完成数据加工与整合，建立一致性的维度，构建可复用的面向分析和统计的明细事实表，以及汇总公共粒度的指标，根据目前业务特点，暂时只建立DWD层
- 明细粒度事实层（DWD）：以业务过程作为建模驱动，基于每个具体的业务过程特点，构建最细粒度的明细层事实表。可以结合企业的数据使用特点，将明细事实表的某些重要维度属性字段做适当冗余，即宽表化处理。
- 数据中间层：DWM（Data WareHouse Middle）该层会在DWD层的数据基础上，对数据做轻度的聚合操作，生成一系列的中间表，提升公共指标的复用性，减少重复加工。直观来讲，就是对通用的核心维度进行聚合操作，算出相应的统计指标。
- 公共汇总粒度事实层（DWS）：以分析的主题对象作为建模驱动，基于上层的应用和产品的指标需求，构建公共粒度的汇总指标事实表，以宽表化手段物理化模型。构建命名规范、口径一致的统计指标，为上层提供公共指标，建立汇总宽表、明细事实表。
- 公共维度层（DIM）：基于维度建模理念思想，建立整个企业的一致性维度。降低数据计算口径和算法不统一风险。公共维度层的表通常也被称为逻辑维度表，维度和维度逻辑表通常一一对应。
数据应用层ADS（Application Data Service）：存放数据产品个性化的统计指标数据。根据CDM与ODS层加工生成。
中英文及简写：
数据引入层（ODS，Operation Data Store）
数据公共层（CDM，Common Data Model）
公共维度层（DIM，Dimension）
数仓明细层（DWD，Data Warehouse Detail）
数据汇总层（DWS，Data Warehouse Service）
数据应用层（ADS，Application Data Service）。
3.2 各层级用途
1) 数据引入层（ODS，Operation Data Store）：将原始数据几乎无处理的存放在数据仓库系统，结构上与源系统基本保持一致，是数据仓库的数据准备区。原始数据，主要是埋点数据（日志数据）和业务操作数据（binlong），数据源主要是 Mysql、HDFS、Kafka 等
2) 数据公共层（CDM，Common Data Model，又称通用数据模型层），包括 DIM 维度表、DWD 和 DWS，由ODS 层数据加工而成。主要完成数据加工与整合，建立一致性的维度，构建可复用的面向分析和统计的明细事实表，以及汇总公共粒度的指标。这一层里又包括三层：
- 公共维度层（DIM）：
- 基于维度建模理念思想，建立整个企业的一致性维度。降低数据计算口径和算法不统一风险。公共维度层的表通常也被称为逻辑维度表，维度和维度逻辑表通常一一对应。
- 主要使用 MySQL、Hbase、Redis 三种存储引擎，对于维表数据比较少的情况可以使用 MySQL，对于单条数据大小比较小，查询 QPS 比较高的情况，可以使用 Redis 存储，降低机器内存资源占用，对于数据量比较大，对维表数据变化不是特别敏感的场景，可以使用 HBase 存储。
- 数仓明细层（DWD）：
- ODS 层经过清洗，落地这一层，一般是最细粒度。
- 以业务过程作为建模驱动，**基于每个具体的业务过程特点，构建最细粒度的明细层事实表。**可以结合企业的数据使用特点，将明细事实表的某些重要维度属性字段做适当冗余，即宽表化处理。
- 数据汇总层（DWS）：
- 对 DWD 层的轻微聚合，对一些可累加的指标进行聚合，增加复用性。
- 以分析的主题对象作为建模驱动，基于上层的应用和产品的指标需求，构建公共粒度的汇总指标事实表，以宽表化手段物理化模型。构建命名规范、口径一致的统计指标，为上层提供公共指标，建立汇总宽表、明细事实表。公共汇总粒度事实层的表通常也被称为汇总逻辑表，用于存放派生指标数据。
3) 数据应用层（ADS，Application Data Service）：存放数据产品个性化的统计指标数据。根据 CDM 与 ODS 层加工生成。
4. 开发规范
4.1 命名规则
1) ods 层
增量数据： {project_name}.ods_{数据来源}_{源系统表名}_delta
全量数据： {project_name}.ods_{数据来源}_{源系统表名}
数据来源说明：
01 -> hdfs 数据
02 -> mysql 数据
03 -> redis 数据
04 -> mongodb 数据
05 -> tidb 数据
举例如下：
行为日志表： ods_01_action_log
用户表： ods_02_user
2) dim 层
公共区域维表： {project_name}.dim_pub_{自定义命名标签}
具体业务维表： {project_name}.dim_{业务缩写}_{自定义命名标签}
举例如下：
公共区域维表： dim_pub_area
公共时间维表： dim_pub_date
A公司电商板块的商品全量表： dim_asale_itm
3) dwd 层
多个业务公共表： {project_name}.dwd_pub_{自定义命名标签}
具体业务数据增量表： {project_name}.dwd_{业务缩写}_{自定义命名标签}_di
具体业务数据全量表： {project_name}.dwd_{业务缩写}_{自定义命名标签}_df
举例如下：
交易会员信息事实表：ods_asale_trd_mbr_di
交易商品信息事实表：dwd_asale_trd_itm_di
交易订单信息事实表：dwd_asale_trd_ord_di
4) dws 层
多个业务公共表： {project_name}.dws_pub_{自定义命名标签}
具体业务最近一天汇总事实表： {project_name}.dws_{业务缩写}_{自定义命名标签}_1d
具体业务最近N天汇总事实表： {project_name}.dws_{业务缩写}_{自定义命名标签}_nd
具体业务历史截至当天汇总表： {project_name}.dws_{业务缩写}_{自定义命名标签}_td
具体业务小时汇总表： {project_name}.dws_{业务缩写}_{自定义命名标签}_hh
举例如下：
dws_asale_trd_byr_subpay_1d（A电商公司买家粒度交易分阶段付款一日汇总事实表）
dws_asale_trd_byr_subpay_td（A电商公司买家粒度分阶段付款截至当日汇总表）
dws_asale_trd_byr_cod_nd（A电商公司买家粒度货到付款交易汇总事实表）
dws_asale_itm_slr_td（A电商公司卖家粒度商品截至当日存量汇总表）
dws_asale_itm_slr_hh（A电商公司卖家粒度商品小时汇总表）---维度为小时
dws_asale_itm_slr_mm（A电商公司卖家粒度商品分钟汇总表）---维度为分钟
5) ads 层
{project_name}.ads_{业务缩写}_{自定义命名标签}
举例如下：
订单统计表： ads_nshop_order_form
订单支付统计： ads_nshop_orderpay_form
4.2 数据来源介绍
1) 业务数据
业务数据往往产生于事务型过程处理，所以一般存储在关系型数据库中，如 mysql、oracle。
业务数据源： 用户基本信息、商品分类信息、商品信息、店铺信息、订单数据、订单支付信息、活动信息、物流信息等
2) 埋点日志
埋点日志相对业务数据是用于数据分析、挖掘需求，一般以日志形式存储于日志文件中，随后通过采集落地分布式存储介质中如 hdfs、hbase。
用户行为日志： 用户浏览、用户点评、用户关注、用户搜索、用户投诉、用户咨询
3) 外部数据
当前一般公司都会通过线上广告来进行获客，与三方公司合作更多的提取相关数据来进行深度刻画用户及用户群体，另外爬取公共公开数据也是分析运营的常用方式。
外部数据源： 广告投放数据、爬虫数据、三方接口数据
5. 分层的误区
数仓层内部的划分不是为了分层而分层，分层是为了解决 ETL 任务及工作流的组织、数据的流向、读写权限的控制、不同需求的满足等各类问题。
业界较为通行的做法将整个数仓层（DW）又划分成了 dwd、dwb、dws、dim、mid 等等很多层。然而我们却始终说不清楚这几层之间清晰的界限是什么，或者说我们能说清楚它们之间的界限，复杂的业务场景却令我们无法真正落地执行。
所以数据分层这块一般来说 ODS、DWD、DWS 这三层是最基础的：
至于DW层如何进行切分，是根据具体的业务需求和公司场景自己去定义，一般来说需要：
- 分层是解决数据流向和快速支撑业务的目的；
- 必须按照主题域和业务域进行贯穿；
- 层级之间不可逆向依赖。
- 如果依赖ODS层数据可以完成数据支撑，那么业务方直接使用落地层这也有利于快速、低成本地进行一些数据方面的探索和尝试。
- 确定分层规范后，后续最好都遵循这个架构，约定成俗即可；
- 血缘关系、数据依赖、数据字典、数据命名规范等配套先行；
DW 内的分层没有最正确的，只有最适合你的。
6. 宽表的误区
在数仓层开始引入了宽表。所谓宽表，迄今为止并没有一个明确的定义。通常做法是把很多的维度、事实上卷（roll-up）或者下钻（drill-down）之后关联到某一个事实表中，形成一张既包含了大量维度又包含了相关事实的表。
宽表的使用，有其一定的便利性。使用方不需要再去考虑跟维度表的关联，也不需要了解维度表和事实表是什么东西。
但是随着业务的增长，我们始终无法预见性地设计和定义宽表究竟该冗余多少维度，也无法清晰地定义出宽表冗余维度的底线在哪里。
一个可能存在的情况是，为了满足使用上的需求，要不断地将维表中已经存在的列增加到宽表中。这直接导致了宽表的表结构频繁发生变动。
目前我们所采用的做法是：
- 根据主题域和业务域，将某个业务的所有节点梳理清楚；
- 将关键节点的数据作为事实表依据，然后横向扩充其他事实表上卷数据（包含一些统计指标），同时纵向的添加该节点上一些主键对应的维度；
- 宽表的涉及不依赖具体的业务需求而是根据整体业务线相匹配；
- 尽量用维度建模代替宽表；
为什么说尽量用维度建模代替宽表，就算字段和数据会冗余，维度建模的方式也会表全量数据的宽表模式较好，原因：
- 维度建模是以某一个既定的事实为依据，既然是事实表，那么这块的业务如果不变动的情况下，事实表的粒度基本不会改变；
- 事实表和维度表解耦，维度表的变更事实表基本不会影响，结果表也只需要回刷一下数据流程即可；
- 新增维度完全可以按照星型模型或者雪花模型动态添加新维度；
- 维度模型可以作为宽表的基础，一旦确定全部的数据流程，可以通过维度模型再生成对应宽表进行快速的业务支撑；
五、数仓建模
1.范式理论
1.1 范式概念
1）定义
范式可以理解为设计一张数据表的表结构，符合的标准级别、规范和要求。
2）优点
采用范式，可以降低数据的冗余性。
为什么要降低数据冗余性？
（1）十几年前，磁盘很贵，为了减少磁盘存储。
（2）以前没有分布式系统，都是单机，只能增加磁盘，磁盘个数也是有限的
（3）一次修改，需要修改多个表，很难保证数据一致性
3）缺点
范式的缺点是获取数据时，需要通过Join拼接出最后的数据。
4）分类
目前业界范式有：第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)、第五范式(5NF)。
1.2 函数依赖
1、完全函数依赖
设X、Y是关系R的两个属性集合，X'是X的真子集，存在X→Y，但对于每一个X'都有X'!→Y，则称Y完全函数依赖于X。
比如通过，（学号，课程）推出分数，那么就可以说：分数完全依赖于（学号，课程）。
即：通过AB能得出C,但是AB单独得不出C,那么说C完全依赖于AB。
2、部分函数依赖
假如Y函数依赖于X，但同时Y并不完全函数依赖于X，那么我们就称Y部分函数依赖于X。
比如通过（学号，课程）推出姓名，因为直接可以通过学号推出姓名。所以姓名部分依赖于（学号，课程）
即：通过AB能得出C,通过A也能得出C，或者通过B也能得出C，那么说C部分依赖于AB。
3、传递函数依赖
设X、Y、Z是关系R中互不相同的属性集合，存在X→Y（Y'!→X），Y→Z，则称Z传递函数依赖于X。
学号推出系名，系名推出系主任，但是系主任推不出学号，系主任主要依赖于系名。这种情况可以说系主任传递依赖于学号。
即：通过A得到B，通过B得到C，但是C得不到A，那么说C传递依赖于A。
1.3 三范式区分
第一范式
1NF核心原则：属性不可切割
很明显上图所示的表格设计是不符合第一范式的，商品列中的数据不是原子数据项，是可以进行分割的，于是对表格进行修改，让表格符合第一范式的要求，如下图所示：
事实上，1NF是所有关系型数据库的最基本要求，只要在RDBMS中已经存在的数据表，一定是符合1NF的。
第二范式
2NF核心原则：不能存在部分函数依赖
以上表格明显存在部分依赖。比如，这张表的主键是（学号，课名），分数确实完全依赖于（学号，课名），但是姓名并不完全依赖于（学号，课名）。
上图右面表格符合第二范式，去掉了部分函数依赖。
第三范式
3NF核心原则：不能存在传递函数依赖
在下图所示表格中，存在传递函数依赖：学号->系名->系主任，但是系主任推不出学号。
上面表需要再次拆解：
2. 关系建模与维度建模
当今的数据处理大致可以分成两大类：联机事务处理OLTP（on-line transaction processing）、联机分析处理OLAP（On-Line Analytical Processing）。OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。二者的主要区别对比如下表所示。
| 对比属性 |
OLTP |
OLAP |
| 读特性 |
每次查询只返回少量记录 |
对大量记录进行汇总 |
| 写特性 |
随机、低延时写入用户的输入 |
批量导入 |
| 使用场景 |
用户，Java EE项目 |
内部分析师，为决策提供支持 |
| 数据表征 |
最新数据状态 |
随时间变化的历史状态 |
| 数据规模 |
GB |
TB到PB |
2.1 关系建模
关系模型如图所示，严格遵循第三范式（3NF），从图中可以看出，较为松散、零碎，物理表数量多，而数据冗余程度低。由于数据分布于众多的表中，这些数据可以更为灵活地被应用，功能性较强。关系模型主要应用与OLTP系统中，为了保证数据的一致性以及避免冗余，所以大部分业务系统的表都是遵循第三范式的。
2.2 维度建模
维度模型如图所示，主要应用于OLAP系统中，通常以某一个事实表为中心进行表的组织，主要面向业务，特征是可能存在数据的冗余，但是能方便的得到数据。
关系模型虽然冗余少，但是在大规模数据，跨表分析统计查询过程中，会造成多表关联，这会大大降低执行效率。所以通常我们采用维度模型建模，把相关各种表整理成两种：事实表和维度表两种。
3. 维度表和事实表
3.1 维度表
维度表：一般是对事实的描述信息。每一张维表对应现实世界中的一个对象或者概念。例如：用户、商品、日期、地区等。
在维度表中，每个表都包含独立于其他维度表的事实特性，例如，客户维度表包含有关客户的数据。维度表中的列字段可以将信息分为不同层次的结构级。
维表的特征：
- 维表的范围很宽（具有多个属性、列比较多）
- 跟事实表相比，行数相对较小：通常< 10万条
- 内容相对固定：编码表
时间维度表：
| 日期ID |
day of week |
day of year |
季度 |
节假日 |
| 2020-01-01 |
2 |
1 |
1 |
元旦 |
| 2020-01-02 |
3 |
2 |
1 |
无 |
| 2020-01-03 |
4 |
3 |
1 |
无 |
| 2020-01-04 |
5 |
4 |
1 |
无 |
| 2020-01-05 |
6 |
5 |
1 |
无 |
3.2 事实表
事实表：每个数据仓库都包含一个或者多个事实数据表。事实数据表可能包含业务销售数据，如现金登记事务所产生的数据，事实数据表通常包含大量的行。事实数据表的主要特点是包含数字数据（事实），并且这些数字信息可以汇总，以提供有关单位作为历史的数据，每个事实数据表包含一个由多个部分组成的索引，该索引包含作为外键的相关性纬度表的主键，而维度表包含事实记录的特性。事实数据表不应该包含描述性的信息，也不应该包含除数字度量字段及使事实与纬度表中对应项的相关索引字段之外的任何数据。
包含在事实数据表中的“度量值”有两中：一种是可以累计的度量值，另一种是非累计的度量值。最有用的度量值是可累计的度量值，其累计起来的数字是非常有意义的。用户可以通过累计度量值获得汇总信息，例如。可以汇总具体时间段内一组商店的特定商品的销售情况。非累计的度量值也可以用于事实数据表，单汇总结果一般是没有意义的，例如，在一座大厦的不同位置测量温度时，如果将大厦中所有不同位置的温度累加是没有意义的，但是求平均值是有意义的。
一般来说，一个事实数据表都要和一个或多个纬度表相关联，用户在利用事实数据表创建多维数据集时，可以使用一个或多个维度表。
事实表中的每行数据代表一个业务事件（下单、支付、退款、评价等）。“事实”这个术语表示的是业务事件的度量值（可统计次数、个数、金额等），例如，2020年5月21日，宋老师在京东花了250块钱买了一双安踏鞋。维度表：时间、用户、商品、商家。事实表：250块钱、一双
每一个事实表的行包括：具有可加性的数值型的度量值、与维表相连接的外键，通常具有两个和两个以上的外键。
事实表的特征：
- 非常的大
- 内容相对的窄：列数较少（主要是外键id和度量值）
- 经常发生变化，每天会新增加很多。
1）事务型事实表
以每个事务或事件为单位，例如一个销售订单记录，一笔支付记录等，作为事实表里的一行数据。一旦事务被提交，事实表数据被插入，数据就不再进行更改，其更新方式为增量更新。
2）周期型快照事实表
周期型快照事实表中不会保留所有数据，只保留固定时间间隔的数据，例如每天或者每月的销售额，或每月的账户余额等。
例如购物车，有加减商品，随时都有可能变化，但是我们更关心每天结束时这里面有多少商品，方便我们后期统计分析。
3）累积型快照事实表
累计快照事实表用于跟踪业务事实的变化。例如，数据仓库中可能需要累积或者存储订单从下订单开始，到订单商品被打包、运输、和签收的各个业务阶段的时间点数据来跟踪订单声明周期的进展情况。当这个业务过程进行时，事实表的记录也要不断更新。
| 订单id |
用户id |
下单时间 |
打包时间 |
发货时间 |
签收时间 |
订单金额 |
| 3-8 |
3-8 |
3-9 |
3-10 |
4. 维度模型分类
在维度建模的基础上又分为三种模型：星型模型、雪花模型、星座模型。
4.1 星型模型
星型模型和雪花模型的主要区别在于维度的层级，标准的星型模型维度只有一层，而雪花模型会涉及多级。
4.2 雪花模型
雪花模型，比较靠近3NF，但是无法完全遵守，因为遵循3NF的性能成本太高。
4.3 星座模型
星座模型与前两种的区别是事实表的数量，星座模型是基于多个事实表。
基本上是很多数据仓库的常态，因为很多数据仓库都是多个事实表的，所以星座不星座只反映是否有多个事实表，他们之间是否共享一些维度表。所以星座模型并不和前两种冲突。
4.4 模型的选择
首先就是星座不星座这个只跟数据和需求有关系，跟设计没关系，不用选择。
星型还是雪花，取决于性能优化，还是灵活更优先。
目前实际企业开发中，不会绝对选择一种，根据情况灵活组合，甚至并存（一层维度和多层维度都保存）。但是整体来看，更倾向于维度更少的星型模型。尤其是Hadoop体系，减少Join就是减少Shuffle，性能差距很大。（关系型数据可以依靠强大的主键索引）