数仓学习---7、数据仓库设计、数据仓库环境准备

最新推荐文章于 2023-12-30 02:32:16 发布

星光下的赶路人star

最新推荐文章于 2023-12-30 02:32:16 发布

阅读量599

点赞数 2

分类专栏：数仓文章标签：学习数据仓库大数据 hive

本文链接：https://blog.csdn.net/qq_44804713/article/details/131780567

版权

数仓专栏收录该内容

15 篇文章 8 订阅

订阅专栏

这是本人的学习过程，看到的同道中人祝福你们心若有所向往，何惧道阻且长；
但愿每一个人都像星星一样安详而从容的，不断沿着既定的目标走完自己的路程；
最后想说一句君子不隐其短，不知则问，不能则学。
如果大家觉得我写的还不错的话希望可以收获关注、点赞、收藏（谢谢大家）

一、数据仓库设计

1.1 数仓仓库分层规划

优秀可靠的数仓体系，需要良好的数据分层结构。合理的分层，能够使数据体系更清晰，使复杂问题得以简化。以下是该项目的分层规划
在这里插入图片描述

1.2 数据仓库构建流程

在这里插入图片描述

1.2.1 数据调研

数据调研重点要做两项工作，分别是业务调研和需求分析。这两项工作做的是否充分，直接影响着数据仓库的质量。
1、业务调研
业务调研的主要目标是熟悉业务流程、熟悉业务数据。

熟悉业务流程要求做到，明确每个业务的具体流程，需要将该业务所包含的每个业务过程一一列举出来。

熟悉业务数据要求做到，将数据（包括埋点日志和业务数据表）与业务过程对应起来，明确每个业务过程会对哪些表的数据产生影响，以及产生什么影响。产生的影响，需要具体到，是新增一条数据还是修改一条数据，并且需要明确新增的内容或是修改的逻辑。

下面是业务电商中的交易为例进行演示，交易业务涉及到的业务过程有买家下单、买家支付、卖家发货、买家收货，具体流程如下图。

在这里插入图片描述
2、需求分析
典型的需求指标如，最近一天各省份手机品类订单总额。
分析需求时，需要明确需求所需的业务过程及维度，例如该需求所需的业务过程就是买家下单，所需的维度有日期，省份，商品品类。

3、总结
做完业务分析和需求分析，要保证每个需求都能找到与之对应的业务过程及维度。若现有数据无法满足需求，则需要和业务方进行沟通，例如某个页面需要新增某个行为的埋点。

1.2.2 明确数据域

数据仓库模型设计除横向的分层之外，通常也需要根据业务情况进行纵向划分数据域。划分数据域的意义是便于数据的管理和应用。

通常可以根据业务过程或者部门进行划分，本项目根据业务过程进行划分，需要注意的是一个业务过程只能属于一个数据域。

下面是本数仓项目所需的所以业务过程及数据域划分详情。

数据域	业务过程
交易域	加购、下单、取消订单、支付成功、退单、退款成功
流量域	页面浏览、启动应用、动作、曝光、错误
用户域	注册、登陆
互动域	收藏、评价
工具域	优惠券领取、优惠券使用（下单）、优惠券使用（支付）

1.2.3 构建业务总线矩阵

业务总线矩阵包含维度模型所需的所有事实（业务过程）以及维度，以及各业务过程与各维度的关系。矩阵的行是一个个业务过程，矩阵的列是一个个的维度，行列的交点表示业务与维度的关系。
在这里插入图片描述
一个业务过程对应维度模型中的一张事务型事实表，一个维度则对应维度模型中的一张维度表。所以构建业务总线矩阵的过程就是设计维度模型的过程。但是需要注意的是，总线矩阵中通常只包含事务型事实表，另外两种类型的事实表需单独设计。

按照事务型事实表的设计流程，选择业务过程-》声明粒度-》确认维度-》确认事实，得到的最终的业务总线矩阵见以下表格。

在这里插入图片描述
后续的DWD层以及DIM层的搭建需要参考业务总线矩阵。

1.2.4 明确统计指标

明确统计指标具体的工作是深入分析，构建指标体系。构建指标体系的主要意义就是指定义标准化。所有指标的定义，都必须遵循同一套标准，这样能有效的避免指标定义存在歧义，指标定义重复等问题。

