面试题-数仓

---

title: 面试题-数仓
tags: 面试
renderNumberedHeading: true
grammar_cjkRuby: true

1. 如何判定一个表是事实表还是维度表？

• 事实表是多个维度表的一个交点，维度表是分析事实的一个窗口。
• 判定一个表是否事实表可以简单的依据是否有度量（数值型数据，并且大部分度量是可加性的），少部分不具有可加性比如商品价格，订单状态；半可加性，如不同仓库的同一个商品数加起来（仅仅某些维度可加）
• 维度表是事实表的一个分析角度，维度是事实表的查询约束条件，维度的细节级别决定了事实表的粒度（一个事实表只能有一个粒度决定事实表一行记录单行信息说明，即粒度是对维度细节级别的定义，各个维度粒度组合决定事实表的粒度，从而形成单行记录的说明）粒度下的一个度量可加计算就是统计分析。

2. 数据建模过程说一下？

• 先确定是特指维度建模还是，数据建模这个大概念
• 维度建模一般四大流程（选取业务过程，定义粒度，确定维度，确定事实）
• 数据建模一般8步（确定业务目标→数据获取→数据检验→变量选择（数据清洗）→变量分组→分组变量WOE转化→数据输入模型算法→模型评估）
  • 确定目标首先是理解业务要解决什么问题,
  • 数据在哪，怎么获取，可以按照总体样本比例获取
  • 确定需要哪些数据指标， 数据检验包括检验数据的唯一性（排除重复数据）、样本完整性（确保样本变量的分布不会显著偏离总体的分布）、范围以及取值、异常值（过大、过小、记录出错等）。
  • 变量选择:就是选择具有预测能力的自变量。在做自变量的选择时，需要做数据的探索（这要依靠个人经验和统计学的基础知识,自变量之间的相关性用皮尔森相关系数衡量就可以，而分类型自变量则可以通过概率比、基尼方差、信息值等来衡量。需要了解因变量：自变量是被操纵的变量，而因变量是被测定或被记录的变量。也就是说自变量是“原因”，而因变量就是“结果”
  • 变量分组：分组的基本原则：组内差异小，组间差异大；分组数量不宜过大或过小，建议数值型变量分为4~8组。 分组的意义：变量分组后，可以获得简洁高效的规则：需要了解 分类型自变量如何分组和数值型自变量分组的差别使用的分组算法。
  • WOE是一种：WOE的全称是“Weight of Evidence”，即证据权重，是一种比较样本响应的可能性和和样本数据的差异大小的计算函数 ，WOE越小，差异越小。
  • 训练模型，调整参数，使模型效果不断优化
  • 模型评估：模型效果的评估有两个方面：一是模型是否解决了需要解决的问题（是否还有没有注意和考虑到的潜在问题需要解决）；二是模型的精确性（误差率或者残差是否符合正态分布等）。
  • 结果呈现：结果呈现主要关注以下三个方面：模型解决了哪些问题？解决效果如何？如何解决问题？具体操作步骤是什么？
  • 模型部署：通过大量数据解决了一个或多个重要的现实问题，需要将方案落实下去，一般情况下需要通过线上技术环境部署落实。

3. 三范式

• 第一范式：存在非主属性对码的部分依赖关系 R(A,B,C) AB是码 C是非主属性 B-->C B决定C C部分依赖于B。如果关系R 中所有属性的值域都是单纯域，那么关系模式R是第一范式的。那么符合第一模式的特点就有：有主关键字、主键不能为空、主键不能重复,、字段不可以再分
• 第二范式：存在非主属性对码的传递性依赖 R(A,B,C) A是码 A -->B ,B-->C。如果关系模式R是第一范式的，而且关系中每一个非主属性不部分依赖于主键，称R是第二范式的。所以第二范式的主要任务就是：满足第一范式的前提下，消除部分函数依赖。
• 第三范式：**不存在非主属性对码的传递性依赖以及部分性依赖 **

4. 缓慢变化维处理方式？
   1. 什么也不该，保留原始值
   2. 直接覆盖
   3. 增加新行，需要为新航分配新的代理键
   4. 增加新属性列
   5. 增加微型维度（某些维度属性变化较快导致维度表越来越大可以把这些属性柴丽出来单独构建微型维度表）
   6. 双重外键并且方式1与方式2结合
      在方式2的基础上，不仅是维度的代理键作为事实表外键，维度的自然键（如果自然键会被重新分配，发生变化，应该使用持续性超自然键）也同时作为事实表外键。
      事实表通过代理键连接维表获取历史维度属性，通过自然键连接维表获取当前维度属性
      为表指定键的策略有两种：
      • 自然键。自然键是已经存在的一个或多个属性，它在业务概念中是唯一的。对于表Customer来说，存在两个候选键，CustomerNumber与SocialSecurityNumber。
        代理键。
      • 引入一个不具有业务含义的列作为键，称作代理键。例如图1中表Address的列AddressID。地址不具有一个“简单”的自然键，因为需要使用Address表的所有列组成一个键（取决于你的问题域，可能仅仅需要组合Street和ZipCode列），所以此时引入一个代理键是一个更好的选择
