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.策略

相关推荐
Elastic 中国社区官方博客1 小时前
使用 Elastic 收集 Windows 遥测数据:ETW Filebeat 输入简介
大数据·windows·elasticsearch·搜索引擎·全文检索·可用性测试
鸡c3 小时前
IM项目-----ElasticSearch
大数据·elasticsearch·搜索引擎
Java 第一深情3 小时前
Flink数据源的读写介入体系
大数据·flink
天冬忘忧4 小时前
Kafka 消费者全面解析:原理、消费者 API 与Offset 位移
大数据·kafka
jlting1954 小时前
《智慧教育实时数据分析推荐项目》详细分析
大数据·redis·sql·kafka·database
青云交5 小时前
大数据新视界 -- Hive 数据仓库:架构深度剖析与核心组件详解(上)(1 / 30)
大数据
EasyNVR5 小时前
NVR管理平台EasyNVR多品牌NVR管理工具的流媒体视频融合与汇聚管理方案
大数据·网络·安全·音视频·监控·视频监控
java1234_小锋5 小时前
在Elasticsearch中,是怎么根据一个词找到对应的倒排索引的?
大数据·elasticsearch·搜索引擎
油头少年_w7 小时前
Hadoop进阶原理(HDFS、MR、YARN的原理)
大数据·hadoop·分布式
大数据编程之光7 小时前
基于 Flink 的车辆超速监测与数据存储的小实战
大数据·flink·linq