第二章数据仓的设计与构建

最新推荐文章于 2024-11-09 17:00:58 发布

测试小书童

最新推荐文章于 2024-11-09 17:00:58 发布

阅读量655

点赞数

分类专栏：大数据测试文章标签： big data hadoop

本文链接：https://blog.csdn.net/m0_57824522/article/details/124669043

版权

大数据测试专栏收录该内容

5 篇文章 2 订阅

订阅专栏

本文详细介绍了数据仓库的概念，包括其作为BI基础、四大特点及核心功能。数据仓库通过ETL过程从源数据清洗转换后存储。数据集市、数据湖和数据中台各有侧重，数据仓库常采用分层架构设计，如ODS、DWD、DWS等层。此外，还讨论了数据仓库建模方法，如范式建模、维度建模和实体建模，以及构建数据仓库的自顶向下和自底向上两种策略。最后，提到了数据仓库实例及构建步骤。

摘要由CSDN通过智能技术生成

这个是大数据测试系列第二章，点击查看第一章

什么是数据仓

是BI（商业智能）、报表和数据挖掘等应用的基础
大量的数据集合，4个特点主要包括：面向主题的、集成的、相对稳定的、反应历史变化的
数据仓至少需要具备数据获取、数据存储、数据访问3个核心功能，这3个功能的实现过程是数据源到最终决策应用的流转过程。下图为数据流转图：
数据获取和数据存储这两个功能主要由ETL工具支撑。ETL是指从数据源提前，经过清洗、转换等过程，并最终存储到目标数据仓库的过程。如下图所示，ETL过程3个步骤

在这里插入图片描述

为什么要用ETL

数据仓库、集市、数据湖、中台区别

数据集市

数据仓库面向企业全局业务，而数据集市面向部门级业务

在这里插入图片描述

数据湖

数据存储结构：数据仓主要存储和处理历史数据的机构化数据，而数据湖能存储结构和非结构化所有格式的数据
数据转换处理：数据仓库需要对源数据进行清洗、转换等预处理，以和定义好的数据模型相吻合；而数据湖是从源数据导入，无数据流失，随去随用，只有在使用的时候对数据转换等处理
数据场景：数据仓通常充当商业智能系统、数据仪表盘等可视化报表服务的数据源角色，支持历史分析；数据湖可以作为数据仓库或数据集市的数据源，更适合进行数据的挖掘、探索和预测，

数据中台

由阿里巴巴提出，就是用大数据技术统一处理数据，然后提供API给外部使用，数据中台保护数据仓库和其他服务器中间件

数据仓库的设计

架构分层设计

数据仓库通常可分为数据接入层、数据明细层、数据汇总层、数据集市层、数据应用层、临时层和公共维度层。其中数据明细层和数据汇总层又合称为数据仓库层。

数据接入层ODS

（Operational Data Store，ODS），也称数据贴源层，通常从业务数据库直接导入，为了考虑后续可能需要追溯数据问题，因此对于这一层就不建议做过多的数据清洗工作，原封不动地接入原始数据即可，至于数据的去噪、去重、异常值处理等过程可以放在后面的DWD层来做

数据明细层DWD

(Data Warehouse Detail，DWD) ，这层和 ODS 层保持一样的数据结构，只不过在从 ODS 里抽取到 DWD 的时候这个过程叫 ETL，后面我们会再讲 ETL，在抽取时对数据进行清洗加工，提供一定的数据质量保证，提供更干净的数据。

数据汇总层DWS

（Data Warehouse Summary, DWS），对各个表进行JOIN操作，产生业务所需要的完整数据。该层主要存放明细事实宽表、聚合试试宽表等。

数据集市层DWM

也叫数据中间件，(Data Warehouse Middle,DWM)，该层是在DWD层的数据基础上，对数据做一些轻微的聚合操作，生成一些列的中间结果表，提升公共指标的复用性，减少重复加工的工作。
简答来说，对通用的核心维度进行聚合操作，算出相应的统计指标
从广度来说，它包含了所有的业务数据

数据应用层

