数据仓库（三）——数仓理论

第一章 数仓分层

1.1 为什么要分层

仓库分层

ODS层：原始数据层，存放原始数据，直接加载原始日志、数据，数据保持原貌不做处理

DWD层：对ODS层数据进行清洗（去除空值，脏数据，超过极限范围的数据）、维度退化、脱敏等。保存业务事实明细，一行信息代表一次业务行为，例如一次下单。

DIM层：维度层，保存维度数据，主要是对业务事实的描述信息，例如何人，何时，何地等。

DWS层：以DWD为基础，按天进行轻度汇总。一行信息代表一个主题对象一天的汇总行为，例如一个用户一天下单次数

DWT：以DWS为基础，按主题对数据进行累积汇总。一行信息代表一个主题对象的累积行为，例如一个用户从注册那天开始至今一共下了多少次单

ADS层：数据应用层，面向实际的数据需求，为各种统计报表提供数据。

为什么要分层？

1）把复杂问题简单化。将复杂的任务分解成多层来完成，每一层只处理简单的任务，方便定位问题。

2）减少重复开发。规范数据分层，通过的中间层数据，能够减少极大的重复计算，增加一次计算结果的复用性。

3）隔离原始数据。不论是数据的异常还是数据的敏感性，使真实数据与统计数据解耦开。

1.2 数据集市与数据仓库概念

数据集市（Data Market），现在市面上的公司和书籍都对数据集市有不同的概念。

数据集市则是一种微型的数据仓库，它通常有更少的数据，更少的主题区域，以及更少的历史数据，因此是部门级的，一般只能为某个局部范围内的管理人员服务。

数据仓库是企业级的，能为整个企业各个部门的运行提供决策支持手段。

1.3 数仓命名规范

1.3.1 表命名

• ODS层命名为ods_表名
• DIM层命名为dim_表名
• DWD层命名为dwd_表名
• DWS层命名为dws_表名
• DWT层命名为dwt_表名
• ADS层命名为ads_表名
• 临时表命名为tmp_表名

1.3.2 脚本命名

数据源_to_目标_db/log.sh

用户行为脚本以log为后缀；业务数据脚本以db为后缀。

1.3.3 表字段类型

• 数量类型为bigint
• 金额类型为decimal(16, 2)，表示：16位有效数字，其中小数部分2位
• 字符串(名字，描述信息等)类型为string
• 主键外键类型为string
• 时间戳类型为bigint

第二章 数仓理论

2.1 范式理论

2.1.1 范式概念

1）定义

数据建模必须遵循一定的规则，在关系建模中，这种规则就是范式。

2）目的

采用范式，可以降低数据的冗余性。

为什么要降低数据冗余性？

（1）十几年前，磁盘很贵，为了减少磁盘存储。

（2）以前没有分布式系统，都是单机，只能增加磁盘，磁盘个数也是有限的

（3）一次修改，需要修改多个表，很难保证数据一致性

3）缺点
范式的缺点是获取数据时，需要通过Join拼接出最后的数据。
4）分类

目前业界范式有：第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)、第五范式(5NF)。

2.1.2 函数依赖

2.1.3 三范式区分

第一范式

第二范式

第三范式

2.2 关系建模与维度建模

关系建模和维度建模是两种数据仓库的建模技术。

2.2.1 关系建模

关系建模由Bill Inmon所倡导，维度建模由Ralph Kimball所倡导。

关系建模将复杂的数据抽象为两个概念——实体和关系，并使用规范化的方式表示出来。关系模型如图所示，从图中可以看出，较为松散、零碎，物理表数量多。

关系模型严格遵循第三范式（3NF），数据冗余程度低，数据的一致性容易得到保证。关系模型主要应用与OLTP中。由于数据分布于众多的表中，查询会相对复杂，在大数据的场景下，查询效率相对较低。

2.2.2 维度建模

维度模型如图所示，从图中可以看出，模型相对清晰、简洁。

维度模型示意图

维度模型主要应用与OLAP中，通常以某一张事实表为中心进行表的组织，主要面向业务，以数据分析作为出发点，不遵循三范式，故数据存在一定的冗余。维度模型面向业务，将业务用事实表和维度表呈现出来。表结构简单，故查询简单，查询效率较高。

2.3 维度表和事实表（重点）