5. 大宽表的优点与缺点？

• 优点：
  1. 提高查询性能
  2. 快速响应
  3. 方便使用，降低使用成本：构建公共指标数据层，提升公共指标的复用性，减少重复加工。
  4. 提高用户满意度
• 缺点：
  1. 数据冗余
  2. 另外就是灵活性差，就比如说线上业务表结构变更，宽表模式改造量也比较大
  3. 开发宽表为了避免宽表重复迭代，我们应该去了解业务全流程，得需要知道需扩展哪些维度，沉淀哪些指标，这样就流程会比较长，特别是有些业务快速迭代的话，就有点捉襟见肘

6. 拉链表的实现逻辑说一下？

   • 规范的原始表下构建拉链表：
   1. 就是老订单出现了新状态,我们先将老订单的老状态end_time更改为昨天的日期,封存起来
   2. 是老订单出现了新状态,我们直接重新开启一条新数据用来显示老订单新状态end_time为9999-12-31
   3. (今天的增量表)再就是 full join 不上的就是新订单end_time为9999-12-31
   4. (昨天的拉链表)还有老订单的已经闭合过的老数据
   5. 最终:将四种数据union昨天的end_time不是9999-12-31的拉链表来生成最新的拉链表!
   • 非规范原始表构建拉链表
     什么是非规范的原始表，就是原始表中不存在 create_time 或者 update_time 。 或者更甚者 2者都不存在，这样的情况下，我们该如何去构建拉链表呢？思路是构建一列，去标识 发生变动的数据。我们选择将所有列取 md5 值的方式！！！！

7. 拉链表数据错误回滚
   修正拉链表回滚问题本质就是：其实目的就是找到历史的快照。历史的快照可以根据起始更新时间，那你就找endtime小于你出错的数据就行了，出错日期的数据就行了。重新导入数据，将原始拉链表数据过滤到指定日期之前即可（本质就是过滤数据到回滚日期的前一天。）。

8. 你刚说到数据倾斜，这个怎么处理？ null值怎么打散，打散的伪代码或者sql使用concat，split；宽依赖和窄依赖:关联映射关系。
   发生数据倾斜的原因：
   在进行shuffle 的时候，必须 将各个节点上相同的 key 拉取到某个节点上的一个 task 来进行处理 ，比如按照 key 进行聚合或 join 等操作。此时如果某个key 对应的数据量特别大的话，就会发生数据倾斜。分区父子关联映射关系：1父：n子；1子：n父。
   数据倾斜的表现：
   表现一：
   大多数task运行都非常快，但是个别task运行相对很慢，极端情况，持续执行到99%，就是不结束(mr和hive中常见)
   表现二：
   多数情况下，程序是正常运行的，但是某一天突然发生了OOM异常
   数据倾斜解决：
   1. GroupBy造成的倾斜：set hive.map.aggr=true #开启局部聚合；set hive.groupby.skewindata=true;#开启对map的输出结果进行打散操作。
   2. count（distinct）进行去重统计优化：改写成先分组groupby再count，利用上着的打散特性。
   3. 小表join大表（1G数据存储大小的边界区分）：使用默认开启的mapjoin,复制小表制定列在map阶段进行join计算。从而不需要分发数据就没有数据倾斜。
   4. 倾斜的值是明确而且数量很少（比如null值）：解决方案使用case when对这些值匹配的字段key进行concat随机数进行打散。
   5. 动态分治思想+映射关系:把倾斜的键值和不倾斜的键值分开处理，不倾斜的正常处理即可，倾斜的做mapjoin，然后union all结果即可。

9. 你们主题是怎么划分的，举个例子
   主题： 主题是在较高层次上将企业信息系统中的数据进行综合、归类和分析利用的一个抽象概念，每一个主题基本对应一个宏观的分析领域。
   关于主题域： 主题域通常是联系较为紧密的数据主题的集合。可以根据业务的关注点，将这些数据主题划分到不同的主题域(也说是对某个主题进行分析后确定的主题的边界。)
   关于主题域的划分：
   主题域的确定必须由最终用户和数据仓库的设计人员共同完成的， 而在划分主题域时，大家的切入点不同可能会造成一些争论、重构等的现象，考虑的点可能会是下方的某些方面：
   1、按照业务或业务过程划分：比如一个靠销售广告位置的门户网站主题域可能会有广告域，客户域等，而广告域可能就会有广告的库存，销售分析、内部投放分析等主题；
   2、根据需求方划分：比如需求方为财务部，就可以设定对应的财务主题域，而财务主题域里面可能就会有员工工资分析，投资回报比分析等主题；
   3、按照功能或应用划分：比如微信中的朋友圈数据域、群聊数据域等，而朋友圈数据域可能就会有用户动态信息主题、广告主题等；
   4、按照部门划分：比如可能会有运营域、技术域等，运营域中可能会有工资支出分析、活动宣传效果分析等主题；
   总而言之，切入的出发点逻辑不一样，就可以存在不同的划分逻辑。在建设过程中可采用迭代方式，不纠结于一次完成所有主题的抽象，可先从明确定义的主题开始，=》OneData 后续逐步归纳总结成自身行业的标准模型。

10. 交叉维度的解决方案？
    桥接表可以捕获多对多关系，并且由于源系统中的关系是已知的.桥接表可以解决掉维度之间的多对多关系，也解决掉的维度表的多值维度问题。
    多值维度： 当事实表的一行涉及到维度表的多行时就产生多值维度，同样当维度表的一行需要获取单一属性的多个值时也会产生多值维度。交叉维度是多值维度的一个特例是维度之间的多对多关系；多值维度是事实表和维度表的多对多关系。
    多值维度的解决方案：
    1. 扁平化多值维度，比如一个账户可以三个人拥有，可以引入三个账户拥有人列。
    2. 可以用桥接表：即中间表，维护比较麻烦，计算易出错。

11. 数据质量如何保证（DQC）？制定规范

    • 表级别的监控
      一些类似于维度表，或者缓慢渐变维的表，可以使用固定阈值进行监控。而其余的业务表（事实表，数据集市表），是不妥的（可以采用数据分析，回归模型等方式，进行预测，设定阈值）。

    • 字段级别的监控：对于字段级别的数据变化要提前感知，及时报警，防止影响下游指标的计算。

      • 枚举值的校验
      • 特殊值判断（脏数据等）
      • 范围判断

    • 全链路的监控
      ETL任务监控 就是在ETL过程中，哪一个任务报错，报错的问题是什么，要把日志取出来。这个ETL如果没有执行完，结果出不来，下游有哪些任务是会受到影响。
      VIP任务监控： 重点业务指标重点排查，保证在每天上班前，数据完整，正确地提供。

      数据质量管理你们怎么做的？
      参考：https://www.zhihu.com/question/404424623

      数据治理这块你有参与吗？
      数据治理本身包含很多的内容，目标，制度规范、流程、组织、工具，成熟，保护和隐私缺一不可。=》数据质量作为衡量。

12. 任务延迟如何优化（SLA）？没做过了解

参考：https://www.sohu.com/a/437094597_115128?sec=wd 有限提高任务调度的worker并行度。

最佳服务水平协议（SLA） 级别数据中心战略包括三项关键性能指标（KPI），用于衡量公司的投资效果。IT 部门都会制定可实现的最佳服务水平协议（SLA）级别、最低成本以及最高资源利用率等指标。
- 服务质量（QoS）。针对每项业务功能对于正常，运行时间、平均修复时间（MTTR）和成本的敏感度，我们在 SLA 方面使用了分层的方法。
- 成本效益（每个服务部门的成本）。根据每项业务功能所需的容量进行构建。
- 有效地利用资产和容量。通过资产的实际输出而不是资产的分配方式进行衡量，通过评估作业或存储的实际运行状况衡量利用率是否高效。

13. join的时候依照哪一个关键字？对字段有没有限制？

14. 元数据管理怎么做的？没做过，了解
    元数据的分类——技术元数据、业务元数据、管理元数据、
    过程:元数据范围，接入，标准，维护，查找分析报告，管理平台。
    分析：血缘分析，影响分析，冷热分析，关联分析，资产地图分析。

15. hive的四种排序

    • order by会对输入做全局排序，因此只有一个 reducer(多个 reducer无法保证全局有序)
    • sort by不是全局排序，其在数据进入 reducer前完成排序
    • distribute by是控制在map端如何拆分数据给 reduce端的。hive会根据 distribute by后面列，对应 reduce的个数进行分发，默认是采用hash算法；distribute by经常和 sort by配合使用。
    • 当distribute by 和 sort by 所指定的字段相同时，即可以使用cluster by；cluster by指定的列只能是升序。

16. 会有小文件：目前没有系统级的小文件处理方案，都需要自己编码实现。

    • Hadoop Archive或者HAR，是一个高效地将小文件放入HDFS块中的文件存档工具，它能够将多个小文件打包成一个HAR文件（运行一个mapreduce作业），这样在减少namenode内存使用的同时，仍然允许对文件进行透明的访问。不能新增加移除归档后的HAR文件。
    • Sequence file，hadoop可以进行merge大批小文件合并成一个大文件(key是小文件名，value是文件内容)
    • CombineFileInputFormat是一种新的inputformat，用于将多个文件合并成一个单独的split。