很多刚开始学习大数据的同学还不知道数仓是什么？

数仓的资料很少，面试如何准备该部分？

数仓hc远多于数开hc？ 【是的】

很多同学offer上写的虽然是大数据开发工程师，其实仍然是数仓开发的岗位？ 【是的】

首先我们明确一下数据仓库是什么？

数据仓库是一个面向主题的（比如订单、商品、会员）、集成的（来自不同数据源的统一数据规范比如男女的取值，命名规范的统一，字段类型的统一）、非易失（一般不会进行删除和修改操作）且随时间变化（并不是数据会变，而是数据随着时间会不断增多）的数据集合，主要用于存储历史数据，然后通过分析整理进而提供数据支持和辅助决策。【面试问到，就这么回答，绝对满分答案】

接下来聊一下数仓面试如何准备呢？

主要是两方面内容，一个是理论，一个是实践

理论的话，大家可以看一下我接下来总结的面试题目，有时间的同学可以看看大数据之路这本书

实践的话，也就是需要准备一个数仓的项目，网上有很多，大家自行学习即可

数仓重点面试题目

共25道，*越多代表越重要

1.数据仓库是什么 ***

上面已经说过了~

2.数据仓库和数据库有什么区别 *

• 数据库中主要存放的是一些在线的数据，数据仓库中主要存放的是历史数据，并且存放的数据要比数据库多
• 数据库主要用于业务处理（比如交易系统），数据仓库主要用于数据分析
• 数据库的设计就是要避免冗余，而数据仓库通常会专门引入冗余，减少后面进行分析时大量的join操作

3.为什么要对数据仓库分层 ***

• 第一个是将复杂的需求简单化；我们通过将复杂的问题分解为多个步骤来完成，每一层只处理单一的步骤，比较容易和理解
• 第二个是提高数据的复用性；比如在已经得到最终结果之后，又需要中间层的一些数据，我可以直接查询中间层的数据，不必重新进行计算
• 补充说一下：我觉得数据仓库就是一种以空间换取时间的架构！

4.为什么需要数据建模 *

爆发式的数据增长，如何对数据进行有序、有结构地分类组织和存储是一大挑战。数据模型是数据存储和组织方法，它强调从业务、数据存取和使用角度合理存储数据。有了适合业务的数据模型之后，那么大数据就可以获得以下好处：性能、成本、效率、质量

5.经典的数据仓库建模方法论有哪些 ***

• ER模型是Inmon提出的，这个模型是符合3范式的，他的出发点就是整合数据，将各个系统中的数据以整个企业角度按主题进行分类，但是不能直接用于分析决策
• 维度模型是Kimball提出的，这个人和Inmon算是数仓的两个流派，他的出发点就是分析决策，为分析需求服务，而现在多数的数仓的搭建都是基于维度模型进行搭建的。
• 区别：ER模型冗余更少，但是在大规模数据跨表分析中，会造成多表关联，这会大大降低执行效率

6.数仓相关的名词术语解释，比如数据域、业务过程、衍生指标 *

• 数据域：将业务过程或者维度进行抽象的集合，例如交易域、商品域等都是数据域
• 业务过程：一个不可拆分的行为事件，例如下单、支付、退款等都是业务过程
• 维度：用于分析事实所需要的多样环境/角度，例如时间、地理等都是维度
• 维度属性：维度属性隶属于一个维度，例如地理维度中的国家名称、国家ID、省份名称等都是维度属性
• 原子指标：业务中定义的不可拆分的指标，用来度量某一行为事件，例如支付金额、下单数目等都是原子指标
• 派生指标：就是对原子指标统计范围的限定，形式为 一个原子指标+多个修饰词【可选】+时间周期，例如最近一天通过花呗支付的金额（原子指标：支付金额，修饰词：花呗支付，时间周期：最近一天）

7.派生指标的种类 *

• 事务型指标：对业务活动进行衡量的指标。例如订单支付金额、新发商品数、新增注册会员数
• 存量型指标：对实体对象（比如商品、会员）某些状态的统计。例如商品总数、会员总数等，这类指标需维护原子指标及修饰词，在此基础上创建衍生指标，对应的时间周期一般为"截止当前某个时间"
• 复合型指标：在事务型指标和存量型指标的基础上复合而成的。通常为比率型或者比例型，例如UV-下单买家数转化率，最近一天无线支付金额占比等

