大数据篇：数据仓库概念

时间:2020-04-28
本文章向大家介绍大数据篇：数据仓库概念，主要包括大数据篇：数据仓库概念使用实例、应用技巧、基本知识点总结和需要注意事项，具有一定的参考价值，需要的朋友可以参考一下。

大数据篇：数据仓库概念

数据仓库（Data WareHouse）是为企业所有决策制定过程，提供所有系统数据支持的战略集合

通过对数据仓库中数据的分析，可以帮助企业，改进业务流程、控制、成本、提高产品质量等

数据仓库，并不是数据最终目的地，而是为数据最终的目的地做好准备：清洗、转义、分类、重组、合并、拆分、统计等等

1 数据库的"分家"

随着关系数据库理论的提出，诞生了一系列经典的RDBMS，如Oracle，MySQL，SQL Server等。这些RDBMS被成功推向市场，并为社会信息化的发展做出的重大贡献。然而随着数据库使用范围的不断扩大，它被逐步划分为两大基本类型：

  1. 操作型数据库

主要用于业务支撑。一个公司往往会使用并维护若干个数据库，这些数据库保存着公司的日常操作数据，比如商品购买、酒店预订、打车下单、外卖订购等；

  1. 分析型数据库

主要用于历史数据分析。这类数据库作为公司的单独数据存储，负责利用历史数据对公司各主题域进行统计分析；

那么为什么要"分家"？在一起不合适吗？能不能构建一个同样适用于操作和分析的统一数据库？

答案是NO。一个显然的原因是它们会"打架"......如果操作型任务和分析型任务抢资源怎么办呢？再者，它们有太多不同，以致于早已"貌合神离"。接下来看看它们到底有哪些不同吧。

2 操作型数据库 VS 分析型数据库

因为主导功能的不同(面向操作/面向分析)，两类数据库就产生了很多细节上的差异。就好像玩LOL一个中单一个ADC，肯定有很多行为/观念上的不同

2.1 数据组成差别 - 数据时间范围差别

  • 操作型数据库
    • 只会存放一定天数的数据
  • 分析型数据库
    • 存放的则是数年内的数据

这点也是将操作型数据和分析型数据进行物理分离的主要原因。

2.2 数据组成差别 - 数据细节层次差别

  • 操作型数据库

    • 存放的主要是细节数据
    • 也有汇总需求，但汇总数据本身不存储而只存储其生成公式。这是因为操作型数据是动态变化的，因此汇总数据会在每次查询时动态生成。

  • 分析型数据库

    • 存放的既有细节数据，又有汇总数据，对于用户来说，重点关注的是汇总数据部分。

    • 因为汇总数据比较稳定不会发生改变，而且其计算量也比较大(因为时间跨度大)，因此它的汇总数据可考虑事先计算好，以避免重复计算。

2.3 数据组成差别 - 数据时间表示差别

  • 操作型数据库
    • 通常反映的是现实世界的当前状态
  • 分析型数据库
    • 既有当前状态，还有过去各时刻的快照
    • 可以综合所有快照对各个历史阶段进行统计分析

2.4 技术差别 - 查询数据总量和查询频度差别

  • 操作型数据库
    • 查询的数据量少而频率多
  • 分析型数据库
    • 查询的数据量大而频率少

要想同时实现这两种情况的配置优化是不可能的，这也是将两类数据库物理分隔的原因之一。

2.5 技术差别 - 数据更新差别

  • 操作型数据库
    • 允许用户进行增，删，改，查
  • 分析型数据库
    • 规范是只能进行查询

2.6 技术差别 - 数据冗余差别

  • 操作型数据库

    • 数据的意义是什么？就是减少数据冗余，避免更新异常，操作型就需要遵循相关的规范。

  • 分析型数据库

    • 分析型数据库中没有更新操作。因此，减少数据冗余也就没那么重要了。

2.7 功能差别 - 数据读者差别

  • 操作型数据库
    • 使用者是业务环境内的各个角色，如用户，商家，进货商等
  • 分析型数据库
    • 只被少量用户用来做综合性决策。

2.8 功能差别 - 数据定位差别

  • 操作型数据库
    • 是为了支撑具体业务的，因此也被称为"面向应用型数据库"
  • 分析型数据库
    • 是针对各特定业务主题域的分析任务创建的，因此也被称为"面向主题型数据库"

这里说的定位，主要是指以何种目的组织起来

3 数据库三范式

  • 1NF：字段不可分;

    • 原子性 字段不可再分,否则就不是关系数据库;

  • 2NF：有主键，非主键字段依赖主键;

    • 唯一性 一个表只说明一个事物;

  • 3NF：非主键字段不能相互依赖;

    • 每列都与主键有直接关系，不存在传递依赖;

4 数据仓库(data warehouse)定义

大家应该已经意识到这个问题：既然分析型数据库中的操作都是查询，因此也就不需要严格满足完整性/参照性约束以及范式设计要求，而这些却正是分析型数据库精华所在。这样的情况下再将它归为数据库会很容易引起大家混淆，毕竟在绝大多数人心里数据库是可以关系型数据库画上等号的。

  • 那么为什么不干脆叫"面向分析的存储系统"呢？

