项目面试记录

项目描述：

通过分析用户的上网行为，对用户的行为进行分析，计算网站的关键指标，为网站的栏目设置，板块划分，以及预测产品的趋势提供决策支持。通过埋点代码收集到用户在网站的持续性访问的轨迹信息用Flume进行数据采集，将处理后的数据导入到Hive仓库对应的库和表中，经过ETL分析处理，最终将处理的结果存到数据库中，进行报表展示。

负责工作：

• 用户使用浏览器访问页面产生埋点日志并发送至大数据服务器；

• 参与Hive数据仓库设计的讨论；

• ETL数据清洗；

该项目emmm完全是尚硅谷大数据的阉割版，也没理解透彻

面试细节：

1.数仓的输入数据源和输出数据源是什么？

本项目输入是前端埋点产生的用户行为数据（也可以是后端的业务数据，以及爬虫数据），输出系统是一个报表系统

2.Hadoop，Flume，Hive版本：

3.1.3，1.9.0，3.1.2

3.用户行为数据量：

要看活跃用户有多少，如果每天的活跃用户有100万，每人一天产生100条记录，每条日志1K，那么数据量有1亿K/1024/1024=100G，也就是一天100G的数据。存入数据仓库的时候，每层进行压缩，70G，存储3分副本210G，一年内不扩容，210G*365=74T，预留一些空间：105T

4.OLTP和OLAP

当今的数据处理可以分为两大类：联机事务处理和联机分析处理

OLTP：on-line transaction processing，联机事务处理，是传统的关系型数据库的主要应用，主要是业务数据，比如银行交易。需要考虑高并发、考虑事务（感觉面向关系型数据库，组织数据的模型是关系建模）

OLAP：On-Line Analytical Processing，联机分析处理，重点主要是面向分析，会产生大量的查询，一般很少涉及增删改，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。（感觉面向数仓，组织数据的模型是纬度建模）

对比属性	OLTP	OLAP
读特性	每次查询只返回少量记录	对大量数据进行汇总
写特性	随机、低延时写入用户的输入	批量导入
使用场景	用户，JAVA EE项目	内部分析师，为决策提供支持
数据表征	最新数据状态	随时间变化的历史状态
数据规模	GB	TB到PB

5.数据仓库建模的意义

减少重复计算，快速查询所需要的数据

6.数据建模的方法和思想

6.1ER模型（关系建模）

实体关系模型。遵循第三范式。ER图可以帮助解释数据库的逻辑结构。有三个成分：实体，属性、关系。

表较为松散，零碎，物理表数量多，但是数据冗余少。因为数据分布于较多的表中，这些数据可以更为灵活的被应用，功能性较强。但是数据查询要join，比较慢。不太适用于Hadoop体系，因为要join就要shuffle，shuffle开销大

6.2纬度建模

优点

1）表的数量比较少，关系比较简单，模型比较好理解，以业务为驱动

2）查询的时候也会join但是不会join过多，没有过多的shuffle，查询性能更好

3）更适合做数据分析

中间表叫做事实表，外边的一圈叫做维度表。纬度表存的都是事实表的一些描述信息（存储的是分析数据的角度（纬度），比如用户、商品、日期、地区等）

星形模型（事实表周围一级纬度）、雪花模型（事实表周围多级维度）、星座（多个事实表）

雪花模型和星型模型的主要区别

主要区别在于维度的层级，标准的星型模型纬度只有一层，而雪花模型可能会涉及多级

雪花模型，比较靠近3NF，但是无法完全遵守，因为遵循3NF的性能成本太高

星座模型

星座模型和另外两种情况的区别是事实表的数量，星座模型是基于多个事实表，多个事实表有一些共享的维度。很多数据仓库的常态就是星座模型

模型的选择

星座不星座只跟数据和需求相关，跟设计没关系，不用选择

星型还是雪花，取决于性能优先还是灵活优先

