数仓知识1

文章详细阐述了数据仓库的五层结构(ODS、DWD、DWS、DWT、ADS)及其各自的功能,强调了维度建模在其中的重要性,包括星型模型、雪花模型和星座模型的差异。同时,提到了数据模型的选择策略和评估一个良好数据模型的标准。此外,还讨论了事务性事实表、周期性快照事实表等事实表类型以及数据治理的目的和流程。
摘要由CSDN通过智能技术生成

数仓分层

数仓分五层:ods,dwd,dws,dwt,ads.

1.ods层
(1)保持数据原貌不做任何修改,起到备份数据的作用。
(2)数据采用压缩,减少磁盘的存储空间。(例如将原始数据100G压缩到10G左右)
(3)创建分区表,防止后续的全表扫描。

2.dwd层
dwd层需要构建维度模型,一般采用星型模型,呈现的状态一般为星座模型。
在dwd层以业务过程为建模驱动,基于每个具体业务过程的特点,构建最细粒度的明细事实表。事实表可做适当的宽表化处理。
根据维度建模中星型模型思想,将维度进行退化。例如,将地区表和省份表退化为地区维度表,活动信息表和活动规则表退化为活动维度表。

3.dws层
dws层统计当天主题对象的当天行为。服务于dwt层的主题宽表。dws层的宽表字段,是站在不同维度的视角看待事实。重点关注事实表的度量值。
按天轻度汇总

4.dwt层
以分析的主题对象作为建模驱动,基于上层的应用和产品的指标需求,构建主题对象的全量宽表。
从dws层按主题汇总

5.ads层
分别对各种主题进行指标分析。

四种常见数据模型

维度建模 范式(关系型)建模 Data Vault模型、Anchor模型

维度建模 关系型建模
关系型建模就是把数据抽象成实体和关系,严格遵循第三范式(3NF),数据冗余程度低,数据的一致性容易得到保证。由于数据分布于众多的表中,查询会相对复杂,在大数据的场景下,查询效率相对较低。
维度模型以数据分析作为出发点,不遵循三范式,故数据存在一定的冗余。维度模型面向业务,将业务用事实表和维度表呈现出来。表结构简单,故查询简单,查询效率较高。

了解哪些维度模型/维度建模中的几种模型:星型模型、雪花模型、星座模型
星型模型 雪花模型
星型模型,雪花模型,星座模型的区别
雪花模型的优点是什么 1、结构扩展灵活;2、降低冗余;3、方便更新
标准的星型模型维度只有一层,以事实表为中心,所有维度直接关联在事实表上,呈星型分布
雪花模型比较靠近第三范式(遵循第三范式成本高),在星型模型的基础上,维度表上又关联了其他维度表。这种模型维护成本高。性能方面也较差,所以一般不建议使用。尤其是基于hadoop体系构建数仓,减少join就是减少shuffle,性能差距会很大。
星座模型和前两种区别就是事实表的数量,星座模型基于多个事实表,多个事实表共享维度表

维度建模的理解 :维度模型的出现,就是为了解决大数据量导致的查询慢的问题。
选择策略:首先是否选择星座模型跟数据和业务有关,和设计没关系。星型模型还是雪花模型取决于是想选择性能优先还是灵活度优先
我了解到的企业业务不会绝对性的选择星型模型或者雪花模型,甚至两者并存(但是更倾向于星型模型尤其是)

怎么算是一个好的数据模型/数仓

1、业务过程清晰
2、指标好理解
3、核心模型相对稳定
4、高内聚低耦合

事实表有什么类型,三种类型有什么区别 (了解哪些事实模型)

事实表通常细,列少 

数据仓库维度建模的核心,紧紧围绕着业务过程来设计。其包含与业务过程有关的维度引用(维度表外键)以及该业务过程的度量(通常是可累加的数字类型字段)。
事务性事实表,周期性快照事实表,累加性快照事实表

事务性事实表每个事务或事件为单位,粒度最小,一旦事务被提交,事实表数据被插入,数据就不再进行更改,其更新方式为增量更新
选择业务过程→声明粒度→确认维度→确认事实
选择业务过程:一般一个业务过程对应一个事务性事实表
声明粒度:即精确定义每张事务型事实表的每行数据表示什么,应该尽可能选择最细粒度
确认维度:确定与每张事务型事实表相关的维度有哪些。
确认事实:每个业务过程的度量值
其逻辑可能会比较复杂,或者效率会比较低下

周期性快照事实表不会保存所有数据,只保存一段时间的数据具有规律性的、可预见的时间间隔来记录事实,主要用于分析一些存量型或者状态型指标
确定粒度→确定事实
确定粒度:用周期和维度(统计指标)表示
确定事实:根据维度(统计指标表示)(这个事实是指度量值值的类型)
可加事实:指可以按照与事实表相关的所有维度进行累加,例如事务型事实表中的事实。
半可加事实:只能按照与事实表相关的一部分维度进行累加,不能按照时间维度进行累加因为没意义
不可加事实:不可加事实是指完全不具备可加性,通常需要转化为可加事实
累积性快照事实表:用与跟踪业务事实的变化
使用累积型快照事实表进行统计,就能避免两个事务事实表的关联操作,从而变得十分简单高效。
选择业务过程→声明粒度→确认维度→确认事实。
1)选择业务过程:选择一个业务流程中需要关联分析的多个关键业务过程,多个业务过程对应一张累积型快照事实表。
2)声明粒度:精确定义每行数据表示的是什么,尽量选择最小粒度
3)确认维度:选择与各业务过程相关的维度,需要注意的是,每各业务过程均需要一个日期维度。
4)确认事实:选择各业务过程的度量值。

