序列号 | 内容 | 链接 |
---|---|---|
1 | 大数据知识面试题-通用(2022版) | https://blog.csdn.net/qq_43061290/article/details/124819089 |
2 | 大数据知识面试题-Hadoop(2022版) | https://blog.csdn.net/qq_43061290/article/details/124822293 |
3 | 大数据知识面试题-MapReduce和yarn(2022版) | https://blog.csdn.net/qq_43061290/article/details/124841929 |
4 | 大数据知识面试题-Zookeepr (2022版) | https://blog.csdn.net/qq_43061290/article/details/124548428 |
5 | 大数据知识面试题-Hive (2022版) | https://blog.csdn.net/qq_43061290/article/details/125105485 |
6 | 大数据知识面试题-Flume(2022版) | https://blog.csdn.net/qq_43061290/article/details/125132610 |
7 | 大数据知识面试题-Hbase(2022版) | https://blog.csdn.net/qq_43061290/article/details/125145399 |
8 | 大数据知识面试题-sqoop(2022版) | https://blog.csdn.net/qq_43061290/article/details/125145736 |
9 | 大数据知识面试题-Kafka(2022版) | https://blog.csdn.net/qq_43061290/article/details/125145841 |
10 | 大数据知识面试题-Azkaban(2022版) | https://blog.csdn.net/qq_43061290/article/details/125146859 |
11 | 大数据知识面试题-Scala (2022版) | https://blog.csdn.net/qq_43061290/article/details/125145976 |
12 | 大数据知识面试题-Spark (2022版) | https://blog.csdn.net/qq_43061290/article/details/125146030 |
13 | 大数据知识面试题-Flink(2022版) | https://blog.csdn.net/qq_43061290/article/details/125182137 |
14 | 数据仓库—建设规范(2022版) | https://blog.csdn.net/qq_43061290/article/details/125785261 |
15 | 数据仓库–开发流程(2022版) | https://blog.csdn.net/qq_43061290/article/details/125967931 |
16 | 数据仓库–名词解释及关系(2022版) | https://blog.csdn.net/qq_43061290/article/details/125886082 |
优秀可靠的数仓体系,往往需要清晰的数据分层结构,即要保证数据层的稳定又 要屏蔽对下游的影响,并且要避免链路过长。那么问题来了,一直在讲数仓要分 层,那数仓分几层最好?
目前市场上主流的分层方式眼花缭乱,不过看事情不能只看表面,还要看到内在 的规律,不能为了分层而分层,没有最好的,只有适合的
。
分层是以解决当前业务快速的数据支撑为目的,为未来抽象出共性的框架并能够 赋能给其他业务线,同时为业务发展提供稳定、准确的数据支撑,并能够按照已 有的模型为新业务发展提供方向,也就是数据驱动和赋能。
一个好的分层架构,要有以下好处:
数仓分层要结合公司业务进行,并且需要清晰明确各层职责,一般采用如下分层 结构:
数据分层架构
数仓建模在哪层建设呢?我们以维度建模为例,建模是在数据源层的下一层进行 建设,在上图中,就是在 DW 层进行数仓建模,所以DW 层是数仓建设的核心层。 下面详细阐述下每层建设规范,和上图的分层稍微有些区别:
ODS 层,是最接近数据源中数据的一层,为了考虑后续可能需要追溯数据问题, 因此对于这一层就不建议做过多的数据清洗工作,原封不动地接入原始数据即可, 至于数据的去噪、去重、异常值处理等过程可以放在后面的 DWD 层来做。
数据仓库层是我们在做数据仓库时要核心设计的一层,在这里,从 ODS 层中获 得的数据按照主题建立各种数据模型。
DW 层又细分为 DWD (Data Warehouse Detail) 层、DWM (Data WareHouse Middle) 层和 DWS (Data WareHouse Servce) 层。
(1) 数据明细层:DWD (Data Warehouse Detail)
该层一般保持和 ODS 层一样的数据粒度,并且提供一定的数据质量保证。DWD 层 要做的就是将数据清理、整合、规范化、脏数据、垃圾数据、规范不一致的、状态 定义不一致的、命名不规范的数据都会被处理。
同时,为了提高数据明细层的易用性,该层会采用一些维度退化手法,将维度退 化至事实表中,减少事实表和维表的关联。
另外,在该层也会做一部分的数据聚合,将相同主题的数据汇集到一张表中,提 高数据的可用性 。
(2) 数据中间层:DWM (Data WareHouse Middle)
该层会在 DWD 层的数据基础上,数据做轻度的聚合操作,生成一系列的中间表, 提升公共指标的复用性,减少重复加工。
直观来讲,就是对通用的核心维度进行聚合操作,算出相应的统计指标。
在实际计算中,如果直接从 DWD 或者 ODS 计算出宽表的统计指标,会存在计算 量太大并且维度太少的问题,因此一般的做法是,在 DWM 层先计算出多个小的 中间表,然后再拼接成一张 DWS 的宽表。由于宽和窄的界限不易界定,也可以 去掉 DWM 这一层,只留 DWS 层,将所有的数据再放在 DWS 亦可。
(3) 数据服务层:DWS (Data WareHouse Servce)
DWS 层为公共汇总层,会进行轻度汇总,粒度比明细数据稍粗,基于 DWD 层上 的基础数据,整合汇总成分析某一个主题域的服务数据,一般是宽表。DWS 层应覆 盖 80% 的应用场景。又称数据集市或宽表。
按照业务划分,如主题域流量、订单、用户等,生成字段比较多的宽表,用于提 供后续的业务查询,OLAP 分析,数据分发等。
一般来讲,该层的数据表会相对比较少,一张表会涵盖比较多的业务内容,由于 其字段较多,因此一般也会称该层的表为宽表。
在这里,主要是提供给数据产品和数据分析使用的数据,一般会存放在 ES、 PostgreSql、Redis 等系统中供线上系统使用,也可能会存在 Hive 或者 Druid 中供数据分析和数据挖掘使用。比如我们经常说的报表数据,一般就放在这里。
如果维表过多,也可针对维表设计单独一层,维表层主要包含两部分数据:
高基数维度数据:一般是用户资料表、商品资料表类似的资料表。数据量可能是 千万级或者上亿级别。
低基数维度数据:一般是配置表,比如枚举值对应的中文含义,或者日期维表。 数据量可能是个位数或者几千几万。
(1) 按照业务或业务过程划分
业务容易理解,就是指的功能模块/业务线。
业务过程:指企业的业务活动事件,如下单、支付、退款都是业务过程。不过需 要注意的是,一个业务过程是一个不可拆分的行为事件,通俗的讲,业务过程就 是企业活动中的事件。
(2) 按照数据域划分
数据域是指面向业务分析,将业务过程或者维度进行抽象的集合。其中,业务过 程可以概括为一个个不可拆分的行为事件,在业务过程下,可以定义指标,维度 是指度量的环境,如买家下单事件,买家是维度。为保障整个体系的生命力,数 据域是需要抽象提炼,并且长期维护和更新的,但不轻易变动。在划分数据域时, 既能涵盖当前所有的业务需求,又能在新业务进入时无影响地被包含进已有的数 据域中和扩展新的数据域。
(1) 高内聚、低耦合
即主题内部高内聚、 不同主题间低耦合。明细层按照业务过程划分主题,汇总层 按照“实体+ 活动”划分不同分析主题,应用层根据应用需求划分不同应用主题。
(2) 核心模型和扩展模型要分离
建立核心模型与扩展模型体系,核心模型包括的字段支持常用的核心业务,扩展 模型包括的字段支持个性化或少量应用的需要,不能让扩展模型的字段过度侵入
核心模型,以免破坏核心模型的架构简洁性与可维护性。
(3) 公共处理逻辑下沉及单一
越是底层公用的处理逻辑越应该在数据调度依赖的底层进行封装与实现,不要让 公用的处理逻辑暴露给应用实现,不要让公共逻辑多处同时存在。
(4) 成本与性能平衡
适当的数据冗余可换取查询和刷新性能,不宜过度冗余与数据复制。
(5) 数据可回滚
处理逻辑不变,在不同时间多次运行数据结果确定不变。
稳定业务按照标准的数据流向进行开发,即 ODS –> DWD –> DWS –> APP。
非稳定业务或探索性需求,可以遵循 ODS -> DWD -> APP 或者 ODS -> DWD -> DWM ->APP 两个模型数据流。
在保障了数据链路的合理性之后,也必须保证模型分层引用原则:
举例:
需统一规定不同的数据的数据类型,严格按照规定的数据类型执行:
宽表的冗余字段要确保:
保证主题域内,指标口径一致,无歧义。
通过数据分层,提供统一的数据出口,统一对外输出的数据口径,避免同一指标 不同口径的情况发生。
(1) 指标梳理
指标口径的不一致使得数据使用的成本极高,经常出现口径打架、反复核对数据 的问题。在数据治理中,我们将需求梳理到的所有指标进行进一步梳理,明确其 口径,如果存在两个指标名称相同,但口径不一致,先判断是否是进行合并,如 需要同时存在,那么在命名上必须能够区分开。
(2) 指标管理
指标管理分为原子指标维护和派生指标维护。
原子指标:
派生指标:
(1) 增量表
新增数据,增量数据是上次导出之后的新数据。
(2) 全量表
每天的所有的最新状态的数据。
(3) 快照表
按日分区,记录截止数据日期的全量数据。
(4) 拉链表
记录截止数据日期的全量数据。
这部分主要是要通过对历史数据的等级划分与对表类型的划分生成相应的生命 周期管理矩阵。
(1) 历史数据等级划分
主要将历史数据划分 P0、Pl、P2、P3 四个等级,其具体定义如下:
(2) 表类型划分
事件型流水表 (增量表) 指数据无重复或者无主键数据,如日志。
事件型镜像表 (增量表) 指业务过程性数据,有主键,但是对于同样主键的属性 会发生缓慢变化,如交易、订单状态与时间会根据业务发生变更。
维表包括维度与维度属性数据,如用户表、商品表。
Merge 全量表包括业务过程性数据或者维表数据。由于数据本身有新增的或者发 生状态变更,对于同样主键的数据可能会保留多份,因此可以对这些数据根据主 键进行 Merge 操作,主键对应的属性只会保留最新状态,历史状态保留在前一 天分区 中。例如,用户表、交易表等都可以进行 Merge 操作。
ETL 临时表是指 ETL 处理过程中产生的临时表数据,一般不建议保留,最多 7 天。
TT 拉取的数据和 DbSync 产生的临时数据最终会流转到 DS 层,ODS 层数据作 为原始数据保留下来,从而使得 TT&DbSync 上游数据成为临时数据。这类数据 不建议保留很长时间,生命周期默认设置为 93 天,可以根据实际情况适当减少 保留天数。
很多小业务数据或者产品数据,BI 一般是直接全量拉取,这种方式效率快,对 存储压力也不是很大,而且表保留很长时间,可以根据历史数据等级确定保留策 略。
通过上述历史数据等级划分与表类型划分,生成相应的生命周期管理矩阵,如下
同步规范:
表分类与生命周期:
数据质量:
(1) 设计准则
共维度在不同的物理表中的字段名称、数据类型、数据内容必须保持一致 (历史原 因不一致,要做好版本控制)
组合原则:
将维度与关联性强的字段进行组合,一起查询,一起展示,两个维度必须具有天 然的关系,如:商品的基本属性和所属品牌。
无相关性:如一些使用频率较小的杂项维度,可以构建一个集合杂项维度的特殊 属性。
行为维度:经过计算的度量,但下游当维度处理,例:点击量 0-1000,100-1000 等,可以做聚合分类。
拆分与冗余:
针对重要性,业务相关性、源、使用频率等可分为核心表、扩展表。 数据记录较大的维度,可以适当冗余一些子集。
(2) 存储及生命周期管理
建议按天分区。
3 个月内最大访问跨度<=4 天时,建议保留最近 7 天分区;
3 个月内最大访问跨度<=12 天时,建议保留最近 15 天分区;
3 个月内最大访问跨度<=30 天时,建议保留最近 33 天分区;
3 个月内最大访问跨度<=90 天时,建议保留最近 120 天分区;
3 个月内最大访问跨度<=180 天时,建议保留最近 240 天分区;
3 个月内最大访问跨度<=300 天时,建议保留最近 400 天分区;
(1) 存储及生命周期管理
建议按天分区。
(2) 事务型事实表设计准则
基于数据应用需求的分析设计事务型事实表,结合下游较大的针对某个业
务过程和分析指标需求,可考虑基于某个事件过程构建事务型实时表;
一般选用事件的发生日期或时间作为分区字段,便于扫描和裁剪; 冗余子集原则,有利于降低后续 IO 开销;
明细层事实表维度退化,减少后续使用 join 成本。
(3) 周期快照事实表
周期快照事实表中的每行汇总了发生在某一标准周期,如某一天、某周、
某月的多个度量事件。
粒度是周期性的,不是个体的事务。
通常包含许多事实,因为任何与事实表粒度一致的度量事件都是被允许的。
(4) 累积快照事实表
多个业务过程联合分析而构建的事实表,如采购单的流转环节。 用于分析事件时间和时间之间的间隔周期。
少量的且当前事务型不支持的,如关闭、发货等相关的统计。
数据仓库的性能是数据仓库建设是否成功的重要标准之一。聚集主要是通过汇总 明细粒度数据来获得改进查询性能的效果。通过访问聚集数据,可以减少数据库 在响应查询时必须执行的工作量,能够快速响应用户的查询,同时有利于减少不 同用访问明细数据带来的结果不一致问题。
(1) 聚集的基本原则
一致性。聚集表必须提供与查询明细粒度数据一致的查询结果。 避免单一表设计。不要在同一个表中存储不同层次的聚集数据。
聚集粒度可不同。聚集并不需要保持与原始明细粒度数据一样的粒度,聚
集只关心所需要查询的维度。
(2) 聚集的基本步骤
第一步:确定聚集维度
在原始明细模型中会存在多个描述事实的维度,如日期、商品类别、卖家等,这 时候需要确定根据什么维度聚集,如果只关心商品的交易额情况,那么就可以根 据商品维度聚集数据。
第二步:确定一致性上钻
这时候要关心是按月汇总还是按天汇总,是按照商品汇总还是按照类目汇总,如 果按照类目汇总,还需要关心是按照大类汇总还是小类汇总。当然,我们要做的 只是了解用户需要什么,然后按照他们想要的进行聚集。
第三步:确定聚集事实
在原始明细模型中可能会有多个事实的度量,比如在交易中有交易额、交易数量 等,这时候要明确是按照交易额汇总还是按照成交数量汇总。
(3) 公共汇总层设计原则
除了聚集基本的原则外,公共汇总层还必须遵循以下原则:
词根属于数仓建设中的规范,属于元数据管理的范畴,现在把这个划到数据治理 的一部分。完整的数仓建设是包含数据治理的,只是现在谈到数仓偏向于数据建 模, 而谈到数据治理,更多的是关于数据规范、数据管理。
表命名,其实在很大程度上是对元数据描述的一种体现,表命名规范越完善,我 们能从表名获取到的信息就越多。比如:一部分业务是关于货架的,英文名是: rack,rack 就是一个词根,那我们就在所有的表、字段等用到的地方都叫 rack, 不要叫成 别的什么。这就是词根的作用,用来统一命名,表达同一个含义。
指标体系中有很多“率”的指标,都可以拆解成 XXX+率,率可以叫 rate,那我 们所有的指标都叫做 XXX+rate。
词根:可以用来统一表名、字段名、主题域名等等。
举例: 以流程图的方式来展示,更加直观和易懂,本图侧重 dwm 层表的命名 规 范,其余命名是类似的道理:
第一个判断条件是该表的用途,是中间表、原始日志还是业务展示用的表 如果 该表被判断为中间表,就会走入下一个判断条件:表是否有 group 操作 通过是 否有 group 操作来判断该表该划分在 dwd 层还是 dwm 和 dws 层 如果不是 dwd 层,则需要判断该表是否是多个行为的汇总表 (即宽表) 最后再分别填上 事业群、部门、业务线、 自定义名称和更新频率等信息即可。
分层
:表的使用范围
事业群和部门
:生产该表或者该数据的团队
业务线
:表明该数据是哪个产品或者业务线相关
主题域
:分析问题的角度,对象实体
自定义
:一般会尽可能多描述该表的信息,比如活跃表、留存表等
更新周期
:比如说天级还是月级更新
数仓表的命名规范如下:
(1)数仓层次:
公用维度:dim
DM 层:dm
ODS 层:ods
DWD 层:dwd
DWS 层:dws
(2) 周期/数据范围:
日快照:d
增量:i
全量:f
周:w
拉链表:l
非分区全量表:a
(1) 常规表
常规表是我们需要固化的表,是正式使用的表,是目前一段时间内需要去维护去 完善的表。
规范:分层前缀[dwd|dws|ads]_部门_业务域_主题域_XXX_更新周期|数据范围
业务域、主题域我们都可以用词根的方式枚举清楚,不断完善。
更新周期主要的是时间粒度、 日、月、年、周等。
(2) 中间表
中间表一般出现在 Job 中,是 Job 中临时存储的中间数据的表,中间表的作 用 域只限于当前 Job 执行过程中,Job 一旦执行完成,该中间表的使命就完 成了, 是可以删除的 (按照自己公司的场景自由选择,以前公司会保留几天 的中间表 数据,用来排查问题) 。
规范:mid_table_name_[0~9 |dim]
table_name 是我们任务中目标表的名字,通常来说一个任务只有一个目标表。 这里加上表名,是为了防止自由发挥的时候表名冲突,而末尾大家可以选择自由
发挥,起一些有意义的名字,或者简单粗暴,使用数字代替,各有优劣吧,谨慎 选择。
通常会遇到需要补全维度的表,这里使用 dim 结尾。
如果要保留历史的中间表,可以加上日期或者时间戳。
(3) 临时表
临时表是临时测试的表,是临时使用一次的表,就是暂时保存下数据看看,后续 一般不再使用的表,是可以随时删除的表。
规范:tmp_xxx
只要加上 tmp 开头即可,其他名字随意,注意 tmp 开头的表不要用来实际使用, 只是测试验证而已。
(4) 维度表
维度表是基于底层数据,抽象出来的描述类的表。维度表可以自动从底层表抽象 出来,也可以手工来维护。
规范:dim_xxx
维度表,统一以 dim 开头,后面加上,对该指标的描述。
(5) 手工表
手工表是手工维护的表,手工初始化一次之后,一般不会自动改变,后面变更, 也是手工来维护。
一般来说,手工的数据粒度是偏细的,所以暂时统一放在 dwd 层,后面如果有 目标值或者其他类型手工数据,再根据实际情况分层。
规范:dwd_业务域_manual_xxx
手工表,增加特殊的主题域,manual,表示手工维护表。
(1) 公共规则
(2) 指标命名规范
结合指标的特性以及词根管理规范,将指标进行结构化处理。
参考
本文档规范依据来源参考: