Hive基础面试-如何理解复用率的

1. 模型的复用率你们是怎么做的？

 简单直白的说就是你的模型复用率如何，在业务方是否认可该模型，也是衡量模型建设的一个标准，复用率数：数仓模型涉及的核心是追求模型的复用和共享，引用系数越高，说明数仓的复用性越好

「用模型引用系数作为指标，衡量数据中台模型设计的复用度。引用系数越高，说明数仓的复用性越好。
模型引用系数：一个模型被读取，直接产出下游模型的平均数量」

• 通过数据血缘图评估模型设计

借助元数据中心的数据血缘图，我们能够直观地评判数仓模型的设计优劣。一个欠佳的模型设计往往呈现出自下而上的单一线条状，这意味着数据的流向极为单一，缺乏应有的复用和共享。

与之相反，理想的模型设计应是交织的发散型结构。在这种结构下，一个模型能够被多个下游模型引用，从而形成复杂的网络关系。比如，一张 DWD 层表被多张 DWS 层表引用，这充分体现了数据的复用和共享。这样的设计能够让数据在不同的业务场景中得到充分利用，进而提高数据的价值。同时，当底层数据发生变化时，只需在少数关键节点进行调整，就可以影响到多个下游业务，大大降低了维护的工作量。

• 以模型引用系数衡量复用度

复用度，我们引入了模型引用系数这一重要指标。模型引用系数指的是一个模型被读取后，直接产出下游模型的平均数量。

以 DWD 层表为例，如果一张 DWD 层表被 5 张 DWS 层表引用，那么这张 DWD 层表的引用系数就是 5。通过计算所有有下游表的 DWD 层表的引用系数的平均值，我们可以得到 DWD 层表平均模型引用系数。一般来说，这个系数低于 2 被认为比较差，而 3 以上则相对比较好，这是根据经验得出的判断标准

•  DWD完善度与复用性的关系

DWD 层作为数据仓库的重要层次，其完善度对于整个数仓的性能和复用性至关重要。通常情况下，我们可以通过观察 ODS 层有多少表被 DWS/ADS/DM 层引用，来衡量 DWD 层是否完善

• DWS/ADS/DM 层完善度对复用性的影响

DWS/ADS/DM 层的完善度主要考核汇总数据的完善程度。一般来说，我们主要看汇总数据能直接满足多少查询需求。如果汇总数据无法满足需求，使用数据的人就不得不使用明细数据甚至原始数据，这会增加查询的复杂性和成本

• 完善度对数仓模型复用性的重要意义

完善度的数仓模型能够带来多方面的好处。首先，它可以提高数据的复用性，减少重复开发工作。通过在 DWD 层进行充分的数据处理和整合，上层的数据使用可以更加高效地复用已有的数据资产。其次，完善的汇总数据可以满足大部分查询需求，提高查询速度和降低成本。最后，完善度高的数仓模型能够更好地支持业务决策，提供准确、及时的数据支持

2. 数据去重的常见方法有哪些？

数据去重是提升数据质量的重要环节，常见的去重方法包括：

主键去重：为数据表设定唯一标识符作为主键，数据库层面自动阻止重复数据的插入。

哈希技术：利用哈希函数计算数据行的唯一哈希值，相同数据产生相同的哈希值，从而快速识别并移除重复项。

排序法：先对数据集进行排序，然后遍历数据，比较相邻记录，移除重复行。此方法适用于数据量不大或内存足够大的情况。

distinct查询：在SQL查询中使用DISTINCT关键字筛选出唯一的记录。

外部键关联：在关联表之间通过外键约束，确保从属记录的唯一性，间接实现去重。

数据清洗工具：利用专门的数据清洗软件或库（如Python的pandas库），内置去重功能简化操作。

指纹技术：对复杂数据结构（如文档、图像）使用内容指纹（如MD5、SHA）进行比较，识别重复内容。

3. 缓慢变化维的设计？

三种：直接覆盖，增加新行，增加心属性列

Type 1:覆盖：直接用新值代替旧值。

Type 2:增加新行。将当前行的状态设置为off，并设置一个endtime时间戳，将当前时间标记上。

同时新增1行，将其状态标记为on，设置begintime时间戳为上一个记录的endtime+1。

Type 3:增加新列：给表增加一个新列，来存储新值，同时保留原来的值不变。

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

拉链表使用场景：需要查看历史某一时间节点的状态，同时考虑到存储空间。

实现方式：

首先是拉链表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

5. 星型模型和雪花模型区别？

星形模型(Star Schema):

1.事实被维度所包围，且维度没有被新的表连接

2.星形模型是一个比较折中的的建模方式(BIAPPS中都是用的是星形的建模方式)

雪花模型(Snowflake Schema):

1.事实表被多个维表或一个或多个层次所包围

2.雪花模型一般在处理大的且相对静态的层次的时候使用