这就是关于数据仓库最贴切的定义了。事实上数据仓库不应让传统关系数据库来实现，因为关系数据库最少也要求满足第1范式，而数据仓库里的关系表可以不满足第1范式。也就是说，同样的记录在一个关系表里可以出现N次。但由于大多数数据仓库内的表的统计分析还是用SQL，因此很多人把它和关系数据库搞混了。

1. 面向主题

面向主题特性是数据仓库和操作型数据库的根本区别。操作型数据库是为了支撑各种业务而建立，而分析型数据库则是为了对从各种繁杂业务中抽象出来的分析主题(如用户、成本、商品等)进行分析而建立；

2. 集成性

集成性是指数据仓库会将不同源数据库中的数据汇总到一起；

3. 企业范围

数据仓库内的数据是面向公司全局的。比如某个主题域为成本，则全公司和成本有关的信息都会被汇集进来；

4. 历史性

较之操作型数据库，数据仓库的时间跨度通常比较长。前者通常保存几个月，后者可能几年甚至几十年；

5. 时变性

时变性是指数据仓库包含来自其时间范围不同时间段的数据快照。有了这些数据快照以后，用户便可将其汇总，生成各历史阶段的数据分析报告；

5 数据仓库组件

​ 1. 业务系统

业务系统包含各种源数据库，这些源数据库既为业务系统提供数据支撑，同时也作为数据仓库的数据源(注：除了业务系统，数据仓库也可从其他外部数据源获取数据)；

​ 2. ETL

ETL分别代表：提取extraction、转换transformation、加载load。其中提取过程表示操作型数据库搜集指定数据，转换过程表示将数据转化为指定格式并进行数据清洗保证数据质量，加载过程表示将转换过后满足指定格式的数据加载进数据仓库。数据仓库会周期不断地从源数据库提取清洗好了的数据，因此也被称为"目标系统"；

​ 3. 前端应用

和操作型数据库一样，数据仓库通常提供具有直接访问数据仓库功能的前端应用，这些应用也被称为BI(商务智能)应用；

6 数据集市

数据集市可以理解为是一种"小型数据仓库"，它只包含单个主题，且关注范围也非全局。

数据集市可以分为两种，一种是独立数据集市(independent data mart)，这类数据集市有自己的源数据库和ETL架构；另一种是非独立数据集市(dependent data mart)，这种数据集市没有自己的源系统，它的数据来自数据仓库。当用户或者应用程序不需要/不必要/不允许用到整个数据仓库的数据时，非独立数据集市就可以简单为用户提供一个数据仓库的"子集"。

7 维度建模的基本概念

维度建模(dimensional modeling)是专门用于分析型数据库、数据仓库、数据集市建模的方法。

它本身属于一种关系建模方法，但和之前在操作型数据库中介绍的关系建模方法相比增加了两个概念：

  1. 维度表(dimension)

表示对分析主题所属类型的描述。比如"昨天早上张三在京东花费200元购买了一个皮包"。那么以购买为主题进行分析，可从这段信息中提取三个维度：时间维度(昨天早上)，地点维度(京东), 商品维度(皮包)。通常来说维度表信息比较固定，且数据量小。

  1. 事实表(fact table)

表示对分析主题的度量。比如上面那个例子中，200元就是事实信息。事实表包含了与各维度表相关联的逻辑外键，并通过JOIN方式与维度表关联。事实表的度量通常是数值类型，且记录数会不断增加，表规模迅速增长。

8 维度建模的三种模式

  1. 星形模式

星形模式(Star Schema)是最常用的维度建模方式

可以看出，星形模式的维度建模由一个事实表和一组维表成，且具有以下特点：

  1. 维表只和事实表关联，维表之间没有关联；
  2. 每个维表的主码为单列，且该主码放置在事实表中，作为两边连接的逻辑外键；
  3. 以事实表为核心，维表围绕核心呈星形分布；
  1. 雪花模式

雪花模式(Snowflake Schema)是对星形模式的扩展，每个维表可继续向外连接多个子维表。

星形模式中的维表相对雪花模式来说要大，而且不满足规范化设计。雪花模型相当于将星形模式的大维表拆分成小维表，满足了规范化设计。然而这种模式在实际应用中很少见，因为这样做会导致开发难度增大，而数据冗余问题在数据仓库里并不严重。

  1. 星座模式

星座模式(Fact Constellations Schema)也是星型模式的扩展。

前面两种维度建模方法都是多维表对应单事实表，但在很多时候维度空间内的事实表不止一个，而一个维表也可能被多个事实表用到。在业务发展后期，星座模式将作为最主要的维度建模。

9 数据立方体(Data Cube)

很多年前，当我们要手工从一堆数据中提取信息时，我们会分析一堆数据报告。通常这些数据报告采用二维表示，是行与列组成的二维表格。但在真实世界里我们分析数据的角度很可能有多个，数据立方体可以理解为就是维度扩展后的二维表格。下图展示了一个三维数据立方体：

