数据仓库工程师面试题目（不定期更新）

1 缓慢变化维的设计？（真心常问，标准答案必备）

三种：直接覆盖，增加新行，增加心属性列
Type 1:覆盖：直接用新值代替旧值。
Type 2:增加新行。将当前行的状态设置为off，并设置一个endtime时间戳，将当前时间标记上。
同时新增1行，将其状态标记为on，设置begintime时间戳为上一个记录的endtime+1。
Type 3:增加新列：给表增加一个新列，来存储新值，同时保留原来的值不变。

2 拉链表使用场景和实现方式？

【yy总结】
拉链表使用场景：需要查看历史某一时间节点的状态，同时考虑到存储空间。
实现方式：
首先是拉链表dw_order_his的设置，有start_date和end_date两个字段；
其次在ods层创建一个ods_order_update表，储存当变化数据（包括insert和update的数据）
源表（order）
ods_order_update表和dw_order_his表的交集进行封链操作，end_date=current_date
ods_oder_update数据插入到his表中，对于记录的end_date=9999-12-31,start_date=current_date

【使用场景】
在数据仓库的数据模型设计过程中，经常会遇到下面这种表的设计：
 有一些表的数据量很大，比如一张用户表，大约10亿条记录，50个字段，这种表，即使使用ORC压缩，单张表的存储也会超过100G，在HDFS使用双备份或者三备份的话就更大一些。
 表中的部分字段会被update更新操作，如用户联系方式，产品的描述信息，订单的状态等等。
 需要查看某一个时间点或者时间段的历史快照信息，比如，查看某一个订单在历史某一个时间点的状态。
 表中的记录变化的比例和频率不是很大，比如，总共有10亿的用户，每天新增和发生变化的有200万左右，变化的比例占的很小。

【实现方式】
全量主要数据表加载的策略为每次加载时需要根据主键将目标表的数据与源表数据进行比对，删除目标表中在源数据表中的相关记录，然后将源表数据全部插入目标表。表现在脚本上为先delete相关记录，然后insert所有记录。主表加载策略主要用于大部分主表的加载，比如客户信息等主要数据表。
增量拉链是指每次加载时，将源表数据视为增量抽取后的结果，加载到目标表时需要考虑数据历史情况。一般数据发生变化时关闭旧数据链，然后开新数据链。增量拉链针对的是历史表情况，由于数据仓库中记录了大部分数据历史表变化情况，因此增量拉链加载策略在数据仓库中是使用比较广泛的一种加载策略。通常这种历史表都含有start_date和end_date字段，首先全字段对比源数据和目标表得出真正的增量数据，这里的全字段不包含start_date和end_date字段，然后根据主键对目标表进行关旧链操作，然后对新增数据开新链，这种拉链策略同样可以处理全量数据。

3 拉链表性能优化

拉链表当然也会遇到查询性能的问题，比如说我们存放了5年的拉链数据，那么这张表势必会比较大，当查询的时候性能就比较低了，个人认为两个思路来解决：

1. 在一些查询引擎中，我们对start_date和end_date做索引，这样能提高不少性能。
2. 保留部分历史数据，比如说我们一张表里面存放全量的拉链表数据，然后再对外暴露一张只提供近3个月数据的拉链表。

4 星型模型和雪花模型区别

星形模型(Star Schema):
Ø 事实被维度所包围，且维度没有被新的表连接
Ø 星形模型是一个比较折中的的建模方式(BIAPPS中都是用的是星形的建模方式)
雪花模型(Snowflake Schema):
} 事实表被多个维表或一个或多个层次所包围
} 雪花模型一般在处理大的且相对静态的层次的时候使用
根据事实表和维度表的关系，又可将常见的模型分为星型模型和雪花型模型。
　　星形模型：当所有维度表连接到事实表上的时候，整个图就像一个星星，故称之为星型模型。星型架构是一种非正规化的结构，多维数据集的每一个维度都直接与事实表相连，不存在渐变维度，所以数据有一定冗余。因为有冗余，所以很多统计不需要做外部的关联查询，因此一般情况下效率比雪花模型高。
　　雪花模型：当有多个维度表没有直接连接到事实表上，而是通过其他维度表连接到事实表上时，其图形就像雪花，故称雪花模型。雪花模型的优点是减少了数据冗余，所以一般情况下查询需要关联其他表。在冗余可接受的前提下使用星型模型。
星型模型和雪花模型的区别在于：维度表是直接连接到事实表还是其他维度表。

5 简述数据仓库中的表的基本类型，以及为了保证引用完整性该以什么样的顺序对它们进行加载。

答：数据仓库中的表的基本类型有维度表、事实表、子维度表、桥接表等几类。其中子维度表即雪花模型由支架维度技术处理，桥接表用来处理多值维度或层级结构。

数据仓库中需要加载的各类表之间有相互依赖的关系，所以加载时需要以一定的顺序进行加载。下面是一些加载的基本原则：
子维度表加载成功后，再加载维度表。
维度表加载成功后，再加载桥接表。
子维度表、维度表和桥接表都加载成功后，再加载事实表。
这个加载顺序可以通过主外键的关系来确定。（注意，此回答为总线架构的数据仓库的表的加载顺序。）

6 事实表和维度表的概念及类型

6.1 事实表的概念

Ø 每个数据仓库都包含一个或者多个事实数据表。
Ø 事实数据表可能包含业务销售数据，如现金登记事务所产生的数据，事实数据表通常包含大量的行
Ø 一般事实表中只存放数字或者一些Flag用来统计(Count)，如收益、数量、支出等

6.2 事实的类型

} 粒度事实表(Additive Fact)
} 周期快照事实表(Semi-Additive Fact)
} 聚合快照事实表(Non-Additive Fact)
} 非事实事实表(Factless Fact Table)

粒度事实表(AdditiveFact):
} 表示的是在特定时间、空间点上的一次瞬间的测量。与粒度同层次的事实表，可以直接将事实字段进行Sum,Count等聚合操作
} 在事实表的设计时，一定要注意一个事实表只能有一个粒度，不能将不同粒度的事实建立在同一张事实表中。
} 交易粒度事实表的来源伴随交易事件成生的数据，例如销售单。在ETL过程中，以原子粒度直接进行迁移。
周期快照事实表(Semi-AdditiveFact)
} 周期快照事实表表现的是一个时间段，或者规律性的重复。这类表非常适合跟踪长期的过程，例如银行账户和其他形式的财务报表。最常用的财务上的周期快照事实表通常有一个月粒度。在周期快照事实表中的数据必须符合该粒度（就是说，他们必须量测的是同一个时间段中的活动）。对于一个好的周期快照事实表来说就是在粒度上有更多的事实。
} 在ETL过程中，以固定的时间间隔生成累计数据。
聚合快照事实表(Non-AdditiveFact):
} 聚合快照事实表用于描述那些有明确开始和结束的过程，例如合同履行，保单受理以及常见的工作流。聚合快照不适合长期连续的处理，如跟踪银行账户或者描述连续的生产制造过程，如造纸。
} 聚合快照事实表的粒度是一个实体从其创建到当前状态的完整的历史。
} 在ETL过程中，随着业务处理过程的步骤逐步完善该表中的记录。
非事实事实表(FactlessFact Table):
} 每个事实表的粒度是一个事件量测。用来描述数据或事件。事件可以发生，但是没有具体的测量值。

6.3 维度表

Ø 维度表可以看作是用户来分析数据的窗口，
Ø 维度表中包含事实数据表中事实记录的特性，有些特性提供描述性信息，有些特性指定如何汇总事实数据表数据，以便为分析者提供有用的信息，
Ø 维度表包含帮助汇总数据的特性的层次结构。

6.4 维度分类

维度的类型:
} 缓慢变化维(Slowly Changing Dimension)
} 快速变化维(Rapidly Changing Dimension)
} 大维(Huge Dimension)和迷你维(Mini-Dimension)
} 退化维(Degenerate Dimension)
缓慢变化维(SCD):
} 大多数的维度的内容都会有不同程度的改变。比如：
} 雇员的升职
} 客户更改了他的名称或地址
} 我们如何去处理这些维度中的变化呢？
} 下面提供了三个处理缓慢变化维的方式
} 直接更新到原先记录中
} 标记记录有效时间的开始日期和结束日期，加入版本控制
} 在记录中添加一个字段来记录历史
快速变化维(FCD):
} 当某个维度的变化是非常快的时候，我们认定他为快速变化维(具体要看实际的变化频率)，比如：
} 产品的价格，地产的价格等
} 例如在一个分析用户如何使用搜索引擎的DW项目中，将用户搜索的关键字作为一个维度。由于用户使用的关键字会快速变化，因此关键字维度中的数据量会迅速增加。
} 另外一个例子就是精度为秒的时间维度，每秒就会增加一个维度值
通常RCD的处理可以分为3类：
Rapidly Changing Small Dimensions – 即维度表字段并不多，表的数据量也不大的情况。这种情形应用SCD中的Type2就可以了。(即：新增一行，旧行置过期)
Rapidly Changing Large Dimensions – 即维度表字段较多，表的数据量较大的情况。这种情形Type2会增加过多的行并导致效率降低，因此通常采用Type3.（新增列：仅保存上一个值previous_value,current_value）
Rapidly Changing Monster Dimensions – 最糟糕的情况，即维度表字段较多，表的数据量很大，且维度表中的一部分字段频繁变化的情况。此时应将相对稳定的字段和频繁变化的字段分割开，频繁变化的字段独立出来形成新的维度表与事实表相连或形成新的雪花关系。（维表分离）