8.经典数仓分层架构 ***

• 操作数据层（ODS）：把业务系统、日志等数据几乎无处理地同步到ODS层中
• 公共维度模型层（CDM）：存放明细事实数据、维表数据及公共指标汇总数据，其中明细事实数据和维表数据一般由ODS加工生成；公共指标汇总数据一般根据明细事实数据和维表数据加工生成明细数据层（DWD）汇总数据层（DWS）
• 应用数据层（ADS）：存放个性化的统计指标数据，一般根据ODS和CDM加工生成

9.模型设计的基本原则 *

• 高内聚和低耦合：将业务相关、粒度相同的数据设计为同一个物理模型，将高频率同时访问的数据放一起，将低频率同时访问的数据分开存储
• 核心模型与扩展模型分离：核心模型包括的字段支持常用的核心业务，扩展模型包括的字段支持个性化或少量应用的需要
• 公共处理逻辑下沉：越是公用的处理逻辑，越应该在数据调度依赖的底层进行封装与实现，不要让公共逻辑多处同时存在
• 成本与性能平衡：适当的数据冗余可以换取查询和刷新性能，但不要过度冗余
• 数据可回滚：处理逻辑不变，在不同时间多次运行，数据结果确定不变
• 一致性：具有相同含义的字段在不同的表中命名必须相同
• 命名清晰可理解：表名需易于消费者理解和使用

10.模型实施的具体步骤 **

1. 数据调研业务调研：以阿里为例，整个阿里集团涉及的领域包括电商、导航、本地生活等领域。各个领域又包括多条业务线，比如电商包括了 淘宝、天猫、天猫国际等。那么是各个业务领域单独建设数仓还是一起建设数仓仍然是一个问题，在阿里，一般各个业务领域单独建设数仓，因为业务领域内的业务线由于业务相似、业务相关性较大，可进行统一集中建设需求调研：通常包括两种途径，一是根据与分析师、业务运营人员沟通获知需求；二是对报表系统中的现有报表进行分析。比如说，分析师需要了解 大淘宝一级类目的成交金额。当获知这个需求后，我们需要分析根据什么汇总（维度），以及汇总什么（度量），这里类目是维度，成交金额是度量；明细数据和汇总数据应该怎么设计？这是一个公用的报表吗？是需要沉淀到汇总表里面，还是在报表工具中进行汇总？
2. 架构设计数据域划分：数据域需要抽象提炼，并且长期维护和更新，但不经常变动。在划分数据域的时候，既能涵盖当前所有的业务需求，又能在新业务进入的时候无影响地被包含进已有的数据域中或者扩展新的数据域。比如会员域、商品域、店铺域、日志域、交易域等构建总线矩阵：需要做两件事情，一是明确每个数据域下有哪些业务过程，二是确定业务过程与哪些维度相关。
3. 规范定义：定义指标体系，包括原子指标和派生指标
4. 模型设计：包括明细事实表、维度表以及汇总事实表的模型设计
5. 代码开发
6. 部署运维

11.维度建模有哪几种模型 ***

• 星型模型：这是最常用的维度建模的方式，核心就是 以事实表为中心，所有的维度表直接连接在事实表上，就和星星一样，所以叫做星型模型
• 雪花模型：这是星型模型衍生而来的，相对于它不同的是 维度表可以再连接其他维度表，有点类似于3NF模型
• 星座模型：这也是星型模型的衍生而来的，相对于它不同的是 基于多张事实表，并且共享维度信息，也就是维度表之间可能会连在一起。一般来说，企业中不会只有一张事实表，所以大多数情况下都是星座模型进行维度建模的。

12.维度建模中表的类型 **

• 维度表：一张维度表就表示对一个对象的一些描述信息。每个维度表都包含单一的主键列，和一些对该主键的描述信息，通常维度表会很宽。比如 乘客信息表，司机信息表，城市首都表
• 事实表：一张事实表就表示对业务过程的描述，比如播单，下单，支付。每个事实表都包含若干维度外键，若干退化维度（维度属性存储到事实表中，减少关联），和数值型的度量值，通常事实表会比较大。

13.维度表的设计过程 *

以淘宝的商品维度为例来对维度设计方法进行详细说明

第一步：选择维度。作为维度建模的核心，在企业级数仓中必须保证维度的唯一性。即为商品维度