根据事实表和维度表的关系，又可将常见的模型分为星型模型和雪花型模型。

　　星形模型：当所有维度表连接到事实表上的时候，整个图就像一个星星，故称之为星型模型。星型架构是一种非正规化的结构，多维数据集的每一个维度都直接与事实表相连，不存在渐变维度，所以数据有一定冗余。因为有冗余，所以很多统计不需要做外部的关联查询，因此一般情况下效率比雪花模型高。

　　雪花模型：当有多个维度表没有直接连接到事实表上，而是通过其他维度表连接到事实表上时，其图形就像雪花，故称雪花模型。雪花模型的优点是减少了数据冗余，所以一般情况下查询需要关联其他表。在冗余可接受的前提下使用星型模型。

星型模型和雪花模型的区别在于：维度表是直接连接到事实表还是其他维度表。

6. 你们公司的数仓分层，每一层是怎么处理数据的

数据仓库一般分为三层，自上而下分别为数据贴源层（ODS，Operation Data Store）、数据公共层（CDM，Common Data Model）和数据应用层（ADS，Application Data Service）。

逻辑分层架构

分层的好处

• 清晰数据结构：每一个数据分层都有它的作用域，这样我们在使用表的时候能更方便地定位和理解。
• 数据血缘追踪：简单来讲可以这样理解，我们最终给业务呈现的是一张能直接使用的张业务表，但是它的来源有很多，如果有一张来源表出问题了，我们希望能够快速准确地定位到问题，并清楚它的危害范围。
• 减少重复开发：规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算。
• 把复杂问题简单化：将一个复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤，比较简单和容易理解。而且便于维护数据的准确性，当数据出现问题之后，可以不用修复所有的数据，只需要从有问题的步骤开始修复。

7. 什么是事实表，什么是维表

事实表（Fact Table）是指存储有事实记录的表，如系统日志、销售记录等；事实表的记录在不断地动态增长，所以它的体积通常远大于其他表。

事实表作为数据仓库建模的核心，需要根据业务过程来设计，包含了引用的维度和业务过程有关的度量。

可加：最灵活最有用的事实是完全可加，可加性度量可以按照与事实表关联的任意维度汇总。比如消费总金额

半可加：半可加度量可以对某些维度汇总，但不能对所有维度汇总。差额是常见的半可加事实，除了时间维度外，他们可以跨所有维度进行操作。(比如每天的余额加起来毫无意义)

不可加：一些度量是完全不可加的，例如：比率。对非可加事实，一种好的方法是，分解为可加的组件来实现聚集

维度表（Dimension Table）或维表，有时也称查找表（Lookup Table），是与事实表相对应的一种表；它保存了维度的属性值，可以跟事实表做关联；相当于将事实表上经常重复出现的属性抽取、规范出来用一张表进行管理。常见的维度表有：日期表（存储与日期对应的周、月、季度等的属性）、地点表（包含国家、省／州、城市等属性）等。维度是维度建模的基础和灵魂，

使用维度表有诸多好处，具体如下：

• 缩小了事实表的大小。
• 便于维度的管理和维护，增加、删除和修改维度的属性，不必对事实表的大量记录进行改动。
• 维度表可以为多个事实表重用，以减少重复工作。

下钻是商业用户分析数据的最基本的方法。下钻仅需要在查询上增加一个行头指针，新行的头指针是一个维度属性，附加了sql语言的group by表达式，属性可以来自任何与查询使用的事实表关联的维度，下钻不需要预先存在层次的定义，或者是下钻路径。

有时，维度除了主键外没有其他内容，例如，当某一发票包含多个数据项时，数据项事实行继承了发票的所有描述性维度外键，发票除了外键无其他项，但发票数量仍然是在此数据项级别的合法维度键。这种退化维度被放入事实表中，清楚的表明没有关联的维度表，退化维度常见于交易和累计快照事实表中

8. 了解onedata吗，说说你的理解

于前期缺少规划，随着集团业务发展，暴露的问题越来越多，给数据治理工作带来了很大的挑战，在数据仓库建设过程中，主要发现了以下几个问题：

• 缺乏统一的标准，如：开发规范、指标口径等。
• 缺乏统一数据质量监控，如：字段数据不完整和不准确，数据发散等。
• 业务知识体系混乱，导致数据开发人员开发成本增加。
• 数据架构不合理，层级之间分工不明显，数据流向混乱。
• 缺失统一维度和指标管理。

二、目标

• 基于公司现有的数据平台，完善数据体系架构、数据规范、模型标准和开发模式，从而驱动业务快速发展
• 高人力成本、数据错误、浪费资源、杂乱无章、效率低下，这些经常出现的痛点，OneData都能轻松解决
• 

1.核心思想

从设计，开发和使用上保障规范和统一，实现数据资产全链路管理，提供标准的数据输出，包含数据规范定义，数据模型设计规范，ETL规范

2.核心特点

3.策略