关系模型虽然数据冗余程度低，但在大规模数据中进行跨表分析、统计、查询时，会造成多表关联，这会大大降低执行效率。所有我们通常采用纬度模型建模，把各种相关表整理成事实表和维度表两种。所有维度表围绕事实表进行解释。

2.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	无

2.3.2 事实表

事实表中的每行数据代表一个业务事件（下单、支付、退款、评价等）。“事实”这个术语表示的是业务事件的度量值（可统计次数、个数、金额等），例如，2020年5月21日，宋宋老师在京东花了250块钱买了一瓶海狗人参丸。维度表：时间、用户、商品、商家。事实表：250块钱、一瓶

每一个事实表的行包括：具有可加性的数值型的度量值、与维表相连接的外键，通常具有两个和两个以上的外键。

事实表的特征：

• 非常的大
• 内容相对的窄：列数较少（主要是外键id和度量值）
• 经常发生变化，每天会新增加很多。

1）事务型事实表

以每个事务或事件为单位，例如一个销售订单记录，一笔支付记录等，作为事实表里的一行数据。一旦事务被提交，事实表数据被插入，数据就不再进行更改，其更新方式为增量更新。

2）周期型快照事实表

周期型快照事实表中不会保留所有数据，只保留固定时间间隔的数据，例如每天或者每月的销售额，或每月的账户余额等。

例如购物车，有加减商品，随时都有可能变化，但是我们更关心每天结束时这里面有多少商品，方便我们后期统计分析。

3）累积型快照事实表

累计快照事实表用于跟踪业务事实的变化。例如，数据仓库中可能需要累积或者存储订单从下订单开始，到订单商品被打包、运输、和签收的各个业务阶段的时间点数据来跟踪订单声明周期的进展情况。当这个业务过程进行时，事实表的记录也要不断更新。

订单****id	用户id	下单时间	打包时间	发货时间	签收时间	订单金额
		3-8	3-8	3-9	3-10

2.4 维度模型分类

在维度建模的基础上又分为三种模型：星型模型、雪花模型、星座模型。

当所有维度表都直接连接到“事实表”上时，整个图解就像星星一样，故将该模型称为星型模型。星型架构是一种非正规化的结构，标准的星型模型维度只有一层，多维数据集的每一个维度都直接与事实表相连接，不存在渐变维度，所以数据有一定的冗余。比如在地域维度表中，存在国家 A 的省 B 的城市 C 以及国家 A 的省 B 的城市 D 两条记录，那么国家 A 和省 B 的信息分别存储了两次，即存在冗余。

在冗余可以接受的前提下，实际运用中，星型模型使用得更多，也更有效率（以空间换时间）。
当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其图解就像多个雪花连接在一起，故称雪花模型。

雪花模型是对星型模型的扩展，会涉及多级，介于关系模型和星座模型之间，比较靠近3NF，但是无法完全遵守，因为遵循3NF的性能成本太高。它对星型模型的维表进一步层次化，原有的各维表可能被扩展为小的事实表，形成一些局部的 " 层次 " 区域，这些被分解的表都连接到主维度表而不是事实表。比如将地域维表又分解为国家，省份，城市等维表。

雪花模型的优点是可以通过最大限度地减少数据存储量及联合较小的维度表来改善查询性能。

雪花型结构去除了数据冗余，最大限度地减少数据存储量，但是要进行多表关联，在Hadoop体系中会增加shuffle，降低性能。

2.5 数据仓库建模（绝对重点）

2.5.1 ODS层

1）HDFS用户行为数据

2）HDFS业务数据

3）针对HDFS上的用户行为数据和业务数据，我们如何规划处理？

（1）保持数据原貌不做任何修改，起到备份数据的作用。
（2）数据采用压缩，减少磁盘存储空间（例如：原始数据100G，可以压缩到10G左右）
（3）创建分区表，防止后续的全表扫描

2.5.2 DIM层和DWD层

DIM层 DWD层需构建维度模型，一般采用星型模型，呈现的状态一般为星座模型。

维度建模一般按照以下四个步骤：

选择业务过程→声明粒度→确认维度→确认事实

（1）选择业务过程

在业务系统中，挑选我们感兴趣的业务线，比如下单业务，支付业务，退款业务，物流业务，一条业务线对应一张事实表。

（2）声明粒度

数据粒度指数据仓库的数据中保存数据的细化程度或综合程度的级别。
声明粒度意味着精确定义事实表中的一行数据表示什么，应该尽可能选择最小粒度，以此来应各种各样的需求。

典型的粒度声明如下：

• 订单事实表中一行数据表示的是一个订单中的一个商品项。
• 支付事实表中一行数据表示的是一个支付记录。

（3）确定维度

维度的主要作用是描述业务是事实，主要表示的是“谁，何处，何时”等信息。

确定维度的原则是：后续需求中是否要分析相关维度的指标。例如，需要统计，什么时间下的订单多，哪个地区下的订单多，哪个用户下的订单多。需要确定的维度就包括：时间维度、地区维度、用户

（4）确定事实
此处的“事实”一词，指的是业务中的度量值（次数、个数、件数、金额，可以进行累加），例如订单金额、下单次数等。

在DWD层，以业务过程为建模驱动，基于每个具体业务过程的特点，构建最细粒度的明细层事实表。事实表可做适当的宽表化处理。

事实表和维度表的关联比较灵活，但是为了应对更复杂的业务需求，可以将能关联上的表尽量关联上。

	时间	用户	地区	商品	优惠券	活动	度量值
订单	√	√	√				运费/优惠金额/原始金额/最终金额
订单详情	√	√	√	√	√	√	件数/优惠金额/原始金额/最终金额
支付	√	√	√				支付金额
加购	√	√		√			件数/金额
收藏	√	√		√			次数
评价	√	√		√			次数
退单	√	√	√	√			件数/金额
退款	√	√	√	√			件数/金额
优惠券领用	√	√			√		次数

至此，数据仓库的维度建模已经完毕，DWD层是以业务过程为驱动。

DWS层、DWT层和ADS层都是以需求为驱动，和维度建模已经没有关系了。

DWS和DWT都是建宽表，按照主题去建表。主题相当于观察问题的角度。对应着维度表。

2.5.3 DWS层与DWT层

DWS层和DWT层统称宽表层，这两层的设计思想大致相同，通过以下案例进行阐述。

1）问题引出：两个需求，统计每个省份订单的个数、统计每个省份订单的总金额

2）处理办法：都是将省份表和订单表进行join，group by省份，然后计算。同样数据被计算了两次，实际上类似的场景还会更多。

那怎么设计能避免重复计算呢？

针对上述场景，可以设计一张地区宽表，其主键为地区ID，字段包含为：下单次数、下单金额、支付次数、支付金额等。上述所有指标都统一进行计算，并将结果保存在该宽表中，这样就能有效避免数据的重复计算。

3）总结：
（１）需要建哪些宽表：以维度为基准。
（２）宽表里面的字段：是站在不同维度的角度去看事实表，重点关注事实表聚合后的度量值。
（３）DWS和DWT层的区别：DWS层存放的所有主题对象当天的汇总行为，例如每个地区当天的下单次数，下单金额等，DWT层存放的是所有主题对象的累积行为，例如每个地区最近７天（15天、30天、60天）的下单次数、下单金额等。

2.5.4 ADS层

对电商系统各大主题（设备主题、会员主题、商品主题和营销主题）指标分别进行分析。

第三章 数仓环境搭建

3.1 Hive环境搭建

Hive的相关介绍：https://www.cnblogs.com/wkfvawl/p/15594717.html

Hive是一款用类SQL语句来协助读/写、管理那些存储在分布式存储系统上的大数据集的数据仓库软件。

3.1.1 Hive引擎简介

Hive引擎包括：默认MR、tez、spark

Hive on Spark：Hive既作为存储元数据又负责SQL的解析优化，语法是HQL语法，执行引擎变成了Spark，Spark负责采用RDD执行。

Spark on Hive : Hive只作为存储元数据，Spark负责SQL解析优化，语法是Spark SQL语法，Spark负责采用RDD执行。

3.1.2 Hive on Spark配置

1）兼容性说明
注意：官网下载的Hive3.1.2和Spark3.0.0默认是不兼容的。因为Hive3.1.2支持的Spark版本是2.4.5，所以需要我们重新编译Hive3.1.2版本。
编译步骤：官网下载Hive3.1.2源码，修改pom文件中引用的Spark版本为3.0.0，如果编译通过，直接打包获取jar包。如果报错，就根据提示，修改相关方法，直到不报错，打包获取jar包。

