数据湖学习笔记No.03（数据仓库）

数据仓库

资料链接：https://cloud.fynote.com/share/d/f3WMWzN

数据分析业务痛点分析

业务系统数据：存放在关系数据库中

用户日志数据：用户在系统中产生

java web为什么需要大数据？

数据存储有瓶颈

数据计算有瓶颈

实时场景计算有瓶颈

数据挖掘有瓶颈

构建大数据平台基础知识

数据库三范式：

1、第一范式（1NF）：原子性，字段不可分

2、第二范式（2NF）：唯一性，有主键，非主键字段依赖主键

3、第三范式（3NF）：非主键字段不能相互依赖

ER:Entity-Relationship实体关系模型

1、抽象实体
2、找出实体之间的关系

为什么要构建数据仓库？

1、数据存储在互不兼容的系统中

2、关系型数据库一般不存储日志数据（日志数据是一个文件或文件中的数据，每次在控制应用程序中发生特定事件时都会写入该文件。）

3、决策者需要从商业阶段观察数据，关系型数据库不适合

数据仓库DW-DWH

数据仓库是面向主题的、集成的（消除歧义、字段统一化的处理）、相对稳定的、反应历史变化的数据集合
TiDB mysql

发展历程中存在的主要问题

数据仓库发展过程中存在一个重要的问题：是否按照范式化建模？

按照范式化建模效率低，不按照范式化建模会导致数据不一致

因此，比尔.恩门提出CIF架构：数仓分层，不同层采用不同建模方式

维度建模

维度建模主要面向分析场景

事实表：发生在现实世界里的操作型事件（维度+度量=fact）

维度表：维度表包含了维度的每个成员的特定名称

数据分析模型

星形模型：当所有的维度表都由连接键连接到事实表时，结构图如星星一样，这种分析模型就是星型模型。（违反范式，存在数据冗余，分析效率高）

雪花模型：当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其结构图就像雪花连接在一起，这种分析模型就是雪花模型。（不违反范式，不存在数据冗余，但分析效率较低）

分层设计

自下而上

1、ODS层（操作数据层）：直接存放业务系统抽取过来的数据

2、DW层（数据仓库）：按照主题建立各种数据模型

​ （1）DWD层（数据明细层Detail）：在ODS基础上对数据进行加工处理，提供更干净的数据

​ （2）DWM层（数据中间层Middle）：对通用的数据进行轻度的聚合

​ （3）DWS层（数据服务层Service）：按照主题业务，组织主题宽表，用于OLAP分析。

3、DM层（Data Market）数据集市层：基于DW的基础数据，整合汇总成某一主题域的报表数据。

范式建模必须符合准三范式设计规范，如果使用混合建模，则源表也需要符合范式建模的限制，即源数据须为操作型或事务型系统的数据。通过ETL抽取转换和加载到数据仓库的ODS层，ODS层数据与源数据是保持一致的，所以ODS层数据也是符合范式设计规范的，通过ODS的数据，利用范式建模方法，建设原子数据的数据仓库EDW，然后基于EDW，利用维度建模方法建设数据集市。

分层的好处

1. 清晰的数据结构
2. 减少重复开发
3. 统一的数据出口
4. 简化问题

数据库与数据仓库的区别

数据库 OLTP 数据仓库 OLAP
T+1

功能	数据库	数据仓库
数据范围	当前状态数据	存储完整、反映历史变化的数据
数据变化	频繁增删改查操作	仅仅支持增加、查询数据操作
数据变化	面向业务交易流程	面向分析、侧重决策分析
数据变化	频繁、小批次、高并发、低延迟	非频繁、大批量、高吞吐、有延迟
数据变化	遵循数据库三范式、数据冗余	违范式、适当冗余
数据变化	ER实体关系模型（范式建模）	范式建模+维度建模

范式建模：是由Inmon提出的，这种建模方式在理论上符合三范式，但是不同于关系数据库中的三范式，这里的三范式是在企业角度面向主题的抽象，是自上而下的，以数据源头为导向，然后一步步探索获取尽量符合预期的数据，因为数据源往往是异构的，所以会更加强调数据的清洗工作，将数据抽取为实体-关系模型，并不强调事实表和维度表的概念。
范式建模的优点：能够结合业务系统的数据模型，较方便的实现数据仓库的模型；同一份数据只存放在一个地方，没有数据冗余，保证了数据一致性；数据解耦，方便维护。
范式建模的缺点：表的数量多；查询时关联表较多使得查询性能降低。

维度建模：是由Kimball提出的，是以最终任务为导向，将数据按照目标拆分出不同的表需求，数据会抽取为事实-维度模型，数据源经ETL转化为事实表和维度表导入数据集市，以星型模型或雪花模型等方式构建维度数据仓库
维度建模的优点：模型结构简单，面向分析，为了提高查询性能可以增加数据冗余，反规范化的设计，开发周期短，能够快速迭代。
维度建模的缺点：数据会大量冗余，预处理阶段开销大，后期维护麻烦；还有一个问题就是不能保证数据口径一致性。

OLTP（on-line transaction processing）翻译为联机事务处理， OLAP（On-Line Analytical Processing）翻译为联机分析处理，从字面上来看OLTP是做事务处理，OLAP是做分析处理。从对数据库操作来看，OLTP主要是对数据的增删改，OLAP是对数据的查询

大数据架构的演变

传统大数据离线结构

Lambda传统架构（离线处理+实时链路） 传统实时开发

缺点：重复开发多

实时链路是烟囱式开发，数据不能复用

Lambda架构（离线数仓+实时数仓）

实现了分层，但存在问题：
1、同样需求需要开发两套相同代码
2、集群资源使用增多
3、离线与实时结果不一致
4、批量计算T+1计算不完
5、服务器存储大

Kappa架构 (纯实时数仓)

Kafka做消息的缓存
Kappa框架缺点：
1、Kafka无法支撑海量数据存储
2、不支持SQL查询，无法支持高效的OLAP
3、无法复用数据血缘管理体系
4、（最致命）Kafka不支持update/insert
互联网公司实时业务多混合架构
绝大多数实时业务采用Kappa架构，关键核心业务使用离线全量计算方式（Lambda)

批流一体

批式大数据称为历史大数据 流式大数据称为实时大数据

1. 架构角度
2. 计算框架角度 一个计算框架既可以处理批又可以处理流 比如发展到今天的saprk框架
3. SQL支持角度
4. 存储层面
   数据不要重复，也可以写SQL，可以同时解决两者的问题 ——》数据湖

湖仓一体实时数仓架构

Hudi IceBerg Data Lake
1、离线和实时的数据都可以存储在数据湖里

2、IceBerg的底层依附于HDFS分布式文件系统

3、数据湖支持写sql，并且支持更新

解决的问题：

• 存储统一
• Kafka存储量小问题
• 任意分层都可以OLAP数据分析
• 复用同一套相同的血缘关系
• 实时更新数据

​