每个业务主题模块都会产生海量的数据，我们的任务是对这些海量的数据进行分析，统计。注意如上图所示，并不是每个业务模块只会产生1张表，而是一类表，可能意向用户主题模块会产生很多很多表。在每个业务模块的背后还有大量的需求要求，比如获取到意向数据统计一下有意向的用户人数，有意向的用户所在城市分布.....等等。

二、项目架构流程

项目的架构：

基于cloudera manager大数据统一管理平台，结合zookeeper，hdfs，yarn，hive，oozie，sqoop，hue，finebi等相关工具，实现了在线教育大数据分析平台的搭建

各软件作用：

zookeeper：集群管理工具，主要服务于hadoop高可用（hbase，kafka），在zookeeper的基础上搭建的hadoop集群是高可用的

oozie：实现自动化任务调度

sqoop：实现数据的导入与导出

hue：hive与hadoop等大数据软件的客户端工具，方便用户体验

cloudera manager：用于监控大部分大数据软件的WEB UI以及监控服务器本身十分正常、

数据流转流程：

业务数据存储在MySQL数据库中，首先通过sqoop工具将MySQL中的业务数据抽取到Hive的ODS层，其次对数据进行ETL清洗，标准化，维度退化等预处理工作，然后按某个特定的主题将分散的数据进行聚合以方便后续数据分析，随后对数据进行分析统计并将分析的结果通过sqoop导出到MySQL中，最后使用finebi实现图表展示操作。由于分析工作具有周期性，采用ooize进行自动化任务调度。整个项目基于cloudera manager进行统一监控管理。

面试题：

请介绍一下最近做了一个什么项目？（总体介绍（背景，为什么做这个项目，来自于哪个公

司的项目等等）+项目架构+数据流转流程）

请介绍项目的架构是什么方案？（项目架构+数据流转流程）

整个项目各个软件是如何交互的？（数据流转流程）

三、cloudera manager（CM）基本介绍

大数据的发行版本主要有三个：Apache官方社区版本，cloudera公司推出的CDH商业版本，Hortworks推出的HDP商业免费版本，目前HDP版本已被cloudera收购（HDP版本用的不多）

1、cloudera manager工具产生的背景

（1）Apache官方社区版大数据组件

该版本的大数据组件一般用于个人学习使用，不适合商业化。

优点：完全开源，更新速度块；大数据组件需要手动部署方便我们了解其底层原理；可以了解各个组件的依赖关系。

缺点：部署过程极其复杂，超过20台服务器或更多100台，1000台，手动部署很麻烦

各组件一般都有自己的WEB UI界面，Apache版本的大数据组件没有统一化管理界面

组件与组件之间的依赖关系很复杂（例如hive依赖于hadoop，可能hive的x.x版本与

hadoop的x.x版本兼容，与hadoop的y.y版本又不兼容了），一环扣一环，部署过程很累

各组件之间没有统一的metric可视化界面，比如hdfs总共占用的磁盘空间，IO，运行

状况等

优化等需要用户自己根据业务场景进行调整（修改配置文件需要一个一个分发，发现

配置错了，在修改然后在来分发....）

总之在生产环境中尤其大中型企业如果使用Apache大数据版本可能配置个环境需要成百上千人配置1个月，这显然是不行的。

（2）CDH版本大数据组件

为了解决Apache原生版本的各种缺陷，诞生了可以使用Cloudera Manager进行管理的CDH版本。CDH是Apache Hadoop和相关项目中最完整，最稳定的，经过测试和最流行的发行版。CDH的出现帮助解决了各个软件之间的兼容问题，同时内置了大量常规企业优化方案，可也实现集群自动部署，为了方便用户体验，专门推出了一款用于监控管理自家产品的大数据软件：Cloudera Manager

使用Cloudera Manager可以轻松部署和集中操作完整的CDH堆栈和其他托管服务（hadoop，

hive，spark，kudu）。其特定是：应用程序的安装过程自动化

提供运行主机和大数据组件的实时监控统一视图

提供单个中央控制台，以在整个集群中实施配置更改

集成了全套的报告和诊断工具，帮助我们优化性能与利用率

优点：统一化的可视化界面；自动化部署与配置（hadoop，hive，hue，zookeeper.....）；调优极其便捷；零停机维护（用户感觉不到后台在维护达到维护零影响）；多用户管理（权限控制）；稳定性好（部分优化措施都已经调整好）

缺点：占内存；需要使用者深入了解linux命令

2、cloudera manager应用场景

节点在5个以上的集群

专业大数据公司