2）在Hive所在节点部署Spark
如果之前已经部署了Spark，则该步骤可以跳过，但要检查SPARK_HOME的环境变量配置是否正确。

（1）Spark官网下载jar包地址：
http://spark.apache.org/downloads.html

（2）上传并解压解压spark-3.0.0-bin-hadoop3.2.tgz

[atguigu@hadoop102 software]$ tar -zxvf spark-3.0.0-bin-hadoop3.2.tgz -C /opt/module/
[atguigu@hadoop102 software]$ mv /opt/module/spark-3.0.0-bin-hadoop3.2 /opt/module/spark

（3）配置SPARK_HOME环境变量

[atguigu@hadoop102 software]$ sudo vim /etc/profile.d/my_env.sh

添加如下内容

# SPARK_HOME
export SPARK_HOME=/opt/module/spark
export PATH=$PATH:$SPARK_HOME/bin

source 使其生效

[atguigu@hadoop102 software]$ source /etc/profile.d/my_env.sh

３）在hive中创建spark配置文件

[atguigu@hadoop102 software]$ vim /opt/module/hive/conf/spark-defaults.conf

添加如下内容（在执行任务时，会根据如下参数执行）

spark.master                             yarn
spark.eventLog.enabled                   true
spark.eventLog.dir                       hdfs://hadoop102:8020/spark-history
spark.executor.memory                    1g
spark.driver.memory                      1g

在HDFS创建如下路径，用于存储历史日志

[atguigu@hadoop102 software]$ hadoop fs -mkdir /spark-history

４）向HDFS上传Spark纯净版jar包

说明1：由于Spark3.0.0非纯净版默认支持的是hive2.3.7版本，直接使用会和安装的Hive3.1.2出现兼容性问题。所以采用Spark纯净版jar包，不包含hadoop和hive相关依赖，避免冲突。

说明2：Hive任务最终由Spark来执行，Spark任务资源分配由Yarn来调度，该任务有可能被分配到集群的任何一个节点。所以需要将Spark的依赖上传到HDFS集群路径，这样集群中任何一个节点都能获取到。

（1）上传并解压spark-3.0.0-bin-without-hadoop.tgz

[atguigu@hadoop102 software]$ tar -zxvf /opt/software/spark-3.0.0-bin-without-hadoop.tgz

（2）上传Spark纯净版jar包到HDFS

[atguigu@hadoop102 software]$ hadoop fs -mkdir /spark-jars