大维度(HugeDimension):
} 数据仓库中最有意思的维度是一些非常大的维度，比如客户，产品等等。一个大的企业客户维度往往有上百万记录，每条记录又有上百个字段。而大的个人客户维度则会超过千万条记录，这些个人客户维度有时也会有十多个字段，但大多数时候比较少见的维度也只有不多的几个属性。
} 大维度需要特殊的处理。由于数据量大，很多涉及大维度数据仓库功能可能会很慢，效率很低。你需要采用高效率的设计方法、选择正确的索引、或者采用其它优化技术来处理以下问题，包括：
向大维度表填充数据
非限制维度的浏览性能，尤其是那些属性较少的维度
多限制的维度属性值的浏览时间
涉及大维度表的对事实表查询的低效率问题
为处理第二类修改所需要增加的额外的记录
迷你维(MiniDimension):
} 将常用的大维度中的少数字段提取出来，形成一个字段少的维度，在查询的时候便可以使用迷你维中的字段
} 这样的设计明显提高查询效率
普通维:
普通维是基于一个维表的维度，由维表中的不同列来表示维度中的不同级别。
雪花维：
雪花维是基于多个维表的维度，各个维表间以外键关联，分别存储在同一维度中不同级别的成员列值。
父子维：
父子维是基于两个维表列的维度，由维表中的两列来共同定义各个成员的隶属关系，一列称为成员键列，标识每个成员，另一列称为父键列，标识每个成员的父代。
父子维度通俗的话来讲，这个表是自反 的，即外键本身就是引用的主键；类似这样的关系，如公司组织结构，分公司是总公司的一部分，部门是分公司的一部分，当然如果定义得好的话员工是部门的一部 分；通常公司的组织架构并非处在等层次上的，例如总公司下面的部门看起来就和分公司是一样的层次。因此父子维的层次通常不固定的。
因为父子维的复杂的自引用关系，如果按照缓慢维度的全历史记录方式来处理，必然导致逻辑关系混乱，处理起来比较棘手；任何一个组织的变动 (修改名称，更改引用，新增等等操作 )将会引起其下属节点相应的变动；任何一个意外都会导致整个结构的变化，同时发生意外后所带来的逻辑关系很难理顺。而 SQLServer2000中 Analysis Service对于这种急剧的变化处理并不稳定。
因此建议按照缓慢变化维的覆盖方式解决，即只根据主键这个唯一标志进行判断是否是新增还是修改。
索引：
与在其他关系数据库中一样，索引对数据仓库的性能具有重要作用。每个维度表都必须在主键上建立索引。在其他列如标识层次结构级别的列上，索引对于某些专用查询的性能也很游泳。事实数据表必须在由维度表外键构成的组件主键上建立索引。
粒度(Grain) 层次(Hierarchy)：
Ø 粒度是指数据仓库的数据单位中保存数据的细化或综合程度的级别。细化程度越高，粒度级就越小；相反，细化程度越低，粒度级就越大。设计粒度是设计数据仓库中的一个重要的前提
Ø 层次指描述明细数据的层次
一些影响维度建模的因素:
Ø 数据或展现的安全性
Ø 复杂的查询和分析

毕业4年，从应届生到BI数据分析师老油条，不定期将过去自己求职积累经验和数据分析学习相关的一些笔记分享给大家，对互联网数据分析、机器学习有兴趣的朋友也可以关注我的工重号：python数据分析和机器学习，专注BI、数据分析和机器学习的学习和实践 .