不积跬步无以至千里，不积小流无以成江海，大数据高频面试题——数据仓库篇（一）
本期与大家分享的是，小北用心整理的与
数据仓库相关的常见的面试题，希望对大家能有帮助，大家喜欢就给点鼓励吧，欢迎各位大佬评论区指教讨论！???制作不易，各位大佬们给点鼓励！
???点赞? ➕ 收藏⭐ ➕ 关注✅
???欢迎各位大佬指教，一键三连走起！
1.数据仓库为什么要分层？
作为一名数据的规划者，我们肯定希望自己的数据能够有秩序地流转，数据的整个生命周期能够清晰明确被设计者和使用者感知到。直观来讲就是如下的左图这般层次清晰、报表依赖关系直观。
但是，大多数情况下，我们完成的数据体系却是依赖复杂、层级混乱的。如下的右图，在不知不觉的情况下，我们可能会做出一套表依赖结构混乱，甚至出现循环依赖的数据体系。
因此，我们需要一套行之有效的数据组织和管理方法来让我们的数据体系更有序，这就是谈到的数据分层。数据分层并不能解决所有的数据问题，但是，数据分层却可以给我们带来如下的好处：
-
清晰数据结构：每一个数据分层都有它的作用域和职责，在使用表的时候能更方便地定位和理解
-
减少重复开发：规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算
-
统一数据口径：通过数据分层，提供统一的数据出口，统一对外输出的数据口径
-
复杂问题简单化：将一个复杂的任务分解成多个步骤来完成，每一层解决特定的问题
2. 如何对数据仓库进行分层，每一层都做了什么
ODS（Operational Data Store）：数据运营层
“面向主题的”数据运营层，也叫ODS层，是最接近数据源中数据的一层，数据源中的数据，经过抽取、洗净、传输，也就说传说中的 ETL 之后，装入本层。本层的数据，总体上大多是按照源头业务系统的分类方式而分类的。
一般来讲，为了考虑后续可能需要追溯数据问题，因此对于这一层就不建议做过多的数据清洗工作，原封不动地接入原始数据即可，至于数据的去噪、去重、异常值处理等过程可以放在后面的DWD层来做。
DW（Data Warehouse）：数据仓库层
数据仓库层是我们在做数据仓库时要核心设计的一层，在这里，从 ODS 层中获得的数据按照主题建立各种数据模型。DW层又细分为 DWD（Data Warehouse Detail）层、DWM（Data WareHouse Middle）层和DWS（Data Warehouse Service）层。
该层一般保持和ODS层一样的数据粒度，并且提供一定的数据质量保证。同时，为了提高数据明细层的易用性，该层会采用一些维度退化手法，将维度退化至事实表中，减少事实表和维表的关联。
另外，在该层也会做一部分的数据聚合，将相同主题的数据汇集到一张表中，提高数据的可用性。
该层会在DWD层的数据基础上，对数据做轻度的聚合操作，生成一系列的中间表，提升公共指标的复用性，减少重复加工。直观来讲，就是对通用的核心维度进行聚合操作，算出相应的统计指标。
又称数据集市或宽表。按照业务划分，如流量、订单、用户等，生成字段比较多的宽表，用于提供后续的业务查询，OLAP分析，数据分发等。
一般来讲，该层的数据表会相对比较少，一张表会涵盖比较多的业务内容，由于其字段较多，因此一般也会称该层的表为宽表。在实际计算中，如果直接从DWD或者ODS计算出宽表的统计指标，会存在计算量太大并且维度太少的问题，因此一般的做法是，在DWM层先计算出多个小的中间表，然后再拼接成一张DWS的宽表。由于宽和窄的界限不易界定，也可以去掉DWM这一层，只留DWS层，将所有的数据在放在DWS亦可。
ADS/APP/DM（Application Data Store/Application/DataMarket）：数据应用层/数据集市
在这里，主要是提供给数据产品和数据分析使用的数据，一般会存放在 ES、PostgreSql、Redis等系统中供线上系统使用，也可能会存在 Hive 或者 Druid 中供数据分析和数据挖掘使用。比如我们经常说的报表数据，一般就放在这里。
DIM（Dimension）:维表层
维表层主要包含两部分数据：
-
高基数维度数据：一般是用户资料表、商品资料表类似的资料表。数据量可能是千万级或者上亿级别。
-
低基数维度数据：一般是配置表，比如枚举值对应的中文含义，或者日期维表。数据量可能是个位数或者几千几万。
3.关系建模和维度建模的区别？
-
关系模型严格遵循第三范式（3NF），比较松散零碎，物理表数量众多但数据冗余程度低。由于数据分布于众多的表中，这些数据可以更为灵活地被使用，功能性较强。主要应用于OLTP系统中，保证数据的一致性以及避免冗余，所以大部分业务系统的表都遵循第三范式。
-
维度模型主要应用于OLAP系统中，通常以某一个事实表为中心进行表的组织，主要是面向业务，特征是可能存在数据的冗余，但是能很方便的得到数据。
-
关系模型虽然冗余少，但是在大规模数据，跨表分析统计查询过程中，会造成多表关联，这会大大降低执行效率。所以通常采用维度模型建模，把相关各种表整理成两种：事实表和维度表。
4.维度建模的步骤是什么
- 选择业务过程
- 业务过程是组织完成的操作型活动。业务过程事件建立或获取性能度量，并转换为事实表中的事实。过程定义了特定的设计目标以及对粒度，维度，事实的定义。每个业务过程对应企业数据仓库总线矩阵的一行。
- 声明粒度
- 在选择维度或事实前必须声明粒度，因为每个候选维度或事实必须与定义的粒度保持一致。在所有维度设计中强制实行一致性是保证BI应用性能和易用性的关键。在从给定的业务过程中获取数据时，原子粒度是最低级别的粒度。最好从原子级别粒度开始设计，因为原子粒度能够承受无法预期的用户查询。针对不同的事实表粒度，要建立不同的物理表，在同一事实表中尽量不要混用多种不同的粒度。
- 确认环境的维度
- 维度围绕某一业务过程事件所涉及的什么人、什么事、什么地点、什么时间、为什么、如何等背景。
- 确认用于度量的事实
- 事实设计来自业务过程事件的度量，基本上都是以数量值表示。个数、件数、金额等等。
5. 数据库与数据仓库的区别（OLTP与OLAP的区别）
当今的数据处理大致可以分成两大类：联机事务处理OLTP（on-linetransaction processing）、联机分析处理OLAP（On-Line Analytical Processing；OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理。OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。二者的主要区别对比如下表所示。
| 对比属性 | OLAP | OLTP |
|---|---|---|
| 读属性 | 对大量记录进行汇总 | 每次查询只返回少量记录 |
| 写属性 | 批量导入 | 随机，低延时写入用户的输入 |
| 数据表征 | 随时间变化的历史状态 | 最新数据状态 |
| 数据规模 | TB 到 PB | GB |
| 使用场景 | 内部分析师，为决策提供支持 | 用户，Java EE 项目 |
6.什么是维度表，有什么特征 ？
-
维度表：事实表中某个方向分支，必须有主键，用于关联事实表。一般数据量较小，变化缓慢。
-
维度表的特征：
维度表的范围很宽（具有多个属性、列比较多）；跟事实表相比，行数较少，（通常小于10万条）；内容相对固定。
7.什么是事实表 ，有什么特征？什么是事实？事实表可分为几种？
- 事实表：事实表是用来存储主题的主干内容，一些外键指向维度表。事实表一般是没有主键的，基本都是外键。数据的质量完全由业务系统来把握。一般单表字段较多，数据量比较大
- “事实”表示的是业务事件的度量值（可以统计次数、个数、金额等），例如订单事件中的支付金额。每一个事实表的行包括：具有可加性的数值型的度量值、与维度表相连接的外键、通常具有两个及以上外键。
- 事实表的特征：
非常的大；内容相对的窄；经常发生变化，每天新增很多。 - 事实表分类：
- 1）事务型事实表：
以每个事务或事件为单位，例如一笔支付记录等，作为事实表里的一行数据。一旦事务被提交，事实表数据被插入，数据就不再进行更改，其更新方式为增量更新。 - 2）周期型快照事实表：
周期型快照事实表中不会保留所有数据，只保留固定时间间隔的数据，以具有规律性的、可预见的时间间隔记录事实。例如每天或每月的总销售金额，或每月的账户余额等。 - 3）累积型快照事实表:
累积快照事实表用于跟踪业务事实的变化，覆盖过程的整个生命周期，通常具有多个日期字段来记录关键时间点。例如数据仓库中可能需要累积或者存储订单从下单开始，到订单商品被打包、运输、签收等各个业务阶段的时间点数据，来跟踪订单生命周期的进展情况。当这个业务过程进行时，事实表的记录也要不断更新。
- 1）事务型事实表：
8.什么是宽表？拉链表？
- 宽表：字段和数据量比较巨大，很多维度杂糅在一起。好处：方便查询分析。缺点：没有规范。
- 拉链表：记录一个事物从开始，一直到当前状态的所有变化的信息。
9.数据仓库建模的几种方式 ？
范式建模，雪花模型，星型建模，事实星座模型.
链接：解析几种数仓建模方式
10.数仓建设的理论（哪两种）
Kimball和Inmon是两种主流的数据仓库理论，分别由 Ralph Kimbal和 Bill Inmon 提出，在实际数据仓库建设中，业界往往会相互借鉴使用两种开发模式。
Kimball
模式从流程上看是是自底向上的，即从数据集市到数据仓库再到数据源(先有数据集市再有数据仓库)的一种敏捷开发理论方法。对于Kimball模式，数据源往往是给定的若干个数据库表，数据较为稳定但是数据之间的关联关系比较复杂，需要从这些OLTP中产生的事务型数据结构抽取出分析型数据结构，再放入数据集市中方便下一步的BI与决策支持。通常，Kimball都是以最终任务为导向。首先，在得到数据后需要先做数据的探索，尝试将数据按照目标先拆分出不同的表需求。其次，在明确数据依赖后将各个任务再通过ETL由Stage层转化到DM层。这里DM层数据则由若干个事实表和维度表组成。接着，在完成DM层的事实表维度表拆分后，数据集市一方面可以直接向BI环节输出数据了，另一方面可以先DW层输出数据，方便后续的多维分。Kimball往往意味着快速交付、敏捷迭代，不会对数据仓库架构做过多复杂的设计，在变换莫测的互联网行业，这种架构方式逐渐成为一种主流范式。
Inmon
模式从流程上看是自顶向下的，即从数据源到数据仓库再到数据集市的（先有数据仓库再有数据市场）一种瀑布流开发方法。对于Inmon模式，数据源往往是异构的，比如从自行定义的爬虫数据就是较为典型的一种，数据源是根据最终目标自行定制的。这里主要的数据处理工作集中在对异构数据的清洗，包括数据类型检验，数据值范围检验以及其他一些复杂规则。在这种场景下，数据无法从stage层直接输出到dm层，必须先通过ETL将数据的格式清洗后放入dw层，再从dw层选择需要的数据组合输出到dm层。在Inmon模式中，并不强调事实表和维度表的概念，因为数据源变化的可能性较大，需要更加强调数据的清洗工作，从中抽取实体-关系。通常，Inmon都是以数据源头为导向。首先，需要探索性地去获取尽量符合预期的数据，尝试将数据按照预期划分为不同的表需求。其次，明确数据的清洗规则后将各个任务通过ETL由Stage层转化到DW层，这里DW层通常涉及到较多的UDF开发，将数据抽象为实体-关系模型。接着，在完成DW的数据治理之后，可以将数据输出到数据集市中做基本的数据组合。最后，将数据集市中的数据输出到BI系统中去辅助具体业务。