[atguigu@hadoop102 software]$ hadoop fs -put spark-3.0.0-bin-without-hadoop/jars/* /spark-jars

５）修改hive-site.xml文件

[atguigu@hadoop102 ~]$ vim /opt/module/hive/conf/hive-site.xml

添加如下内容

<!--Spark依赖位置（注意：端口号8020必须和namenode的端口号一致）-->
<property>
    <name>spark.yarn.jars</name>
    <value>hdfs://hadoop102:8020/spark-jars/*</value>
</property>
 
<!--Hive执行引擎-->
<property>
    <name>hive.execution.engine</name>
    <value>spark</value>
</property>

3.1.3 Hive on Spark测试

（1）启动hive客户端

[atguigu@hadoop102 hive]$ bin/hive

（2）创建一张测试表

hive (default)> create table student(id int, name string);

（3）通过insert测试效果

hive (default)> insert into table student values(1,'abc');

若结果如下，则说明配置成功

如果报错，Execution Error, return code 30041 from org.apache.hadoop.hive.ql.exec.spark.SparkTask. Failed to create Spark client for Spark session
就是指没有连接上spark.
已解决:
思路1: 就是Namenode的端口号问题,hdfs之间的端口号要统一，大家可以去hadoop文件夹里面去找，没改的话就是8020；
思路2: spark的/opt/module/spark/conf该目录中有个spark-env.sh.template
文件然后修改文件名为spark-env.sh

mv spark-env.sh.template spark-env.sh；

然后在该文件中添加:

export SPARK_DIST_CLASSPATH=$(hadoop classpath)

即可. 我是思路2解决的,因为全程跟着这个项目走,视频中确实没有改spark-env.sh这一步. 如果按视频中来做的,兼容性是没问题的.
思路3：在hive/conf/hive-site.xml中增加：（这里特地延长了hive和spark连接的时间，可以有效避免超时报错）

<!--Hive和spark连接超时时间-->
<property>
    <name>hive.spark.client.connect.timeout</name>
    <value>100000ms</value>
</property>

3.2 Yarn配置

3.2.1 增加ApplicationMaster资源比例

容量调度器对每个资源队列中同时运行的Application Master占用的资源进行了限制，该限制通过yarn.scheduler.capacity.maximum-am-resource-percent参数实现，其默认值是0.1，表示每个资源队列上Application Master最多可使用的资源为该队列总资源的10%，目的是防止大部分资源都被Application Master占用，而导致Map/Reduce Task无法执行。

生产环境该参数可使用默认值。但学习环境，集群资源总数很少，如果只分配10%的资源给Application Master，则可能出现，同一时刻只能运行一个Job的情况，因为一个Application Master使用的资源就可能已经达到10%的上限了。故此处可将该值适当调大。

（1）在hadoop102的/opt/module/hadoop-3.1.3/etc/hadoop/capacity-scheduler.xml文件中修改如下参数值

[atguigu@hadoop102 hadoop]$ vim capacity-scheduler.xml

（2）分发capacity-scheduler.xml配置文件

[atguigu@hadoop102 hadoop]$ xsync capacity-scheduler.xml

（3）关闭正在运行的任务，重新启动yarn集群

[atguigu@hadoop103 hadoop-3.1.3]$ sbin/stop-yarn.sh
[atguigu@hadoop103 hadoop-3.1.3]$ sbin/start-yarn.sh

3.3 数仓开发环境

数仓开发工具可选用DBeaver或者DataGrip。两者都需要用到JDBC协议连接到Hive，故需要启动HiveServer2。

1.启动HiveServer2

[atguigu@hadoop102 hive]$ hiveserver2

2.配置DataGrip连接

1）创建连接

2）配置连接属性
所有属性配置，和Hive的beeline客户端配置一致即可。初次使用，配置过程会提示缺少JDBC驱动，按照提示下载即可。

3.测试使用
创建数据库gmall，并观察是否创建成功。

1）创建数据库

2）查看数据库

3）修改连接，指明连接数据库

4）选择当前数据库为gmall

3.4 数据准备

一般企业在搭建数仓时，业务系统中会存在一定的历史数据，此处为模拟真实场景，需准备若干历史数据。假定数仓上线的日期为2020-06-14，具体说明如下。

3.4.1 用户行为日志

用户行为日志，一般是没有历史数据的，故日志只需要准备2020-06-14一天的数据。具体操作如下：

https://www.cnblogs.com/wkfvawl/p/15834034.html

1）启动日志采集通道，包括Flume、Kafak等
2）修改两个日志服务器（hadoop102、hadoop103）中的/opt/module/applog/application.yml配置文件，将mock.date参数改为2020-06-14。
3）执行日志生成脚本lg.sh。
4）观察HDFS是否出现相应文件。

3.4.2 业务数据

业务数据一般存在历史数据，此处需准备2020-06-10至2020-06-14的数据。具体操作如下。

1）修改hadoop102节点上的/opt/module/db_log/application.properties文件，将mock.date、mock.clear，mock.clear.user三个参数调整为如图所示的值。

2）执行模拟生成业务数据的命令，生成第一天2020-06-10的历史数据。

[atguigu@hadoop102 db_log]$ java -jar gmall2020-mock-db-2021-01-22.jar

3）修改/opt/module/db_log/application.properties文件，将mock.date、mock.clear，mock.clear.user三个参数调整为如图所示的值。

4）执行模拟生成业务数据的命令，生成第二天2020-06-11的历史数据。

[atguigu@hadoop102 db_log]$ java -jar gmall2020-mock-db-2021-01-22.jar

5）之后只修改/opt/module/db_log/application.properties文件中的mock.date参数，依次改为2020-06-12，2020-06-13，2020-06-14，并分别生成对应日期的数据。

6）执行mysql_to_hdfs_init.sh脚本，将模拟生成的业务数据同步到HDFS。

[atguigu@hadoop102 bin]$ mysql_to_hdfs_init.sh all 2020-06-14

7）观察HDFS上是否出现相应的数据