运维工作较频繁的场景

3、cloudera manager的架构

4、cloudera manager的功能

（1）信号检测

默认情况下Agent（监测当前节点是否正常）每隔15s向Cloudera Manager Server发送一次检测信号。如果运行状态不良，后续会提高检测频率，直到正常为止。

（2）软件监测

监测各个大数据软件hdfs，yarn....是否正常启动，监测配置文件的修改，一旦配置信息被修改会触发重启进程。捕获各个软件的运行情况及其他信息。

（3）主机管理

快速实现主机节点的添加与删除，例如当前hadoop集群有10台服务器，由于业务量增加这10台服务器已经不够用了需要在添加10台，CM可以很方便快捷的为hadoop集群添加服务器和删除服务器。

（4）进程启停

开启hadoop的hdfs，yarn；开启hive等等都可以在CM上可视化操作。

（5）监控管理

监控软件在运行时的状态，主机是否健康等等各种信息

四、项目环境搭建

解压3台虚拟机CDH_DataBase1/2/3.zip到无中文无空格的环境中，然后挂载到VMware上（点击.vmx文件可自动挂载），其次启动虚拟机即可，注意在启动过程中一定要点击“我已移动该虚拟机”。这里使用的虚拟机已经事先配置好主机名、网络、主机名地址映射以及所有使用的大数据组件，当然我们也可以自己创建虚拟机然后手动设置。由于在hadoop01上运行的东西较多因此配置高点，这些都可以自行设置。

hadoop01 : 192.168.52.150

hadoop02 : 192.168.52.151

hadoop03 : 192.168.52.152

网关 : 192.168.52.1

设置虚拟机VMnet8子网信息与上述配置一致，设置windows中VMnet8信息与上述配置一致。然后可以利用finalshell远程连接到虚拟机。

设置Windows中主机名地址映射，地址为C:\Windows\System32\drivers\etc\hosts。然后访问hadoop01:7180即可进入cloudera manager界面用户名和密码初始都是admin。

yarn有点小毛病，点击yarn

至此所有环境搭建完成：

上述大数据软件都是CDH 6.2.1版本，在该版本下所有软件都是兼容的。

注意：后续不用虚拟机时一定不能挂起，不能强制关机，需要使用shutdown -h now命令关机，重启服务器使用reboot命令；开启虚拟机后CM和所有的大数据软件会自动启动，这个启动过程可能会耗时10-20分钟，因此可能会出现刚启动虚拟机直接访问7180端口打不开的情况。

关闭CM监控功能（耗内存）：关闭后仅仅是无法实现实时监控，整个集群还是正常运行中。

至于CM的安装与CDH的安装后续会详细介绍。

五、维度分析

1、什么是维度

维度一般指分析的角度，看待一个问题的时候可以多个角度来看待，而这些角度就是维度。例如：有一份2020年订单数据，我们可以从时间、地域、商品、来源、用户、...等等多个角度进行分析，这些都是维度。

维度可以分为定性维度和定量维度两种，定性维度强调分析的角度是笼统的，例如统计每天、每月、每年、各个的维度，没有具体到统计哪天、哪月、哪年。一般来说定性维度的字段都是放置在group by中；定量维度强调统计某个具体的维度或某个范围下的信息，例如统计2020年度订单额，统计20-30岁区间人群的人数。一般来说定量维度的字段都放置在where中。

维度的分层与分级：本质上是对维度进行细分的过程。比如时间维度，我们按年进行统计，还可以按季度、月、天、小时进行逐步细化的统计；又比如我们统计全国的人口数，还可以按省、市、县进行逐步细化统计。在实际分析中，统计的层级越多，意味着统计越细化维度越多。

维度的下钻和上卷：以某一个维度为基准，往细化统计的过程称为下钻，往粗粒度统计的过程称为上卷。例如当前是按天统计，如果需要统计出每小时的信息需要下钻。如果需要统计出每年、季度、月的信息需要上卷。在实际分析中，下钻与上卷意味着维度变多。

2、什么是指标

指标就是衡量事务发展的标准，即度量值。常见的指标有count() sum() max() min() avg()，以及一些比率指标转化率，流失率，同比增长率等等。指标又分为绝对指标和相对指标两种，绝对指标指计算具体值的指标，例如count() sum() max() min() avg()。相对指标指计算比率问题的指标。

3、维度分析

维度分析就是针对某个主题，从不同的维度进行统计分析，从而得出各种指标的过程。它是数据分析的一种常用手段。

案例：请求出在2020年度，女性，未婚，年龄在18-25岁区间的用户每一天的订单量？

