一文读懂数据仓库~~~

1、简介

1.1、背景

主要为了满足两个需要，一是历史数据积存，二是企业数据分析需要

为了避免冷数据对数据库产生的影响，妨碍数据库运行，这时就需要企业定期将冷数据从业务数据库中转移，存储到专门存放历史数据的仓库中，这个仓库就称之为数据仓库。

企业统一建立一个数据仓库，使用专门的数据抽取系统，定期从业务数据库把数据抽取到数据仓库中。数据仓库可以直接开放接口，这样业务数据库和数据仓库的权限管理更具有针对性，数据仓库面向数据分析，业务数据库面向业务系统，各司其职。

1.2、概念

数据仓库是存储数据的仓库, 主要是用于存储过去既定发生的历史数据, 对这些数据进行数据分析的操作, 从而对未来提供决策支持。

数据仓库是一个面向主题的（Subject Oriented）、集成的（Integrate）、相对稳定的（Non-Volatile）、随时间变化（Time Variant）的数据集合，它用于支持企业或组织的决策分析处理。

特征：

• 面向主题的：数据集合是以主题为单位进行数据汇聚，一个主题内只存储与本主题有关系的数据。
• 集成的：数据来源多种多样，需要ETL操作。
• 相对稳定的：一般只进行写入与查询操作，不进行更新与删除。
• 反映历史变化：关键数据隐式或显式的基于时间变化

特点：既不生产数据, 也不消耗数据, 数据来源于各个数据源

1.3、传统数据库与大数据仓库

传统数据库：传统数据库是单个关系型数据库组成MPP（大规模并行处理）集群，说人话就是多个单机数据库集群产生。

• 优点：
  • 由于是由关系型数据库改造，所以完全兼任原有的SQL语法
• 缺点：
  • 扩展性有限：每一个节点都是一个数据库，涉及数据交换还需要网络IO，限制了节点上限，分库分表也有一定上限
  • 热点问题：某一个数据库压力特别大，而其他很小

大数据仓库：基于分布式文件系统

• 优点：数据库结构化数据看为文件，自动拆分多副本存储，不用考虑精细的分库分表，解决了延展性和热点问题。
• 缺点：
  • sql支持率问题
  • 缺少事务支持，对事务支持不全 3
  • 数据量较小时，计算较慢。在数据量没有达到一定规模的时候，光是任务的拆分，分配，调度，合并，整个过程就会花费大量的时间。

常见的数仓产品：

传统型数仓：

• Oracle RAC
• DB2
• Teradata
• Greenplum

分布式数仓：

• hive
• Spark SQL
• HBase
• Impala
• HAWQ
• TIDB

2、数据仓库、数据库、数据集市

2.1、OLTP、OLAP

​ 操作型处理，叫联机事务处理OLTP（On-Line **Transaction**** Processing），主要目标是做数据处理，它是针对具体业务在数据库联机的日常操作，通常对少数记录进行查询、修改。用户较为关心操作的响应时间、数据的安全性、完整性和并发支持的用户数等问题。传统的关系型数据库系统作为数据管理的主要手段，主要用于操作型处理。

​ 分析型处理，叫联机分析处理OLAP（On-Line **Analytical**** Processing），主要目标是做数据分析。一般针对某些主题的历史数据进行复杂的多维分析，支持管理决策。数据仓库是OLAP系统的一个典型示例，主要用于数据分析

2.2、数据仓库、数据库

​ 数据库与数据仓库的区别实际讲的是OLTP与OLAP的区别。

​ OLTP系统的典型应用就是RDBMS,也就是我们俗称的数据库，当然这里要特别强调此数据库表示的是关系型数据库，Nosql数据库并不在讨论范围内。

​ OLAP系统的典型应用就是DW,也就是我们俗称的数据仓库。

​ 因此数据仓库和数据库的区别就很好掌握了。但是有几点需要着重强调：

