数据仓库理论

发布时间 2023-11-29 16:11:37作者: 戴莫先生Study平台

数据仓库理论

数仓是一种思想,数仓是一种规范,数仓是一种解决方案!

1、数据处理方式

数据处理大致可以分为两大类:联机事务处理:OLTP(On_Line Transaction Processing)、联机分析处理OLAP(On_Line Analytical Processing)

image-20231127211534264

OLTP(On_Line Transactions Processing):中文名称是联机事务处理。其特点是会有高并发且数据量级不大的查询,是主要用于管理事务的系统。此类系统专注于short on-line-transactions如Insert,update,delete,Query操作。通常存在此类系统中的数据都是以实体对象模型来存储数据,并满足3NF(数据库第三范式)。

OLAP(On_Line Analytical Processing):中文名称是联机分析处理。其特点是查询频率较OLTP系统更低,通常会涉及到非常复杂的聚合计算。一般用于大数据分析,数据分析结果是宏观,用于决策层进行决策作用。

image-20231127212845109

2、数据建模

将经过系统分析后抽象出来的概念模型转化为物理模型

数据建模指的是对现实世界各类数据的抽象组织,确定数据库需管辖的范围、数据的组织形式等直至转化成现实的数据库。

  • ER建模

主要用于OLTP,主要用于基于联机事务处理,企业高度设计一个3NF模型的方法,用实体加关系描述的数据模型描述企业业务架构,站在企业角度面向主题的抽象,而不是针对某个业务流程的实体对象关系抽象。简而言之就是三大范式:第一范式每个列不能再分(原子性)。第二范式就是非主键完全依赖与主键。第三范式:属性不依赖其他非主键字段。(所有范式是在前面范式基础上叠加)

优点:规范性好,冗余小,数据集成和数据一致性方面得到重视。

缺点:需全面了解业务,成本昂贵,对建模人员要求高,容易烂尾。

  • 维度建模

以分析决策为需求构建模型,面向重点解决用于如何快速完成分析需求,同时还有较好的大规模复杂查询的响应性能,更直接面向业务。

重要概念=> 事实表:发生在现实世界中的操作事件,其产生的可度量数值,存储在事实表中。

维度表:每个纬度表都包含单一的主键列。

度量值:对一次行为的度量。

  • 总结
ER建模是面向应用,遵循三范式,以消除冗余为目标的技术。
维度建模以面向分析,为了提高查询性能可以增加数据冗余,反规范化的技术。
优点:技术要求不高,快速上手,敏捷迭代,快速交付。
缺点:维度表冗余比较多,视野狭窄。

image-20231127224024928

3、维度建模表分类

维度是纬度建模的基础和灵魂。在维度建模中,将度量称为事实,将环境描述为维度,维度是用于分析事实所需要的多样的环境。

特征:表范围很宽(具有多个属性、列比较多) 跟事实表相比,行数较少(通常小于10万条) 内容相对固定。

DWS:DataWareHouse Service(数据仓库服务)

DWD:DataWarehouseDetail(数仓详情)

ODS:Operation Data Store(操作数据存储)

ADS:Application Data Service(应用数据服务)

Dim:Dimension(维度表)

  • 举例说明
今天张三买了一瓶两块钱的矿泉水。
分析:“今天”,“张三”,“买”,“矿泉水”是维度,“一瓶”,“两块”是事实。
  • 维度表的设计原则
1、维度属性尽可能丰富,为数据打下基础,尽可能为维度表添加描述信息。
2、区分数值型属性和事实。一般用于查询约束条件和分组统计,则作为维度属性;用于参与度量的计算,则作为事实表。
3、沉淀出通用的维度属性,为建立一致性维度做好铺垫。
4、退化维度:把一些简单的维度表放进事实表中。
5、缓慢变化维:维度的属性并不是始终不变的,它会随着时间的流逝发生缓慢变化的维。
   处理方式:一、直接覆盖原值,不看历史数据,简单粗暴
           二、拉链表--在需要的维度行增加三列:有效日期、截止日期、行标识(可选)。
           三、增加属性列
例如:比如商品价格,可以用于查询约束条件或统计价格区间的商品数量,此时是作为维度属性使用的;也可以用于统计某类目下商品的平均价格,此时是作为事实使用的。

image-20231128202710684

  • 拉链表

image-20231128202833993

  • 增加属性列

image-20231128202904109

  • 总结

为了提升效率,把常用的维度冗余到事实表中。

  • 维度设计高级主题

维度整合:一、垂直整合:即不同的来源表包含相同的数据集,只是存储的信息不同。比如学生信息表、成绩表、课程表、老师表,每个表都以学号为关联字段,可以把所有表整合到学生信息表中(增加字段)。