该层中，数据高度汇总，数据粒度较大，但不一定涵盖所有业务数据，也可能只是数据集市层数据的一个子集。
该层主要是提供给数据产品和数据分析使用的数据，一般会存放在ES、Redis、PostgreSql等系统中供线上系统使用；也可能存放在hive或者Druid中，供数据分析和数据挖掘使用，比如常用的数据报表就是存在这里的

临时层TMP

临时存放一些中间数据计算结果

公共维度层

主要负责一些一致性维度建设，如地点区域表、时间维度表等，数据仓库的各层均可使用此层

数据仓库建模方法

主要有范式建模、维度建模、实体建模

范式建模

是数据仓库逻辑模型设计的基本理论，在数据仓库的模型设计中，一般采用第三范式。一个符合第三范式的关系必须具有以下三个条件:

每个属性的值唯一,不具有多义性;
每个非主属性必须完全依赖于整个主键,而非主键的一部分;
每个非主属性不能依赖于其他关系中的属性,因为这样的话,这种属性应该归到其他关系中去

维度建模

是经典的面向分析的数据仓库建模方法。对数据进行分析时使用的度量。例如：抽取近10年的信用卡数据，分析年申请趋势
经常出现实体表、维度表和事实表等
- 实体表，用于存放商品的属性信息
- 维度表，按照某个分析维度来组织的事实描述，如分析某商品近半年来每月下单量，则表中一定存在时间字段属性。
- 事实表，是维度表各个维度的交点，如某商品在某地某月的销售额
在维度建模的基础上又分为三种模型：星型模型、雪花模型、星座模型。

星型模式

在这里插入图片描述

雪花模式

在这里插入图片描述

星型模型和雪花模型实例

在这里插入图片描述

星座模式

星座模式是星型模式延伸而来，星型模式是基于一张事实表的，而星座模式是基于多张事实表的，而且共享维度信息。

在这里插入图片描述

星座模型与前两种情况的区别是事实表的数量,星座模型是基于多个事实表。
基本上是很多数据仓库的常态,因为很多数据仓库都是多个事实表的。所以星座不星座只反映是否有多个事实表,他们之间
是否共享一些维度表。所以星座模型并不和前两个模型冲突。

模型的选择

首先就是星座不星座这个只跟数据和需求有关系,跟殳计没关系,不用选择。星型还是雪花,取决于性能优先,还是灵活更优先。
目前实际企业开发中,不会绝对选择一种,根据情况灵活组合,甚至并存(一层维度和多层维度都保存)
但是整体来看,更倾向于维度更少的星型模型。尤其是hadoop体系,减少Join就是减少 Shuffle,性能差距很大。(关系型数据可以依靠强大的主键索引)

实体建模

在数据仓建模中不常见，一般适用与业务建模和领域概念建模阶段

数据仓库构建

数据仓库的构建方法

构建方法主要包括自顶向下和自底向上

自顶向下实现

自顶向下的实现需要在项目开始时完成更多计划和设计工作，这就需要涉及参与数据仓库实现的每个工作组、部门或业务线中的人员。要使用的数据源、安全性、数据结构、数据质量、数据标准和整个数据模型的有关决策一般需要在真正的实现开始之前就完成。
此构建方法，实施周期长，难道略大

自底向上实现

自底向上的实现包含数据仓库的规划和设计，无需等待安置好更大业务范围的数据仓库设计。这并不意味着不会开发更大业务范围的数据仓库设计；随着初始数据仓库实现的扩展，将逐渐增加对它的构建。现在，该方法得到了比自顶向下方法更广泛的接受，因为数据仓库的直接结果可以实现，并可以用作扩展更大业务范围实现的证明。

两者结合

两者结合的折中实现：每种实现方法都有利弊。在许多情况下，最好的方法可能是某两种的组合。该方法的关键之一就是确定业务范围的架构需要用于支持集成的计划和设计的程度，因为数据仓库是用自底向上的方法进行构建。在使用自底向上或阶段性数据仓库项目模型来构建业务范围架构中的一系列数据集市时，您可以一个接一个地集成不同业务主题领域中的数据集市，从而形成设计良好的业务数据仓库。这样的方法可以极好地适用于业务。在这种方法中，可以把数据集市理解为整个数据仓库系统的逻辑子集，换句话说数据仓库就是一致化了的数据集市的集合。