维度 粒度的区别区别粒度 维度
维度是我们描述事实的角度。
事实是一条业务中度量的集合。
度量是业务中产生的一个数值。
粒度是度量的单位

多维体系结构

总线架构(总线矩阵),一致性维度,一致性事实
总线架构:两部分:前台,后台。
后台称为数据准备去,核心部件,一致性维度产生,保存和分发的场所
前台时对外的接口:两种数据集市:原子数据集市,聚集数据集市
两种集市都用星型结构存储
原子数据集是保存低粒度的细节数据,聚集数据集市比原子数据集是高

一致性维度
起源:多维体系结构中,没有物理上的数据仓库,由物理数据集市组合成逻辑上的数仓,最终组合在一起成为一个数仓,如果分布建立集市的过程出问题,数据集市就会成为孤立的集市,无法组成数仓,一致性维度的提出为解决这个问题

在同一个集市内,一致性维度的以上就是两个维度如果由关系,要么完全一样,要么就是一个维度在数学意义上时另一个维度的子集

一致性事实
建立多个数据集市时完成一致性维度完成了一致性的百分之八十,剩下的就是建立一致性事实。
一致性维度和一致性事实区别在于
一致性维度发生修改时同步复制到每个数据技术。
一致性事实需要查询多个数据技术中的事实,一般通过交叉探查实现
为了进行交叉探查,要保证1:kpi的定义和计算方法一直,2、事实的单位要一致

维度表

是什么
度量称为事实,环境描述为维度

退化维度
退化维度的相关数据迁移到事实表中,然后删除退化的维度。一般分组用
缓慢变化维
随着时间发生缓慢变化的维度,一般使用代理键作为维度表的主键
三种常用处理方式:直接覆盖原值,拉链表(增加有效日期,截止日期,行表示),增加列属性

维度表设计方法:
1、选择维度或者新建维度
2、确定主维表
3、确定相关维表
4、确定维度属性

三范式和反范式

第一范式列不可再分
第二范式不存在部分依赖
第三范式不存在传递依赖
优点:减少冗余,更新操作快,空间少
缺点:如果对多个表关联查询性能降低,更难进行索引优化

反范式化:
优点:减少表关联,更好进行索引优化
缺点:存在大量冗余,维护成本高

Lambda和Kappa

路线:经典数仓架构–(数据量暴增)–>离线大数据架构–(实时性)—>lambda架构—(多业务,多数据源没时间行数据源)—>kappa架构

lambda架构
三层:Batch Layer,Speed Layer,Serving Layer
Batch Layer复制数据存储和全量数据集的预查寻
Speed Layer负责对增量数据计算生成Realtime Views
Serving Layer响应用户查询请求
缺点
实时与批量计算结构不一致导致数据口径问题
批量计算在计算窗口内无法完成
开发和维护复杂性问题
服务器存储大

kappa架构
核心思想
kafka或类似的分布式队列系统保存数据
需要全量重新计算时重启一个流计算实例,从头开始读取数据进行处理,输出到一个新的结果存储中
新的实例做完后停止老的流计算实例,把老的结果删除
只有必要的时候才会对历史数据进行重复计算,并且实时计算和批处理过程用同一份代码

lambda把全量历史数据和实时增量数据合并输出
kappa两个流写作输出,queries每次使用最新一个流处理结果

数据治理

是什么
管理数据的行为,提高数据质量

目的
降低风险,降低成本,增加数据价值,方便管理等

流程
发现数据质量问题>定义数据质量规则>质量控制>质量评估>质量优化

方法
理采存管用
业务和数据资源梳理
数据采集清洗
数据库设计和存储
数据管理
数据使用

OLAP

olap和oltp区别
oltp面向业务开发人员。olap面向决策人员
oltp日常事务处理 ---- ,olap面向分析决策
oltp关系模型 ---------- ,olap多为模型
数据少 ------------------- ,数据量大
联机事务处理----------- ,在线分析处理

分类
MOLAP:基于多维数组,明细和聚合都在cube中
ROLAP:基于关系型模型,明细和汇总都在关系型数据库
HOLAP:细节数据以ROLAP,聚合数据以MOLAP

基本操作
钻取,上卷,切片,切块,旋转

数据倾斜

表现
hadoop:

  • 几个或者一个Reduce卡住不能结束
  • 各种container报错OOM
  • 一场的reducer读写数据量远大于其他正常reducer
  • 任务被kill

hive:
一般在group by 和join on上
spark:

  • executor lost,OOM,Shuffle过程出错
  • Driver OOM
  • 单个Executor执行时间特别久,整体任务卡在某个阶段不能结束
  • 正常的任务突然失败

原因
1)key分布不均匀
2)建表考虑不周
3)业务数据激增

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值