维度：时间，性别，婚姻状态，年龄，用户

定性维度：每一天--day 用户--user

定量维度：2020年度--year 18-25岁--age 女性--sex 未婚--marrystatus

指标：订单量（绝对指标）--count()

----->

select user, day, count(*) from 表 where year = '2020' and age between 18 and 25 and marrystatus = '未婚' and sex = '女性' group by user, day;

只要从具体的需求中分析出维度有那些，指标有那些，相当于把SQL语句也写了。

六、数仓建模

1、维度建模

数仓建模是规定如何在hive中构建表，这些表的构建要利于后续的数据分析，数仓建模中主要提供两种理论来进行数仓建模操作：三范式建模和维度建模理论

三范式建模：主要存在于关系型数据库建模方案上（业务数据库建模方案上），主要规定了比如所建的每一个表都应该有一个主键，数据尽可能避免冗余的发生等等。

维度建模：主要存在于分析型数据库建模方案上，一切以分析为目标，只要是利于分析的建模都是可以的，因此运行出现一定的冗余，表也可以没有主键。

三范式建模一般会对表进行拆分，使表尽可能没有冗余，不利于查询，查询时大概率会多表关联，很费劲。维度建模一般是将零散的表进行聚合，利于查询，查询时大概率只需要操作一张表即可。构建数仓的目的就是为了对数据进行分析，因此使用维度建模方式。

维度建模有两种表：事实表与维度表

2、什么是事实表与维度表

事实表：一般指分析主题所对应的表，每一条数据用于描述一个具体的事实信息，这些表一般都是一堆主键（外键）和描述事实字段的聚集，事实表一定存在。

例如：统计2020年度订单销售情况

主题：订单

事实表：与主题“订单”密切相关的表订单表，订单表中的一条数据描述了一个具体的订单信息。订单表一般有：订单id，商品id，单价，购买的数量，下单时间，用户id，商家id，省份id，市区id，县id，商品价格等等字段。进行统计分析时，可以结合商品维度，用户维度，商家维度，地区维度进行统计分析，在统计分析时可能会关联到其他表（维度表），比如需要获取具体的用户姓名，则用户表就是维度表。事实表一般囊括多种维度，维度表一般只涉及一种维度，如用户表只涉及用户维度。

主键（外键）：商品id，用户id，商家id，省份id，市区id，县id

描述事实字段：订单id，单价，购买的数量，下单时间，商品价格

维度表：指在对事实表进行统计分析的时候，基于某一个维度，而这个维度信息可能存在与其他表中，这个表就是维度表。维度表不一定存在，但维度一定存在。

例如：根据用户维度进行统计，如果在事实表中只存储了用户id，此时需要关联用户表，此时维度表存在。如果在事实表中不仅仅存储了用户id，还存储了用户名称等其他信息，这个时候就不需要用户表的参与，意味着没有维度表，但用户维度还存在。

注意：一般需要计算的指标字段所在的表都是事实表，例如上文案例：请求出在2020年度，女性，未婚，年龄在18-25岁区间的用户每一天的订单量？指标是订单量，那么能够计算订单量的表就是事实表。

3、事实表与维度表的分类

（1）事实表的分类

事务事实表：保存的是最原始的数据，也称“原子事实表”或“交易事实表”。沟通中常说的

事实表，大多指事务事实表。与主题密切相关的表，一行数据能表示一个

具体的事务信息的表，如上文中的订单表。一条数据表示一个具体的订单

信息

周期快照事实表：周期快照事实表由事务事实表加工产生，即对事务事实表按照某一个

可预见周期进行提前聚合形成的事实表。可预见周期如每天，每月，每年

累计快照事实表：完全覆盖一个事务或产品的生命周期的时间跨度，通常该表具有多个

日期字段，用来记录整个生命周期中的关键时间点。

案例：统计2020年度订单相关情况

主题：订单

事实表：订单表order（事务事实表）

假设现在有这么一个需求：请统计每天有多少个用户下单，并要求上卷到月。（需要按天统计，按月统计）

基于事务事实表统计：

按天统计：select substr(o_time,1,10), count(uid) from order group by substr(o_time,1,10);

统计结果：需要计算4次

2021-08-20 2

2021-08-21 2

按月统计：select substr(o_time,1,7), count(uid) from order group by substr(o_time,1,7);

统计结果：需要计算4次

2021-08 4

基于周期快照事实表按月统计

select substr(o_time,1,7), sum(u_num) from 周期快照事实表 group by substr(o_time,1,7);

统计结果：需要计算2次

2021-08 4

总结：通过周期快照事实表完成提前聚合操作，当需要进行上卷统计时，只需要对周期快照事实表进行累加即可，减少了数据扫描量，提高了查询效率。当然如果uid有重复则无法使用周期快照事实表。

（2）维度表的分类

高基数维度表：指维度表中的数据量比较庞大，且数据会发生变化的表。例如商品表，

用户表。

低基数维度表：指维度表中的数据量不多，且数据相对比较稳定的表，数据量一般在几

十条到几千条左右。例如日期表，配置表，区域表。

4、维度建模的三种模型

第一：星型模型

特点：只有一个事实表，意味着只有一个分析的主题，在事实表的周围围绕了多个维度表，维度表与维度表之间没有任何的依赖。反映数仓发展初期最容易产生的模型。

第二：雪花模型

特点：只有一个事实表，意味着只有一个分析的主题，在事实表的周围围绕了多个维度表，维度表可以接着关联其他的维度表。反映数仓发展出现畸形时产生的模型（该模型一旦大量出现，后期维护会变得非常繁琐，同时如果依赖层次越多，sql分析的难度也会加大，因此在实际生产中，建议尽量减少该模型的产生）

第三：星座模型

特点：有多个事实表，意味着有多个分析的主题，在事实表的周围围绕了多个维度表，多个事实表在条件符合的情况下，可以共享维度表。反映数仓发展中后期最容易产生的模型。

在实际生产环境中最容易出现的时雪花模型。此时需要我们将模型进行优化，时模型尽可能减少雪花模型的出现。

5、缓慢渐变维

解决问题：解决历史变更数据是否需要维护的情况

缓慢渐变维即维度中的属性可能会随着时间发生变化，例如用户所在城市可能发生改变，进而影响后续统计分析精度（通俗来讲缓慢渐变维就是指那些随着时间的推移会发生缓慢变化的字段）

例如目前业务数据库中有这样一条顾客信息被存储在数仓中：该顾客所在城市为beijing，在beijing期间花费100万元，因此正常情况下统计该用户在不同城市消费情况时，beijing有100万元。

如果由于某些原因，该顾客搬到sanya了，此时业务数据库中的信息变更为：

本身在数仓中已有该顾客的记录，但是该顾客记录发生了变化，数仓如何处理呢？假设数仓直接全部覆盖（同步信息），那么会导致理应在bijing消费的100万，变更为三亚，这与事实不符，数据分析结果出现问题。

为了解决由于对历史数据维护不当导致的分析问题，提出了3中解决方案：

SCD1：直接覆盖，不维护历史数据。主要适用于对错误数据处理

SCD2：不删除，不修改已存在的数据，当数据发生变更后，会添加一条新的版本记录数据，并在建表时多加两个时间字段：起始时间，截止时间，通过这两个字段来标记每条数据的起止时间，可以有效解决上述问题。使用该方案产生的新表一般称为拉链表，在实际生产过程中较为常用。

优点：适用于保存多个历史版本，方便维护实现

缺点：会造成数据冗余情况，导致磁盘占用率提升

SCD3：通过增加列的方式来维护历史变更数据

优点：减少了数据冗余，适用于少量历史版本的记录以及磁盘空间不是特别充足的情况

缺点：无法记录更多的历史版本，因为每次修改数据都会导致表结构增加一列，会涉及

对表结构的更改，不宜频繁。后续维护比较繁琐。

面试题：

1）在项目中，如何实现历史数据变化维护工作

2）如何实现历史版本数据维护，你有几种方案？SCD1，2，3

3）请简述如何实现拉链表

基本数仓架构

七、本项目数仓架构

1、维度退化

维度退化的目的是减少维度表的关联工作。

例如：例如某教育机构有5家分公司，分别位于北京，上海，深圳，杭州，南京。现要求对所有分公司的业务数据进行统计分析（由于这些公司都隶属于某教育机构，因此假设各公司的业务数据结构一致）。显然每个分公司都有一堆一模一样的表，比如北京，上海，深圳，杭州，南京的公司都有用户表（用户id，用户名称，用户所在地，用户联系电话），后续按某一主题分析时，如果需要利用用户表，此时需要关联5张表，这很麻烦，因此需要维度退化即将用户表增加一个字段：用户表（用户id，用户名称，用户所在地，用户联系电话，公司所在地），此时5张表就变为一张大宽表，后续分析只需要关联1张表即可，减少了维度表的关联工作，提高了查询效率。