二、水平整合:即不同的来源表包含不同的数据集,不同子集之间无交叉,也可以存在部分交叉。比如蚂蚁金服仓库,采集的数据有淘宝会员、1688会员、国际站会员、支付宝会员等,由于查询业务需求把所有会员整合到一张表中。通俗点讲把每个表中每行数据进行整合。

同时水平整合又要考虑,是否存在交叉,存在交叉需要去重。如果不存在交叉,则需要考虑不同子集的自然键是否存在冲突,如果不冲突,则可以考虑将各子集的自然键作为整合后的表的自然键;另一种方式是设置超自然键, 将来源表各子集的自然键加工成一个字段作为超自然键。比如qq、微信、qq炫舞、qq飞车同属腾讯的,腾讯为了查询账户信息,可以把表整合一起设置主键记录是:qq_123456,vx_123456,xw_123456,fc_123456

维度拆分:一、水平拆分:将维度的不同分类实例化为不同的维度,同时在主维度中保存公共属性;维护单一维度,包含所有可能的属性。

二、垂直拆分:维度属性的丰富程度直接决定了数据仓库的能力;尽可能丰富维度属性,进行反规范化处理。

  • 事实表的设计原则
1、尽可能包含所有与业务相关的事实。
2、只选择与业务过程相关的事实。
3、分解不可加性事实为可加组件。
4、在选择维度和事实之前必须先声明粒度--越细越好(最低级别的原子粒度开始)
5、在同一个事实表中不能有多种不同粒度的事实。
6、事实的单位要保持一致。比如时间日期格式、距离长度等
7、对事实的null值要统一处理,null值没处理好会导致数据倾斜或者无法计算。
8、使用退化维度提高事实表的易用性。
  • 事实表概念
事实表中的每行数据代表一个业务事件。“事实”表示的是业务事件的度量值(可以统计次数、个数、金额等)。

可加性事实是指可以按照与事实表关联的任意维度进行汇总。比如:销售记录表(事实表)对应商品销售事实,销售记录中是多个销售事实,其中销售金额是可以累加的,或者某个商品的销售金额可以累加。

半可加性事实只能按照特定维度汇总,不能对所有维度汇总,比如库存可以按照地点和商品进行汇总,而按时间维度把一年中每个月的库存累加起来则毫无意义。

不可加性事实,比如比率型事实。对于不可加性事实可分解为可加的组件来实现聚集。比如每个班的语文成绩及格率,把每个班的及格率进行相加,没有意义,但是全年级的语文及格成绩以及总人数是有意义的,可以求出全年级及格率。

相对维表来说,通常事实表要细长得多,行的增加速度也比维表快很多。
  • 事实表设计方法
1、选择业务过程以及确定事实表类型。
2、明确业务过程后,根据业务需求来选择与维度建模有关的业务过程。
3、声明粒度(粒度越细,数据越多,查询越复杂),确定维度、确定事实、冗余维度。
4、如果维度表能够进行复用,并且维度表字段较多,一般就不会进行退化。
  • 事实表分类
1、事务型事实表:单事务事实表(对每个业务设计一个事实表)、多事务事实表(一个事实表包含不同的业务过程)。
2、周期性快照事务表:周期型快照事实表中不会保留所有数据,只保留固定时间间隔的数据,以具有规律性的、可预见的时间间隔记录事实,例如每天或每月的总销售金额,或每月的账户余额等。
3、累积型快照事实表:跟踪事务变化,覆盖整个生命周期,通常多个日期字段记录时间点,业务过程进行时,事务表的记录也要不断更新。

image-20231128211634249

4、数据组织类型

维度建模按数据组织类型划分可分为星型模型、雪花模型、星座模型。

  • 星型模型

是一种多维的数据关系,它由一个事实表(Fact Table)和一组维表(Dimension Table)组成。每 个维表都有一个维作为主键,所有这些维的主键组合成事实表的主键。多维数据集每一个维度直接与事实表相连接。

image-20231128212054752

  • 雪花模型

当有一个或多个维表没有直接连接到事实表上,而是通过其他维表连接到事实表上时,其图解就像 多个雪花连接在一起。

雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化,原有的各维表可能被扩展为小 的事实表,形成一些局部的 "层次 " 区域,这些被分解的表都连接到主维度表而不是事实表。通过减少数据存储量,联合较小维表改善查询性能,去除数据冗余。

  • 星座模型

多个事实表共享多个维度表,因而当作星型模型的集合,故称为星座模型。