1、指标体系相关概念
（1）原子指标
原子指标基于某一业务过程的度量值，是业务定义中不可再拆解的指标，原子指标的核心功能就是对指标的聚合逻辑进行了定义。我们可以得出结论，原子指标包含三要素，分别是业务过程、度量值和聚合逻辑。

例如订单总额就是一个典型的原子指标，其中的业务过程为用户下单、度量指为订单金额，聚合逻辑为sum()求和。需求注意的是原子指标只是用来辅助定义指标一个概念，通常不会对应有实际统计需求与之对应。

（2）派生指标
派生指标基于原子指标，其与原子指标的关系如下图

在这里插入图片描述
与原子指标不同，派生指标通常会对应实际的统计需求。
（3）衍生指标
衍生指标是在一个或多个派生指标的基础上，通过各种逻辑运算复合而成。例如比率、比例等类型的指标。衍生指标也会对应实际统计需求。
在这里插入图片描述
2、指标体系对于数仓建模的意义
通过上述两个具体的案例可以看出，绝大多数的统计需求，都可以使用原子指标、派生指标以及衍生指标这套标准去定义。同时能够发现这些统计需求都直接的或间接的对应一个或者是多个派生指标。

当统计需求足够多时，必然会出现部分统计需求对应的派生指标相同的情况。这种情况下，我们就可以考虑将这些公共的派生指标保存下来，这样做的主要目的就是减少重复计算，提高数据的复用性。

这些公共的派生指标统一保存在数据仓库的DWS层。因此DWS层设计，就可以参考我们根据现有的统计需求整理出的派生指标。

按照上述标准整理出的指标体系如下：
原子指标
在这里插入图片描述

1.2.4 维度模型设计

维度模型的设计参照上述得到的业务总线矩阵即可。事实表储存在DWD层，维度表储存在DIM层。

1.2.5 汇总模型设计

汇总模型的设计参考上述整理出的指标体系（主要是派生指标）即可。汇总表与派生指标的对应关系是，一张汇总表通常包含业务过程相同、统计周期相同、统计粒度相同的多个派生指标。

二、数据仓库环境准备

2.1 数据仓库运行环境

2.1.1 Hive环境搭建

1、Hive引擎简介
Hive引擎包括：默认MR、Tez、Spark。
Hive on Spark：Hive既作为储存元数据又负责SQL的解析优化，语法是HQL语法，执行引擎变成了Spark，Spark负责采用RDD执行。

Spark On Hive：Hive只作为储存原数据，Spark负责SQL解析优化，语法是SparkSQL语法，Spark负责采用RDD执行。

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
（2-1）Spark官网下载jar包地址
http://spark.apache.org/downloads.html
（2-2）上传并解压解压spark-3.0.0-bin-hadoop3.2.tgz
（2-3）配置SPARK_HOME环境变量

vim /etc/profile.d/my_env.sh

#添加如下内容
# SPARK_HOME
export SPARK_HOME=/opt/module/spark
export PATH=$PATH:$SPARK_HOME/bin

#Source使其生效
 source /etc/profile.d/my_env.sh

（2-4）在hive中创建spark配置文件

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创建如下路径，用于存储历史日志。
hadoop fs -mkdir /spark-history

（2-5）向HDFS上传Spark纯净版jar包
说明1：由于Spark3.0.0非纯净版默认支持的是hive2.3.7版本，直接使用会和安装的Hive3.1.2出现兼容性问题。所以采用Spark纯净版jar包，不包含hadoop和hive相关依赖，避免冲突。
说明2：Hive任务最终由Spark来执行，Spark任务资源分配由Yarn来调度，该任务有可能被分配到集群的任何一个节点。所以需要将Spark的依赖上传到HDFS集群路径，这样集群中任何一个节点都能获取到。

（2-5-1）
上传并解压spark-3.0.0-bin-without-hadoop.tgz
（2-5-2）上传Spark纯净版jar包到HDFS

（2-6）修改hive-site.xml文件

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、Hive on Spark测试
（1）启动hive客户端
在这里插入图片描述

