目录
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的三大范式设计数据表，读数据时产生大量的关联查询，在一定程度上会影响数据库的读性能。如果我们想对查询效率进行优化，反范式优化也是一种优化思路。此时，可以通过在数据表中增加冗余字段来提高数据库的读性能。
![【Mysql】[Err] 1293 - Incorrect table definition；](https://img-blog.csdnimg.cn/9a52fb68d8424b9387eb1d7c6cef3835.png)