image-20231128212348388

  • 模型选择
模型的选择跟数据和需求有关系,跟设计没有关系。
星型还是雪花,取决于性能优先,还是避免冗余、灵活更优先。
实际企业开发中,一般不会只选择一种,需要根据情况灵活组合,甚至并存(一层维度和多层维度都保存)。
整体来看,更倾向于维度更少的星型模型。尤其是大型数据仓库项目,减少表连接的次数,可以显著提升查询效率。

5、维度表建模步骤

  • 选择业务处理过程>声明粒度>选择维度>确定事实

image-20231128212830057

选择业务:选择感兴趣的业务线,如下单,支付,退款,活动 。

声明粒度:一行代表信息:一条订单?一天的订单?一周的订单? 选择最小粒度。

确认维度:维度退化:谁 。 什么时间 什么地点:牢牢掌握事实表 的粒度,就能将所有可能存在的维度区分开,并且要确保维度表中不能出现重复数据,应使 维度主键唯一。

确认事实:度量值:如个数,件数,金额:是同一事实表中的所有度量必须具有相同的粒度。最实用的事实就是数值类型和可加类事实。

6、数据仓库分层

image-20231128221036850

  • 原因

用空间换时间:通过大量的预处理提升应用系统的用户体验,数仓会有大量冗余数据。

增强扩展性:不分层的话,如果源业务系统的业务规则发生变化将会影响整个数据清洗过程,工作量巨大.

分层管理:通过数据分层管理可以简化数据清洗的过程。

隔离原始数据:把原始数据异常隔离。

  • 优点

清晰数据结构、方便数据血缘追踪、把复杂问题简单化、屏蔽原始数据异常。

  • 介绍

ODS原始数据层:该层最接近数据源中数据的一层,数据源中的数据,经过抽取、洗净、传输,也就说传说中的ETL 之后,装入ODS层。

DW数据仓库层:该层从ODS层中获得的数据按照主题建立各种数据模型。四个概念:维度(dimension)、事实(Fact)、指标(Index)和粒度( Granularity)。还细分为DWS(Data WareHouse Service)、DWD(Data WareHouse Detail)、DIM(Dimension)

DWS:服务数据层,主要整合汇总最终的结果供应用表使用,一般存储大宽表和高度压缩表。

DWD:数据源的细节层,是业务层与数据仓库的隔离层,该层可以把业务表分的更细。此层一般用于维度建模、事实建模。

DIM:存放维度表层。

ADS:存放数据产品个性化的统计指标数据,一般会存放在ES、MySQL等系统中供线上系统使 用,也可能会存在Hive或者Druid中供数据分析和数据挖掘使用。

image-20231129090123946

7、阿里数仓架构

模型层级:阿里巴巴的数据团队把表数据模型分为三层:操作数据层(ODS) 、公共维度模型层(CDM)和应 用数据层(ADS) ,公共维度模型层包括明细数据层(DWD)和汇总数据层(DWS)。

image-20231129093021605

8、ETL

image-20231129093306131

TL是将业务系统的数据经过抽取、清洗转换之后加载到数据仓库的过程,目的是将企业中的分 散、零乱、标准不统一的数据整合到一起,为企业的决策提供分析依据。

数据抽取、数据清洗、库内转换、规则检查、数据加载。 各模块可灵活进行组合,形成ETL处理流程。

数据清洗转换:通常的做法是从业务系统到ODS做清洗,将脏数据和不完整数据过滤掉,在从ODS到DW的过 程中转换,进行一些业务规则的计算和聚合。不一致数据转换、数据细粒度转换、商务规则设计、空值处理、数据标准、数据拆分、数据验证、数据替换、数据关联。

  • ETL工具

数据整合解决方案,通俗点讲就是倒数据工具。

工具:Sqoop、DataX、Kettle、Canal、StreamSets

  • 加载策略

系统日志分析方式:通过分析数据库自身的日志来判断变化的数据。

触发器方式:直接进行数据加载 利用增量日志表进行增量加载。

时间戳方式:在源表上增加一个时间戳字段,系统中更新修改表数据的时候,同时修改时间戳字段的值。

全表对比方式:全表比对即在增量抽取时,ETL 进程逐条比较源表和目标表的记录,将新增和修改的记录读 取出来。

源系统增量数据直接或者转换后加载:全表比对即在增量抽取时,ETL 进程逐条比较源表和目标表的记录,将新增和修改的记录读 取出来。

9、常见概念描述

  • 数据仓库

数据仓库是一个面向主题、集成的、相对稳定的、反映历史变化的数据集合,用于支持管理中的决策制定的。