更多时候数据立方体是N维的。它的实现有两种方式。其中星形模式就是其中一种，该模式其实是一种连接关系表与数据立方体的桥梁。但对于大多数纯OLAP使用者来讲，数据分析的对象就是这个逻辑概念上的数据立方体，其具体实现不用深究。对于这些OLAP工具的使用者来讲，基本用法是首先配置好维表、事实表，然后在每次查询的时候告诉OLAP需要展示的维度和事实字段和操作类型即可。

最常见的五大操作：切片，切块，旋转，上卷，下钻。

9.1 切片和切块(Slice and Dice)

在数据立方体的某一维度上选定一个维成员的操作叫切片，而对两个或多个维执行选择则叫做切块。下图逻辑上展示了切片和切块操作：

  • 这两种操作的SQL模拟语句如下，主要是对WHERE语句做工作：
# 切片
SELECT Locates.地区, Products.分类, SUM(数量)
FROM Sales, Dates, Products, Locates
WHERE Dates.季度 = 2
    AND Sales.Date_key = Dates.Date_key
    AND Sales.Locate_key = Locates.Locate_key
    AND Sales.Product_key = Products.Product_key
GROUP BY Locates.地区, Products.分类

# 切块
SELECT Locates.地区, Products.分类, SUM(数量)
FROM Sales, Dates, Products, Locates
WHERE (Dates.季度 = 2 OR Dates.季度 = 3) AND (Locates.地区 = '江苏' OR Locates.地区 = '上海')
    AND Sales.Date_key = Dates.Date_key
    AND Sales.Locate_key = Locates.Locate_key
    AND Sales.Product_key = Products.Product_key
GROUP BY Dates.季度, Locates.地区, Products.分类

9.2 旋转(Pivot)

旋转就是指改变报表或页面的展示方向。对于使用者来说，就是个视图操作，而从SQL模拟语句的角度来说，就是改变SELECT后面字段的顺序而已。下图逻辑上展示了旋转操作：

9.3 上卷和下钻(Rol-up and Drill-down)

上卷可以理解为"无视"某些维度；下钻则是指将某些维度进行细分。下图逻辑上展示了上卷和下钻操作：

这两种操作的SQL模拟语句如下，主要是对GROUP BY语句做工作：

# 上卷
SELECT Locates.地区, Products.分类, SUM(数量)
FROM Sales, Products, Locates
WHERE Sales.Locate_key = Locates.Locate_key
    AND Sales.Product_key = Products.Product_key
GROUP BY Locates.地区, Products.分类

# 下钻
SELECT Locates.地区, Dates.季度, Products.分类, SUM(数量)
FROM Sales, Dates, Products, Locates
WHERE Sales.Date_key = Dates.Date_key
    AND Sales.Locate_key = Locates.Locate_key
    AND Sales.Product_key = Products.Product_key
GROUP BY Dates.季度.月份, Locates.地区, Products.分类

9 OLAP 和 OLTP

数据处理大致可以分成两大类：

联机事务处理OLTP（on-line transaction processing）：是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。系统强调数据库内存效率，强调内存各种指标的命令率，强调绑定变量，强调并发操作。

联机分析处理OLAP（On-Line Analytical Processing）：是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。 系统则强调数据分析，强调SQL执行市场，强调磁盘I/O，强调分区等。

OLTP OLAP
用户 操作人员 决策人员
功能 日常操作处理 分析决策
DB设计 面向应用 面向主题
数据 当前的，最新的细节，二维表 历史的，聚集的，多维表
存取 读/写少量数据 读取亿级数据
工作单位 事务性保证 复杂查询
用户数 上千个 上百万个
DB大小 100MB-GB 100GB-TB以上
时间要求 具有实时性 对时间的要求不严格
主要应用 数据库 数据仓库

10 OLAP的架构模式

10.1 MOLAP(Multidimensional Online Analytical Processing)

MOLAP架构会生成一个新的多维数据集，也可以说是构建了一个实际数据立方体。

在该立方体中，每一格对应一个直接地址，且常用的查询已被预先计算好。因此每次的查询都是非常快速的，但是由于立方体的更新比较慢，所以是否使用这种架构得具体问题具体分析。

10.2 ROLAP(Relational Online Analytical Processing)

ROLAP架构并不会生成实际的多维数据集，而是使用星形模式以及多个关系表对数据立方体进行模拟

这种架构下的查询没有MOLAP快速。因为ROLAP中，所有的查询都是被转换为SQL语句执行的。而这些SQL语句的执行会涉及到多个表之间的JOIN操作，没有MOLAP速度快。

10.3 HOLAP(Hybrid Online Analytical Processing)

这种架构综合参考MOLAP和ROLAP而采用一种混合解决方案，将某些需要特别提速的查询放到MOLAP引擎，其他查询则调用ROLAP引擎。上述MOLAP和ROLAP的结合。

原文地址：https://www.cnblogs.com/ttzzyy/p/12794279.html

随机文章
本站知识点必读
最近更新