一般的企业开发，不会绝对选择一种，根据情况灵活组合，甚至并存（一层纬度和多层纬度都保存），但是从整体来看，在Hadoop体系更倾向于纬度更少的星型模型。减少join就是减少shuffle，性能差距很大

7.什么是事实表和维度表

事实表

事实表也可以称作流水表，用来记录业务系统发生的事实行为数据。数据是实时产生和动态变化的 

每一个业务（下单、支付、评价等）都对应一个事实表，每个事实表中每一行数据都代表一个业务事件。

事实表当中主要有两类字段，第一种是纬度表外键，另一种就是度量值（可统计次数，个数，金额等的字段（具有可加性））

事实表的特征：

1）非常大（行数非常多）

2）内容相对窄：列数较少（主要是纬度表外键和度量值）

3）经常发生变化，每发生一个业务就会增加一条记录

事实表的分类：

事务性事实表：以业务事件为单位，每一行就是一个业务。一旦事务被提交，事实表数据被插入，数据就不再进行更改，其更新方式为增量更新。（只会新增，不会修改）。可以把支付业务做成事务性事实表，因为只能新增不能修改

周期性快照事实表：不会保留所有数据（事务性事实表保留所有数据），只会保留固定时间间隔的数据。比如加购物车业务，有加减商品，随时都有可能变化，但是我们更关心每天结束时这里面有多少商品，方便我们后期统计分析（全量表）

累积型快照事实表：累计快照事实表用于跟踪业务事实的变化。（新增及变化同步）

纬度表

纬度表是对是事实表的一种延伸。数据量较小，且相对静态

纬度表的特征：

1）纬度表的范围很宽（具有多个属性，列比较多，多是和关系模型比，不是和事实表比）

2）跟事实表相比，行数相对较少，通常小于<10万条（数据量比较小）

3）内容相对比较固定，表里的数据不会很频繁的变化

8.数仓的意义

汇聚企业所有的业务数据，让来自不同业务的数据发挥1+1>2的效果，给企业的商业决策提供专业的参考依据

9.项目用的建模工具是什么

EZDML

10.数据仓库分层

数据量从大到小：（越来越小的原因：做的是一个聚合运算）

ODS（Operation Data Store）原始数据层

        ODS层：原始数据层，存放原始数据，直接加载原始日志，数据，数据保持原貌不做处理（文件写入Hive，load操作）

DWD（Data Warehouse Detail）数据明细层

        重要的一层，是地基

        DWD层：对ODS层进行清洗（去除空值，脏数据，超过极限范围的数据）、脱敏等。对于业务数据和日志数据不同，业务数据都是结构化的好处理，此外业务数据需要数据仓库的建模，所谓建模就是明确要建哪些表，表里有哪些字段，表与表之间的关联，一般就是在ODS到DWD的时候进行建模，一般使用的思想是纬度建模，建模的过程中顺带进行数据清洗。而日志数据是非结构话的，需要多一步解析的步骤，解析为结构化的数据，解析的时候需要考虑解析为几张表，按照什么逻辑去解析，解析的SQL怎么写等等。

        脱敏：把敏感信息处理一下（比如个人信息），避免数据信息泄漏。处理方式：比如手机号，中间4位变成*

        最后的数据是明细数据，一行信息代表一次业务行为，例如一次下单。

DWS（Data Warehouse Service）服务数据层

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

DWT（Data Warehouse Topic）数据主题层

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

ADS（Application Data Store） 数据应用层

        为各种统计报表提供数据

11.数据仓库为什么要分层

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

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

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

12.数据集市（Data Market）和数据仓库的区别

数据集市是一种微型的数据仓库。是部门级别的。数仓是企业级别的。

数据集市有两种：独立性数据集市和依附性数据集市。区别在于依附型要有企业级数仓，独立型没有数仓

13.数仓命名规范

表命名，每一层缩写_表名，DWD层事实表：dwd_dim/fact_表名

脚本命名，数据源_to_目标_db/log.sh，用户行为脚本