1. 数据仓库不是大型的数据库，虽然数据仓库存储数据规模大。
2. 数据仓库的出现，并不是要取代数据库。
3. 数据库是面向事务的设计，数据仓库是面向主题设计的。
4. 数据库一般存储业务数据，数据仓库存储的一般是历史数据。
5. 数据库是为捕获数据而设计，数据仓库是为分析数据而设计。

2.3、数据仓库、数据集市

​ 数据仓库是面向整个集团组织的数据，数据集市是面向单个部门使用的。可以认为数据集市是数据仓库的子集，也有人把数据集市叫做小型数据仓库。数据集市通常只涉及一个主题领域，例如市场营销或销售。因为它们较小且更具体，所以它们通常更易于管理和维护，并具有更灵活的结构。

​ 比如上图所示：

​ 各种操作型系统数据和包括文件在内的等其他数据作为数据源，经过ETL(抽取转换加载)填充到数据仓库中；

​ 数据仓库中有不同主题数据，数据集市则根据部门特点面向指定主题，比如Purchasing（采购）、Sales（销售）、Inventory（库存）；

​ 用户可以基于主题数据开展各种应用：数据分析、数据报表、数据挖掘。

3数仓分层架构

数据仓库的特点是本身不生产数据，也不最终消费数据。按照数据流入流出数仓的过程进行分层就显得水到渠成。

数据分层每个企业根据自己的业务需求可以分成不同的层次，但是最基础的分层思想，理论上数据分为三个层，操作型数据层（ODS）、数据仓库层(DW)和数据应用层(DA)。

企业在实际运用中可以基于这个基础分层之上添加新的层次，来满足不同的业务需求

为什么要分层

分层的主要原因是在管理数据的时候，能对数据有一个更加清晰的掌控，详细来讲，主要有下面几个原因：

1. 清晰数据结构

   每一个数据分层都有它的作用域，在使用表的时候能更方便地定位和理解。

2. 数据血缘追踪

   简单来说，我们最终给业务呈现的是一个能直接使用业务表，但是它的来源有很多，如果有一张来源表出问题了，我们希望能够快速准确地定位到问题，并清楚它的危害范围。

3. 减少重复开发

   规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算。

4. 把复杂问题简单化

   将一个复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤，比较简单和容易理解。而且便于维护数据的准确性，当数据出现问题之后，可以不用修复所有的数据，只需要从有问题的步骤开始修复。

5. 屏蔽原始数据的异常

   屏蔽业务的影响，不必改一次业务就需要重新接入数据

3.1、ODS（操作型数据层）

操作型数据层。也称之为源数据层、数据引入层、数据暂存层、临时缓存层

这一层不做任何的修改， 目的是存储原始数据

如果一定要修改，就新增数据，然后给他更新的日期，并且将状态变为update，删除旧数据

ETL导入ODS的方法

全量和增量
增量导入：使用外连接&全覆盖的方法，把增量数据与原有的数据进行join全外连接（两表中一个有就返回），如果有新增的数据，就直接在内存中修改，然后把ODS层覆盖

3.2、DW （数据仓库层）

整个层主要是为数据分析提供服务，主要分DIM维度表，DWD（数据明细层）和DWS（数据汇总层）

3.2.1、DIM（公共维度层）

基于维度建模理念思想，建立整个企业一致性维度。

3.2.2、DWD（细节数据层）

将明细事实表的某些重要维度属性字段做适当冗余，即宽表化处理。

主要功能：数据格式规范化&维度降维

DWD（数据明细层）：主要接受ODS层的数据，由于ODS的数据是不进行修改的，所以ODS层的数据可能来源于各个系统，并且格式不统一，所以我们DWD（数据明细层）要做的就是统一格式，如清洗、标准化、异常数据清洗，对数据做统一字段编码等。

还有可能就是维度降维，比如说公司有多个分布，在北京上海等地返回用户表，这些用户表字段都一样，但是一张张独立的表，我们可以把这些表增加一个字段叫做位置，然后把这些表就可以合成同一张表

满足三范式

3.2.3、DWB:（数据基础层） ，DWS（数据汇总层）数据服务层