数据仓库是一个功能概念,是将企业的各业务系统产生的基础数据,通过维度建模的方式,将业务数据划分为多个主题(集市)统一存储,统一管理。

  • 数据集市

image-20231129095032409

数据集市可以理解为是一种"小型数据仓库",它只包含单个主题,且关注范围也非全局。数据集市分为:独立数据集市(集市有自己的源数据和ETL架构)、非独立数据集市(没有自己的源数据,来自数据仓库),数据集市是一个结构概念,是企业级数据仓库的一个子集,面向部门、面向主题。

  • 数据孤岛

业务系统之间各自为政,相互独立造成数据孤岛,业务不集成、流程不互通、数据不共享。

image-20231129095520675

  • 数据湖

数据湖是一种数据存储理念,存储企业各种各样的原始数据的大型仓库,包括结构化、非结构、 二进制图像、音频、视频等等。从源系统导入所有的数据,没有数据流失。数据存储时没有经过转换或只是简单的处理。数据转换和定义schema 用于满足分析需求。通俗点讲:就是存放未处理的数据存储理念。

image-20231129095856535

image-20231128170558941

  • 数据中台

image-20231129095929090

通过企业内外部多源异构的数据采集、治理、建模、分析、应用,使数据对内优化管理提高业务,对外数据合作价值释放,成为企业数据资产管理中枢。

数据中台是一个逻辑概念,为业务提供服务的主要方式是数据API,它包括了数据仓库,大数据、 数据治理领域的内容。

  • 宽窄表

宽表:通常是指业务主题相关的指标、维度、属性关联在一起的一张数据库表,不符合三范式模型,数据产生冗余,但是可以提高查询效率。

窄表:严格按照数据库设计三范式。尽量减少数据冗余,但是缺点是修改一个数据可能需要修改多表。

10、大数据架构

image-20231129100525144

大数据平台由上到下,可分为三个部分:数据采集、数据处理、数据输出与展示。

蓝色图案为大数据组件,红色图案为互联网组件

数据采集:将应用程序产生的数据和日志等同步到大数据系统中,由于数据源不同,这里的数据同步系 统实际上是多个相关系统的组合。数据库同步通常用 Sqoop,日志同步可以选择 Flume,打点采集的数据经过格式化转换后通过 Kafka 等消息队列进行传递。

数据处理:这部分是大数据存储与计算的核心,数据同步系统导入的数据存储在 HDFS。MapReduce、 Hive、Spark 等计算任务读取 HDFS 上的数据进行计算,再将计算结果写入 HDFS。

数据输出和展示:大数据计算产生的数据还是写入到 HDFS 中,但应用程序不可能到 HDFS 中读取数据,所以必 须要将 HDFS 中的数据导出到数据库中。应用程序就可以直接访问数据库中的数据,实时展示给用户,比如展示给用户关联推荐的商 品。

image-20231128163025909

  • Lambda架构(现在使用的架构)

image-20231129102459554

Lambda 架构总共由三层系统组成:批处理层(Batch Layer)速度处理层(Speed Layer),以及用于响应查询的服务层(Serving Layer)

批处理层:批处理层存储管理主数据集(不可变的数据集)和预先批处理计算好的视图。批处理层使用可处理大量数据的分布式处理系统预先计算结果。

速度处理层:速度处理层会实时处理新来的大数据。速度层通过提供最新数据的实时视图来最小化延迟。

服务层:批处理层和速度层处理完的结果都输出存储在服务层中,服务层通过返回预先计算的数 据视图或从速度层处理构建好数据视图来响应查询。

  • Kappa架构

image-20231129102941976

是一种架构思想,通俗点讲就是把流处理和批处理都在速度处理层进行处理,没有处理层。也就是我们说的流批一体。

缺点:缺少处理层,在速度层上处理大数据可能会出错,会耗费大量时间处理错误。

​ 把流处理和批处理放在同一层,就需要使用同一代码算法逻辑,不适用流批处理不一致的场景。

11、数据仓库元数据

  • 业务元数据

描述 ”数据”背后的业务含义 主题定义:每段 ETL、表背后的归属业务主题。

业务描述:每段代码实现的具体业务逻辑。

标准指标:类似于 BI 中的语义层、数仓中的一致性事实;将分析中的指标进行规范化。

标准维度:同标准指标,对分析的各维度定义实现规范化、标准化。 不断的进行维护且与业务方进行沟通确认。

  • 技术元数据

数据源元数据、ETL元数据、数据仓库元数据、BI元数据

  • 管理元数据

管理领域相关,包括管理流程、人员组织、角色职责等。