第二步：确定主维表。一般是ODS表，直接与业务系统同步。以淘宝商品维度为例，s_auction_auctions是与前台商品中心系统同步的商品表，即为主维表

第三步：确定相关维表。数据仓库是业务源系统的数据整合，不同业务系统或者同一业务系统中的表之间存在关联性。根据对业务的梳理，确定哪些表与主维表相关联。以淘宝商品维度为例，与类目、SPU、卖家、店铺等维度存在关联

第四步：确定维度属性。包括两个步骤，一是从主维表中选择维度属性或者生成新的维度属性，二是从相关维表中选择维度属性或者生成新的维度属性

14.维度表的设计中有哪些值得注意的地方 *

• 尽可能生成丰富的维度属性
• 尽可能详细的对维度属性进行文字解释
• 区分数值型属性和事实数值型字段是作为事实还是维度属性，可以参考字段的一般用途。如果通常用于查询约束条件或者分组统计，则是作为维度属性；如果通常用于参与度量的计算，则是作为事实。
• 尽量沉淀通用的维度属性例如，淘宝商品中的property字段，使用k:v存储了多个商品属性。商品品牌就存放在该字段中，而商品品牌是重要的分组统计和查询约束的条件，所以需要将该字段解析出来例如，商品是否在线，是重要的查询约束条件，但是无法直接获取，需要进行加工，所以需要封装商品是否在线的逻辑作为一个单独的属性字段

15.维度规范化和反规范化如何理解 *

• 对于淘系商品维度，如果采用雪花模式进行规范化处理，如下图所示

• 将维度的属性层次合并到单个维度中的操作称为反规范化，如下图所示

• 采用规范化处理，虽然可以节约一部分存储，但是在分析查询的过程中会产生大量的join操作，性能较差。所以在OLAP系统中，通常会进行反规范化，用空间来换取查询性能。

16.维表整合的两种表现形式 *

1. 垂直整合：不同的来源表包含相同的数据集，只是存储的信息不同。比如淘宝会员在源系统中有多张表，如会员基础信息表、会员扩展信息表、淘宝会员等级信息表等，这些表都属于会员信息表，依据维度设计方法，尽量整合至会员维度模型中，丰富其维度属性
2. 水平整合：不同的来源表包含不同的数据集。比如针对蚂蚁集团的数据仓库，其采集的会员数据有 淘宝会员、1688会员、支付宝会员等，是否需要考虑将所有的会员整合到一个会员表中？如果进行整合，首先需要考虑各个会员体系是否有交叉，如果有交叉，则需要去重；如果不存在交叉，则需要考虑不同子集的自然键是否存在冲突，如果不冲突，则可以考虑将各子集的自然键作为整合后表的自然键；另一种方式是 设置超自然键，将来源表各子集的自然键加工成一个字段作为超自然键

17.如何处理维度的变化 ***

背景：在现实世界中，维度的属性并不是静态的，它会随着时间的流逝发生缓慢的变化，与数据增长较为快速的事实表相比，维度变化相对缓慢，所以将这类维度叫做缓慢变化维

处理缓慢变化维的方式：

1. 重写维度值。无法保留历史数据

1. 插入新的维度行。虽然能够保留历史数据，但是 不能将变化前后记录的事实归一化为变化前的维度或者变化后的维度。比如根据业务需求，需要将11月份的交易额全部统计到类目2上，该方式无法实现。

1. 添加维度列。保留历史数据

1. 快照维表。每天保存一份全量快照数据。优点：简单有效，开发和维护成本低；使用方便，理解性好，数据使用方只需要限定日期，即可获取到当天的快照数据。任意一天的事实快照和维度快照通过维度的自然键进行关联即可。缺点：存储的浪费。比如某维度，每天的变化量占总体数据量比例很低，甚至无变化，那么全量保存就非常浪费存储空间
2. 拉链表。通过新增两个时间戳字段（start_dt和end_dt），将所有以天为粒度的变更数据记录下来。背景：2016年1月1日，卖家A在淘宝网发布了B、C两个商品，1月2日，卖家A在淘宝网下架了商品B，同时又发布了商品D快照维表：dt是分区字段拉链表：对于不变的数据，不再重复存储例如，用户访问1月2日的数据，只需要限制start_dt<=20160102和end_dt>20160102即可缺点：理解性较差；存储方式用start_dt和end_dt做分区，随着时间的推移，分区数量会极度膨胀，而现行的数据库系统对分区都有所限制。为了解决上述两个问题，阿里巴巴提出采用极限存储的方式来进行处理透明化：底层的数据还是历史拉链存储，但是上层做一个视图操作或者在Hive里做一个hook。这样对于下游用户来说，极限存储表和全量存储表的访问方式是一样的分月做历史拉链表假设用start_dt和end_dt做分区，并且不做限制，那么可以计算出一年历史拉链表最多可能产生的分区数是：365*364/2=66430；如果每个月月初重新开始做历史拉链表，那么可以计算出一年历史拉链表最多可能产生的分区数是：12*(1+30*29/2)=5232采用极限存储的存储方式，极大地压缩了全量存储的成本，又可以达到对下游用户透明的效果，是一种比较理想的存储方式为什么企业中很少使用这种方式呢？产出效率很低，通常需要t-2对于变化频率高的数据并不能达到节约成本的效果

18.事实表设计的八大原则 *

1. 尽可能包含所有与业务过程相关的事实
2. 只选择与业务过程相关的事实
3. 分解不可加事实为可加事实
4. 在选择维度和事实之前必须先声明粒度
5. 在同一个事实表中不能有不同粒度的事实
6. 事实的单位要保持一致
7. 对事实的null值要处理
8. 使用退化维度提高事实表的易用性

19.事实表的设计过程 ***

第一步：选择业务过程以及确定事实表类型

业务过程通常使用行为动词表示业务执行的活动，比如图11.1中淘宝交易订单流转的业务过程有四个：创建订单、买家付款、卖家发货、卖家确认收货。在明确了流程所包含的业务过程之后，需要根据具体的业务需求来选择与维度建模有关的业务过程。

在选择了业务过程以后，相应的事实表类型也随之确定了。比如选择买家付款这个业务过程，那么事实表为 只包含买家付款这一业务过程的单事务事实表；如果选择的是所有四个业务过程，并且需要分析各个业务过程之间的时间间隔，那么事实表为 包含四个业务过程的累计快照事实表。

第二步：声明粒度

明确的粒度能确保对事实表中行的意思的理解不会产生混淆，保证所有的事实按照同样的细节层次记录。

应该尽量选择最细级别的原子粒度，以确保事实表的应用具有最大的灵活性。

第三步：确定维度

完成粒度声明以后，也就意味着确定了主键，对应的维度组合以及相关的维度字段就可以确定了，应该选择能够描述清楚业务过程所处的环境的维度信息。比如在淘宝订单付款事务事实表中，粒度为子订单，相关的维度有 买家、卖家、商品、收货人信息、业务类型、订单时间等

第四步：确定事实

事实可以通过回答"过程的度量是什么"来确定。比如在淘宝订单付款事务事实表中，同粒度的事实有 子订单分摊的支付金额、邮费、优惠金额等

第五步：冗余维度

在传统的维度建模的星型模型中，对维度的处理是需要单独存放在专门的维表中的，通过事实表外键获取维度。这样做的目的是为了减少冗余，从而减少存储消耗。而在大数据的事实表模型设计中，考虑更多的是下游用户的使用效率，降低数据获取的复杂性，减少关联的表数量。所以通常会在事实表中冗余下游用户经常使用的维度。比如在淘宝订单付款事实表中，通常冗余的大量常用维度字段有 商品类目、卖家店铺等

20.事实表有哪几种类型 ***

• 事务事实表：用来描述业务过程，跟踪空间或时间上某点的度量事件，保存的是最原子的数据
• 周期快照事实表：以具有规律性的、可预见的时间间隔记录事实，时间间隔如每天、每月、每年等。当需要一些状态变量时，比如账户金额、买卖家星级、商品库存、卖家累计交易额等，则需要聚集与之相关的事务才能进行识别计算，往往和事务事实表成对出现。
• 累计快照事实表：用来表述过程开始和结束之间的关键步骤事件，覆盖过程的整个生命周期，通常有多个日期字段来记录关键时间点，当过程随着生命周期不断变化时，记录也会随着过程的变化而修改

21.多事务事实表如何对事实进行处理 *

主要有两种方法对事实进行处理