又例如：某公司没有分公司，维度退化是在数据分析过程中将可能用到的维度表的相关字段退化到事实表中，这样后续在基于维度统计时就不需要关联维度表了，事实表中已经涵盖了相应的维度数据。比如：

原有订单表只有用户id，当我们需要根据用户维度进行统计分析时，就必须关联用户表找到用户名称和其他相关信息，如果我们提前将用户名称和其他相关信息放置到订单表中，那么就不用在关联用户表了，减少了维度表的关联工作，提高了查询效率。

2、架构

ODS层（源数据层）：存储事实表与少量维度表数据

DIM层（维度层）：存储维度表数据（维度表太多情况，维度表不多该层就不需要）

DW层（数据仓库层）：Data Warehouse Detail/Middle/Service

DWD层（明细层）：用于对ODS层的数据进行ETL清洗，以及少量的维度退化操作

少量：1）将多个事实表的数据合并为一个事实表

2）如果维度表存储在ODS层，意味着当前维度表不多，维度退化工作在

DWD层进行，DWD层不对DIM层的维度表处理

DWM层（中间层）：1）对DIM层的维度表进行维度退化

2）用于对事实表进行提前聚合操作，形成周期快照事实表

DWS层（业务层）：进行细化维度统计分析操作，存储分析结果

DA/ADS层（数据应用层）：存储基于DWS层再次分析的结果（提取利于后续做报表等等任务的分析结果），用于对接后续应用（报表，推荐系统...）。例如DWS层的数据表完成了基于订单表各项统计结果信息，但是图表只需要其中销售额，此时从DWS层将销售额的数据提取出来存储到DA层。

八、HUE的使用

HUE软件可以远程连接各种hadoop生态圈的框架（将各种软件的操作界面集成到一起），利用图形化界面对其进行操作，方便用户的体验。首先打开CM（hadoop01:7180）

用户名与密码默认hue：可以看到hue已经连接到hive了（已提前配置好）

HDFS操作创建文件夹与文件：

编辑文件：

右键还可以进行对文件或文件夹的重命名，移动等操作：

HIVE操作-对表进行操作：（也可以右键表）

切换到Hive：

HUE还嵌入了YARN的WEB UI界面：可以看到正在YARN中运行的MapReduce程序

HUE与DBeaver，DataGrip一样可以实现很多大数据组件的连接，方面用户体验。由于HUE是通过浏览器方式访问的，因此HUE相比于DBeaver，DataGrip等工具资源占用率较小。HUE安装好后默认开启8889端口（本项目HUE安装在hadoop02上，WEB UI ： hadoop02:8889）

九、自动化调度工具介绍

1、基本介绍

大数据常用的任务调度工具有oozie和Azkaban，可以实现任务的自动化执行（工作流）。通常情况下，能够用自动化调度工具完成的业务一般具有以下特点：

1）整个业务流程需要周期性重复的去做

2）整个业务流程可以被划分为多个阶段，每个阶段存在依赖关系，必须步骤1执行完，才能执行步骤2，步骤2执行完才能执行步骤3.......

2、常见工具

单独使用：

Azkaban：来源于领英公司，通过配置.job文件设置键值对方式配置业务依赖，只需要简单的几行命令即可实现工作流的配置工作，此外Azkaban提供了一个非常便利的WEB UI界面，通过该界面可以对工作流进行监控管理。它的核心是将业务各步骤编写为shell脚本，然后编写.job文件配置shell脚本依赖关系（谁先执行谁后执行），最后实现业务的自动化调度。

oozie：来源于apache，出现时间较早，整个工作流的配置主要采用XML方式进行。配置过程十分繁琐，oozie的本质是将工作流翻译成MapReduce程序来运行（与hive，sqoop类似），在配置过程中配置一个MR相当于将MR重写一遍。同样oozie提供了一个WEB UI界面，但是该界面只能查看，无法进行操作，而且由于oozie比较老界面十分卡顿。

因此，在单独使用时Azkaban比oozie好

与HUE结合使用：

HUE来源于apache，由于Azkaban不属于apache，所以Azkaban无法和HUE集成。同理Azkaban也不是cloudera公司的，因此Azkaban也无法利用CM自动化安装与监控。总之，如果使用Azkaban工具就需要单独使用和维护。

HUE属于apache，所以apache公司一定是优先集成自家的产品，而oozie也属于apache，因此oozie可以很好的集成到HUE中，集成之后，只需要用户通过鼠标简单点一点即可实现复杂的工作流配置。

因此，加入HUE后，oozie比Azkaban更好用