以分析的主题对象作为建模驱动，基于上层的应用和产品的指标需求，构建公共粒度的汇总指标事实表，以宽表化手段物理化模型

• 存放客观数据,通常作为中间层
• 将各个表汇总成主题表，例如都是交易相关的就汇总成交易表，
• 不满足三范式

3.3、ADS（数据/应用服务层）

存储分析结果，为不同业务提供接口，减少数仓压力

如果直接开放前面的CMD层，这层是进行数据分析的，直接开放业务查询接口会增加负担，所以我们专门建了ADS层来存储结果，并且开放接口。

该层主要是提供数据产品和数据分析使用的数据,一般会存储在ES/mysql等系统中供线上系统使用

3.4、ETL

数据仓库从各数据源获取数据及在数据仓库内的数据转换和流动都可以认为是ETL。但是在实际操作中将数据加载到仓库却产生了两种不同做法：ETL和ELT。

E：extract抽取，T：trasnform转换，L：load加载
抽取原始数据，然后进行转换，然后加载到目的端的过程

1. 数据抽取（Extraction）：

• 抽取的数据源：结构化（二维表数据）、半结构化（图片，文本，html，视频）、非结构化（json，xml）
• 抽取数据的方式：全量或增量（抽取全部数据，或者抽取变动数据）

结构化、半结构化、非结构化数据如何提取？

1. 结构化数据采用JDBC、数据库日志等方式，JDBC对数据库进行直接连接
2. 半结构化或者非结构化，可以监听文件是否发生了变动，将变动后的数据进行抽取

2. 数据转换（Transformation）

主要是数据清洗和转换两个阶段

• 数据清洗

对重复、二义性、不完整、违反业务或逻辑规则等问题进行统一处理

• 数据转换

数据标准化，字段数据类型等转换

3. 数据加载（Loading）

将处理完的数据导入到对应的目标源

常用工具

• 结构化ETL工具：Sqoop，Kettle，Datasatge，Informatica，Kafka

• 非结构化：lume，Logstash

4、数仓建模

数仓建模指的规定如何在hive中构建表, 数仓建模中主要提供两种理论来进行数仓建模操作: 三范式建模和维度建模理论

• 三范式建模: 主要是存在关系型数据库建模方案上, 主要规定了比如建表的每一个表都应该有一个主键, 数据要经历的避免冗余发生等等
• 维度建模: 主要是存在分析性数据库建模方案上, 主要一切以分析为目标, 只要是利于分析的建模, 都是OK的, 允许出现一定的冗余, 表也可以没有主键

4.1、维度建模

主要是存在分析性数据库建模方案上,以分析为目标, 只要是利于分析的建模, 都是OK的, 允许出现一定的冗余, 表也可以没有主键

4.1.1、维度分析

维度一般指的分析的角度, 看待一个问题的时候, 可以多个角度来看待, 而这些角度指的就是维度

比如: 有一份2020年订单数据, 请尝试分析

• 可以从时间, 地域 , 商品, 来源 , 用户…

维度的分类:

• 定性维度: 指的计算每天 每月 各个的维度 , 一般来说定性维度的字段都是放置在group by 中
• 定量维度: 指的统计某一个具体的维度或者某一个范围下信息, 比如说: 2020年度订单额, 统计20~30岁区间人群的人数 ,一般来说这种维度的字段都是放置在where中

维度的分层和分级: 本质上对维度进行细分的过程

比如按年统计: 按季度，按照月份，按照天，按照每个小时

比如按省份统计：按市，按县

从实际分析中, 统计的层级越多, 意味统计的越细化 设置维度内容越多

维度的下钻和上卷: 以某一个维度为基准, 往细化统计的过程称为下钻, 往粗粒度称为上卷

比如: 按照 天统计, 如果需要统计出 小时, 指的就是下钻, 如果需要统计 季度 月 年, 称为上卷统计

• 从实际分析中, 下钻和上卷, 意味统计的维度变得更多了

指标：

指标指的衡量事务发展的标准, 就是度量值