1. 不同业务过程的事实使用不同的事实字段进行存放。比如淘宝交易事务事实表，表中会设置 下单度量，支付度量，完结度量等字段。
2. 不同业务过程的事实使用同一个事实字段进行存放，但增加一个业务过程标签。比如收藏事务事实表，表中会设置 收藏删除类型，以及收藏删除度量等字段。

关于上述两种方法如何选择呢？

• 当不同业务过程的度量比较相似时，采用第二种方式；反之，当不同业务过程的度量差异比较大时，采用第一种方式

22.单事务事实表和多事务事实表哪种设计更好 **

主要从五个方面来进行分析

• 业务过程对于单事务事实表，一个业务过程建议一张事实表，只反映一个业务过程的事实；对于多事务事实表，在同一个事实表中反映多个业务过程的事实。多个业务过程是否放到同一张事实表中，首先需要分析不同业务过程之间的相似性。
• 粒度和维度在确定好业务过程后，需要基于不同的业务过程确定粒度和维度，当不同业务过程的粒度相同，同时拥有相似的维度时，此时就可以考虑采用多事务事实表。如果粒度不同，则必定是不同的事实表。比如交易中 支付和发货有不同的粒度，则无法将发货业务过程放到淘宝交易事务事实表中
• 事实如果单一业务过程的事实较多，同时不同业务过程的事实又不相同，则可以考虑单事务事实表，处理更加清晰；若使用多事务事实表，则会导致事实表零值或空值较多
• 下游业务使用单事务事实表对于下游用户更容易理解，关注哪个业务过程就使用哪张事实表；而多事务事实表包含多个业务过程，用户使用往往较为困惑。
• 计算存储成本当业务过程数据来源于同一个业务系统，具有相同的粒度和维度，且维度较多而事实不多时，此时可以考虑多事务事实表，不仅其加工计算成本较低，同时在存储上也相对节省

23.周期快照事实表的设计过程 *

第一步，确定粒度。采样周期为每天，针对卖家、买家、商品、类目 、地区等维度的快照事实表 ，比如淘宝卖家历史至今汇总事实表、淘宝商品自然月至今汇总事实，不同的采样粒度确定了不同的快照事实表。

第二步，确定状态度量。确定好粒度以后，就要针对这个粒度确定需要采样的状态度量。比如淘宝卖家历史至今汇总事实表，包含了历史截至当日的下单金额、历史截至当日的支付金额等度量

24.累计快照事实表的设计过程 *

第一步，选择业务过程。淘宝交易订单的流转主要包括 下单，支付，发货，完成这四个业务过程，在事务统计中，只关注了下单、支付、完成这三个业务过程，而在统计事件时间间隔的需求中，卖家发货也是关键环节。所以在针对淘宝交易累计快照事实表，我们选择这四个业务过程

第二步，确定粒度。子订单在此表中只记录一行，事件发生时，对此实例进行更新

第三步，确定维度。与事务事实表相同，维度主要有买家、卖家、店铺、商品、类目、地区等。四个业务过程对应的时间字段，分别为下单时间、支付事件、发货时间、确认收货时间。

第四步，确定事实。对于累计快照事实表，需要将各个业务过程的事实均放入事实表中。比如淘宝交易累计快照事实表，包含了各业务过程对应的事实，如下单金额、支付对应的折扣、邮费和支付金额、确认收货对应的金额等。累计快照事实表解决的最重要的问题是 统计不同业务过程之间的时间间隔，建议将每个过程的时间间隔作为事实放在事实表中。

第五步，退化维度。与事务事实表相同。

25.累计快照事实表的特点

1. 数据不断更新事务事实表记录事务发生时的状态，对于实体的某一实例不再更新；而累积快照事实表则对实体的某一实例定期更新。
2. 多业务过程日期累计快照事实表适用于具有明确起止时间的短生命周期的实体，比如交易订单、物流订单等，对于实体的每一个实例，都会经历从诞生到消亡等一系列步骤。对于商品、用户等具有长生命周期的实体，一般采用周期快照事实表更合适累计快照事实表的典型特征就是多业务过程日期，用于计算业务过程之间的时间间隔。还有一个重要作用是保存全量数据。

以上就是第一季的全部内容，接下来第二季会和大家分享 如何对数仓进行计存优化以及众多大厂真实数仓架构等

推荐阅读

我的大数据开发学习之路 https://www.nowcoder.com/discuss/472719451583016960

大数据开发面试重点 https://www.nowcoder.com/discuss/465452981165588480