2023.11.22 -数据仓库的概念和发展

https://blog.csdn.net/m0_49956154/article/details/134320307?spm=1001.2014.3001.5501

1经典传统数仓架构

2离线大数据数仓架构

3数据仓库三层

数据运营层,源数据层（ODS）（Operational Data Store）

数据仓库层（DW）（Data Warehouse）

数据应用层ADS(Application Data Service)

事实表(Fact Table)

维表层(Dimension)

4数据仓库和数据库的区别(t数据库,a仓库)

5.关系模型(ER模型+三范式)

E-R模型（Entity-relationship model）

5.1.三范式

概述:

一、3NF知识点

5.2反范式化

概述

补充之前的 :2023.11-9 hive数据仓库,概念,架构,元数据管理模式

https://blog.csdn.net/m0_49956154/article/details/134320307?spm=1001.2014.3001.5501

1经典传统数仓架构

阶段一: 1991年比尔-恩门（bill inmon）出版第一版数据仓库的书, 标志数据仓库概念的确立, 称为恩门模型
   主张自上而下的建设企业级数据仓库, 建设过程中需要满足三范式要求
   从分散异构的数据源 -> 数据仓库 -> 数据集市

   存在问题:
       由于三范式的建模,导致在数据分析中数据易访问性和系统的性能均收到影响

阶段二: 拉尔夫·金博尔（ralph kimball）提出自下而上的建立数据仓库，整个过程中信息存储采用维度建模而非三范式
   从数据集市-> 数据仓库 -> 分散异构的数据源

   优点:
       提出了维度建模新思路, 完全以数据分析便利性为前提建设, 推出了事实-维度模型
       以最终任务为导向, 需要什么, 我们就建立什么

   弊端:
       随着业务的发展, 导致数据集市越来越多, 出现多个数据集的数据混乱和不一致的情况

阶段三: 1998年比尔-恩门（bill inmon）推出全新的CIF架构, 核心将数仓架构划分为不同的层次以满足不同场景的需求
   如: ODS DW DA层等

   从而明确各个层次的任务分工, 避免原有数据混乱和不一致的问题

   而这种思想已经成为截止到今天的建设数据仓库的指南

2离线大数据数仓架构

大数据中的数据仓库构建就是基于经典数仓架构而来，使用大数据中的工具来替代经典数仓中的传统工具，架构建设上没有根本区别

项目架构图

集群管理工具: Cloudera Manager
数据源: 业务系统的Mysql与SQLServer数据库；
数据抽取: 使用DataX实现关系型数据库和大数据集群的双向同步；
数据存储: HDFS
计算引擎: Hive
交互查询引擎: Presto
OLAP: PG
数据可视化: Fine Report
调度系统: DolphinScheduler(海豚调度)

3数据仓库三层,四大特性

1- 面向主题: 分析什么什么就是我们的主题
2- 集成性: 数据从各个数据源汇聚而来, 数据的结构都不一定一样
3- 非易失性(稳定性): 存储都是过去历史的数据, 不会发送变更, 甚至某些数据仓库都不支持修改操作
4- 时变性: 随着时间推移, 将最近发生的数据也需要放置到数据仓库中, 同时分析的方案也无法满足当前需求, 需要变更分析的手段

数据运营层,源数据层（ODS）（Operational Data Store）

数据运营层ODS(Operation Data Store) -也就是最接近数据源的一层，直接对接的数据源（如：业务库、埋点日志、消息队列等）。ODS数数仓的最底层。

该层是存储数量最大的、未经过太多处理的、最原数据始的一层。该层还起到一个数据备份的作用，比如特殊的行业，一般ODS层需要存储一年甚至多年，不过普通公司一般存储三个月到六个月。

一般情况下，在数据进入ODS层的时候，都会对数据做一些最基本的处理。例如：

数据来源分区
数据按照时间分区存储，一般按照天分区，也有一些公司按照年、月、日三级分区存储
进行最基本的数据处理，如格式错误的丢弃、过滤掉关键信息丢失的数据。

注意：一般公司也会把以上的基本处理放到DWM层来进行。

数据仓库层（DW）（Data Warehouse）

DWD(Data WareHouse Detail) -数据细节层。该层与ODS层保持相同的数据颗粒度，区别在于，改成主要是对ODS层进行数据的清洗和规范化操作，比如说去除空数据、脏数据等。该层由于对数据处理的粒度比较细，一般情况下都是编写代码实现的。很多时候存储的是事实表、维度表和实体表。
DWM(Data WareHouse Middle) -数据中间层。该层主要是对DWD层做一些轻微的聚合操作，生成一些指标列的聚合结果表。
DWS(Data WareHouse Service) -数据服务层。该层是在DWM层基础之上，整合汇总成一个主题域的数据服务层，一般是宽表（具有多个列的表），该层为后续的业务查询、OLAP分析和数据分发提供支撑。