常见的度量值: count() sum() max() min() avg() 还有一些 比例指标(转化率, 流失率, 同比…)

指标的分类:

• 绝对指标: 计算具体的值指标

  count() sum() max() min() avg()

• 相对指标: 计算比率问题的指标

• 转化率, 流失率, 同比

4.1.2、事实表和维度表

维度建模的两个核心概念：事实表和维度表

• 事实表: 事实表一般指的就是分析主题所对应的表,每一条数据用于描述一个具体的事实信息, 这些表一般都是一坨主键(外键)和描述事实字段的聚集

  • 事务事实表：保存的是最原子的数据，也称“原子事实表”或“交易事实表”。沟通中常说的事实表，大多指的是事务事实表。
  • 周期快照事实表：周期快照事实表以具有规律性的、可预见的时间间隔来记录事实，时间间隔如每天、每月、每年等等。周期表由事务表加工产生
  • 累计快照事实表：完全覆盖一个事务或产品的生命周期的时间跨度，它通常具有多个日期字段，用来记录整个生命周期中的关键时间点

• 维度表: 指的在对事实表进行统计分析的时候, 基于某一个维度, 二这个维度信息可能其他表中, 而这些表就是维度表

  维度表并不一定存在, 但是维度是一定存在

  • 高基数维度表: 指的表中的数据量是比较庞大的, 而且数据也在发送的变化

    例如: 商品表, 用户表

  • 低基数维度表: 指的表中的数据量不是特别多, 一般在几十条到几千条左右,而且数据相对比较稳定

    例如: 日期表,配置表,区域表

4.1.3、维度建模的三种模型

1. 第一种: 星型模型

   • 特点: 只有一个事实表, 那么也就意味着只有一个分析的主题, 在事实表的周围围绕了多个维度表, 维度表与维度表之间没有任何的依赖

   • 反映数仓发展初期最容易产生模型

   

2. 第二种: 雪花模型

   • 特点: 只有一个事实表, 那么也就意味着只有一个分析的主题, 在事实表的周围围绕了多个维度表, 维度表可以接着关联其他的维度表

   • 反映数仓发展出现了畸形产生模型, 这种模型一旦大量出现, 对后期维护是非常繁琐, 同时如果依赖层次越多, SQL分析的难度也会加大

   • 此种模型在实际生产中,建议尽量减少这种模型产生

   

3. 第三种: 星座模型

   • 特点: 有多个事实表, 那么也就意味着有了多个分析的主题, 在事实表的周围围绕了多个维度表, 多个事实表在条件符合的情况下, 可以共享维度表

   • 反映数仓发展中后期最容易产生模型

   

对比：

对比

• 星型模型因为数据的冗余所以很多统计查询不需要做外部的连接，因此一般情况下效率比雪花型模型要高。
• 星型结构不用考虑很多正规化的因素，设计与实现都比较简单。
• 雪花型模型由于去除了冗余，有些统计就需要通过表的联接才能产生，所以效率比较低。
• 正规化也是一种比较复杂的过程，相应的数据库结构设计、数据的 ETL、以及后期的维护都要复杂一些。

4.1.4、缓慢渐变维（SCD）

解决问题: 解决历史变更数据是否需要维护的情况

• SCD1：直接覆盖, 不维护历史变化数据
  • 主要适用于: 对错误数据处理
• SCD2：不删除、不修改已存在的数据, 当数据发生变更后, 会添加一条新的版本记录的数据, 在建表的时候, 会多加两个字段(起始时间, 截止时间), 通过这两个字段来标记每条数据的起止时间 , 一般称为拉链表
  • 好处: 适用于保存多个历史版本, 方便维护实现
  • 弊端: 会造成数据冗余情况, 导致磁盘占用率提升
• SCD3: 通过在增加列的方式来维护历史变化数据
  • 好处: 减少数据的冗余, 适用于少量历史版本的记录以及磁盘空间不是特别充足情况
  • 弊端: 无法记录更多的历史版本, 以及维护比较繁琐