表字段：数量类型bigint，金额类型decimal（16，2），16位有效数字，小数部分2位

字符串（名字，描述信息等）类型为string，主键外键类型位string，时间戳类型位bigint

14.三大范式

范式：规范化的模式。设计一张数据表的表结构，符合的标准级别，规范和要求。

采用范式，可以降低数据的冗余性（重复性）

为什么要降低数据的冗余性：之前磁盘很贵，减少磁盘存储，以前没有分布式，只能加磁盘，磁盘个数也有限制。此外，一次修改，需要修改多个表，很难保证数据的一致性

缺点：数据库的表会被拆开，表越来越多，获取数据的时候，需要用join拼接，会降低性能

分类：第一范式、第二范式、第三范式、BCNF（巴斯科德范式），第四范式，第五范式。必须在遵循第一范式之上才能遵循第二范式。一般到第三范式就够了，很多都不用三范式，因为现在存储问题不严重，而且要考虑查询性能。

 完全函数依赖：通过AB能得出C，但是单A或者单B得不出C，那么可以说C完全依赖于AB

部分函数依赖：通过AB能得出C，通过单A或者单B也能打出C，那么说C部分依赖于AB

传递函数依赖：y=f(x),z=g(y)。Z传递函数依赖于x

第一范式核心原则：属性（字段）不可切割。1NF是所有关系型数据库的最基本要求，在关系型数据库管理系统，比如SQL Server，Oracle，MySQL中创建数据表的时候，如果数据表的设计不符合这个最基本的要求，那么操作一定不能成功。也就是说，只要在RDBMS中已经存在的数据表，一定是符合1NF的。比如5台电脑不符合，可以分为数量：5，商品：电脑

第二范式核心原则：不能存在部分函数依赖。自变量：主键字段。因变量：非主键字段。每列和主键进行判断，存在部分函数依赖的进行拆开

第三范式核心原则：不能存在传递函数依赖。

15 数据仓库建模

ODS层

1）HDFS用户行为数据（日志表）

就是一张表（包含了多种类型的日志），要分区

表里的字段，一行就是一条完整的日志，没有切开，只有一个字段

2）HDFS业务数据（业务数据表）

业务表来自于关系型数据库，是结构化的。导过来哪些表就建几个表，字段一致。也要进行分区

DWD层（核心） 

DWD层需要纬度模型，一般采用星型模型，呈现的状态一般为星座模型

1）用户行为数据

要解析，按内容解析，分成五张表

2）业务数据

要维度建模，四步骤：选择业务过程、声明粒度、确认维度、确认事实

选择业务过程（确定有几个事实表）：

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

如果是中小公司，尽量把所有业务过程都选择

如果是大公司（1000多张表），选择和需求相关的业务线

声明粒度：  （确定一个事实表里的一行数据指代的是什么）

数据粒度指数据仓库的保存数据的细化程度或者综合程度的级别

声明粒度意味着精确定义事实表中的一行数据表示什么，应该尽可能选择最小粒度，以此来应各种各样的需求

典型的粒度声明如下：

订单事实表中一行数据表示的是一个订单中的一个商品项

支付事实表中一行数据表示的一个支付记录

确定维度：（确认哪些事实表和维度有关系）

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

确认事实：此处事实指的是业务中的度量值（次数、个数、件数、金额，可以累加），例如订单金额，下单次数等

业务总线矩阵：

DWS层和DWT层

统称为宽表层。会有重复计算，可以将所有指标都统一进行计算，并将结果保存在该宽表中

意义就是减少重复计算。

跟需求相关，以需求为驱动

需要建立哪些宽表：以维度为基准

宽表里面的字段：是站在不同维度的角度去看事实表，重点关注事实表聚合后的度量值

ADS层

对电商系统各大主题指标分别进行分析

为什么选择大数据专业：

发展前景好，随着科技的进步和发展，数据量会越来越大，如何存储海量数据，以及从海量数据中挖掘有用信息越来越重要。利用大数据技术可以为业务提供数据支持