数据应用层`ADS(Application Data Service)`

数据应用层ADS(Application Data Service) -该层主要为数据产品和数据分析提供数据支撑。一般会存放在ES、MySQL、Redis等数据库系统中，为应用系统提供数据，也可以存放在hive或者Druid中，供数据分析与数据挖掘使用，比如数据报表就是存在该层中。

事实表`(Fact Table)`

事实表是指存储有事实记录的表，比如系统日志、销售记录等。事实表的记录在不断地增长，比如电商的商品订单表，就是类似的情况，所以事实表的体积通常是远大于其他表。

维表层(`Dimension`)

维度表（Dimension Table）或维表，有时也称查找表（Lookup Table），是与事实表相对应的一种表；它保存了维度的属性值，可以跟事实表做关联，相当于将事实表上经常重复出现的属性抽取、规范出来用一张表进行管理。

4数据仓库和数据库的区别(t数据库,a仓库)

数据库与数据仓库的区别:实际讲的是OLTP与OLAP的区别
OLTP（On-Line Transaction Processin）:叫联机事务处理，也可以称面向用户交易的处理系统，主要面向用户进行增删改查

OLAP（On-Line Analytical Processing）:叫联机分析处理,一般针对某些主题的历史数据进行分析主要面向分析,支持管理决策。

数据仓库主要特征:面向主题的（Subject-Oriented ）、集成的（Integrated）、非易失的（Non-Volatile）和时变的（Time-Variant）

数据仓库的出现，并不是要取代数据库,主要区别如下:

数据库是面向事务的设计，数据仓库是面向主题设计的。
数据库是为捕获数据而设计，数据仓库是为分析数据而设计
数据库一般存储业务数据，数据仓库存储的一般是历史数据。
数据库设计是尽量避免冗余，一般针对某一业务应用进行设计，比如一张简单的User表，记录用户名、密码等简单数据即可，符合业务应用，但是不符合分析。
数据仓库在设计是有意引入冗余，依照分析需求，分析维度、分析指标进行设计。

5.关系模型(ER模型+三范式)

E-R模型（Entity-relationship model）

表示：
实体：用矩形框表示。
属性：实体的属性用椭圆框表示。
联系：实体间的联系用菱形框表示，并在连线上标明联系的类型，即1—1、1—n或m—n。

两个实体之间的联系
一对一（1:1）：

一对多（1：n）

多对多（m:n）

5.1.三范式

概述:

在关系型数据库中，关于数据表设计的基本原则，规则就称为范式。可以理解为，一张数据表的设计结构需要满足的某种设计标准的级别。想要设计一个结构合理的关系型数据库，必须满足一定的范式（规则）。

范式的英文名称是Normal Form，简称NF。它是英国人E.F.codd（埃德加·弗兰克·科德）在上个世纪70年代提出关系数据库模型后总结出来的。范式是关系数据库理论的基础，也是我们在设计数据库结构过程中所要遵循的规则和指导方法。

1981年，科德因在关系型数据库方面的贡献获得了图灵奖。他也被誉为：“关系数据库之父”

3NF知识点

设计关系数据库时，遵从不同的规范要求，设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式，各种范式呈递次规范，越高的范式数据库冗余越小。

根据数据库冗余的大小,目前关系型数据库有六种范式,各种范式呈递次规范，越高的范式数据库冗余越小。注意: 范式就是设计数据库的通用规范,一般遵循前三种范式即可

第一范式（1NF）

第二范式（2NF）

第三范式（3NF）

巴斯-科德范式（BCNF）

第四范式 ( 4NF）

第五范式（5NF，又称完美范式）

第一范式（1NF）: 强调的是列的原子性，即列不能够再分成其他几列,不可再分解；。

第二范式（2NF）: 满足 1NF的基础上，另外包含两部分内容,要求记录有惟一标识，即实体的惟一性

一是表必须有一个主键；

二是非主键字段必须间接或直接的依赖于主键

第三范式（3NF）: 满足 2NF的基础上，3NF是对字段冗余性的约束，即任何字段不能由其他字段派生出来，它要求字段没有冗余。另外包含

非主键列必须直接依赖于主键，不能存在传递依赖。

即不能存在：非主键列 A 依赖于非主键列 B，非主键列 B 依赖于主键的情况。

5.2反范式化

概述

有的时候不能简单按照规范要求设计数据表，因为有的数据看似冗余，其实对业务来说十分重要。这个时候，我们就要遵循业务优先的原则，首先满足业务需求，再尽量减少冗余。

如果数据库中的数据量比较大，系统的UV和PV访问频次比较高，则完全按照MySQL的三大范式设计数据表，读数据时产生大量的关联查询，在一定程度上会影响数据库的读性能。如果我们想对查询效率进行优化，反范式优化也是一种优化思路。此时，可以通过在数据表中增加冗余字段来提高数据库的读性能。