（2）创建一张测试表
在这里插入图片描述

（3）通过insert测试效果
在这里插入图片描述

2.1.2 Yarn环境配置

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文件中修改如下参数值

vim capacity-scheduler.xml

#修改
<property>
    <name>yarn.scheduler.capacity.maximum-am-resource-percent</name>
    <value>0.8</value>
</property

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

 xsync capacity-scheduler.xml

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

sbin/stop-yarn.sh
sbin/start-yarn.sh

2.2 数据仓库开发环境

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

hiveserver2

2、配置DataGrip连接
（1）创建连接
在这里插入图片描述
（2）配置连接属性
所有属性配置，和Hive的beeline客户端配置一致即可。初次使用，配置过程会提示缺少JDBC驱动，按照提示下载即可。

（3）测试使用
创建数据库gmall，并观察是否创建成功。
（1）创建数据库
在这里插入图片描述

（2）查看数据库
在这里插入图片描述
（3）修改连接，指明连接数据库

（4）选择当前数据库为gmall

在这里插入图片描述

2.3 模拟数据准备

通常企业在开始搭建数仓时，业务系统中会存在历史数据，一般是业务数据库存在历史数据，而用户行为日志无历史数据。假定数仓上线的日期为2020-06-14，为模拟真实场景，需准备以下数据。
注：在执行以下操作之前，先将HDFS上/origin_data路径下之前的数据删除。

1、用户行为日志
用户行为日志，一般是没有历史数据的，故日志只需要准备2020-06-14一天的数据。具体操作如下：
（1）启动日志采集通道，包括Flume、Kafak等
（2）修改两个日志服务器（hadoop102、hadoop103）中的
/opt/module/applog/application.yml配置文件，将mock.date参数改为2020-06-14。
（3）执行日志生成脚本lg.sh。
（4）观察HDFS是否出现相应文件。
2、业务数据
业务数据一般存在历史数据，此处需准备2020-06-10至2020-06-14的数据。具体操作如下。
（1）生产模拟数据
（1-1）修改hadoop102节点上的/opt/module/db_log/application.properties文件，将mock.date、mock.clear，mock.clear.user三个参数调整为如图所示的值。
在这里插入图片描述
（1-2）执行模拟生成业务数据的命令，生成第一天2020-06-10的历史数据。

java -jar gmall2020-mock-db-2021-01-22.jar

（1-3）修改/opt/module/db_log/application.properties文件，将mock.date、mock.clear，mock.clear.user三个参数调整为如图所示的值。
在这里插入图片描述
（1-4）执行模拟生成业务数据的命令，生成第二天2020-06-11的历史数据。

java -jar gmall2020-mock-db-2021-10-10.jar

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

（2）全量表同步
（2-1）执行全量表同步脚本

mysql_to_hdfs_full.sh all 2020-06-14

（2-1）观察HDFS上是否出现全量表数据

（3）增量表首日全量同步
（3-1）清除Maxwell断点记录
由于Maxwell支持断点续传，而上述重新生成业务数据的过程，会产生大量的binlog操作日志，这些日志我们并不需要。故此处需清除Maxwell的断点记录，另其从binlog最新的位置开始采集。
关闭Maxwell。

mxw.sh stop

清空Maxwell数据库，相当于初始化Maxwell。

mysql> 
drop table maxwell.bootstrap;
drop table maxwell.columns;
drop table maxwell.databases;
drop table maxwell.heartbeats;
drop table maxwell.positions;
drop table maxwell.schemas;
drop table maxwell.tables;

（3-2）修改Maxwell配置文件中的mock_date参数

vim /opt/module/maxwell/config.properties
#修改如下
mock_date=2020-06-14

（3-3）启动增量表数据通道，包括Maxwell、Kafka、Flume
（3-4）执行增量表首日全量同步脚本

mysql_to_kafka_inc_init.sh all

（3-5）观察HDFS上是否出现全量表数据

恭喜大家看完了小编的博客，希望你能够有所收获，我一直相信躬身自问和沉思默想会充实我们的头脑，希望大家看完之后可以多想想喽，编辑不易，求关注、点赞、收藏（Thanks♪(･ω･)ﾉ）。