博客

一、数仓定义

按照传统的定义，数据仓库是一个面向主题的、集成的、非易失的、反映历史变化（随时间变化），用来支持管理人员决策的数据集合。数据仓库是一套数据组织和应用的方法论，是需要很多的支持系统来协助（包含类似数据库这样的存储系统），最后达到支持分析决策的目的。

1、


面向主题

• 
  关系型数据库
  

面向事务处理任务，用于记录状态。

• 
  数仓
  

数仓中的数据是按照一定的主题域进行组织，主题是一个抽象的概念，是指用户使用数据仓库进行决策时所关心的重点方面，一个主题通常与多个操作型信息系统相关。每一个主题基本对应一个宏观的分析领域。

比如：银行的数据仓库的主题：客户

2、集成

• 
  关系型数据库
  

数据库通常与某些特定的应用相关，数据库之间相互独立，并且往往是异构的

• 
  数仓
  

数据仓库中的数据是在对原有分散的数据库数据抽取、清理的基础上经过系统加工、汇总和整理得到的。必须消除源数据中的不一致性，以保证数据仓库内的信息是关于整个企业的一致的全局信息。

3、非易失即相对稳定的

• 
  关系型数据库
  

数据通常实时更新，数据根据需要及时发生变化。

• 
  数仓
  

数据仓库中包括了大量的历史数据。所涉及的数据操作主要是数据查询，一旦某个数据进入数据仓库以后，一般情况下将被长期保留，也就是数据仓库中一般有大量的查询操作，但修改和删除操作很少，通常只需要定期的加载、刷新。

4、随时间变化即反映历史变化

• 
  关系型数据库
  

数据主要关心当前某一个时间段内的数据

• 
  数仓
  

数据仓库中的数据通常包含历史信息，系统记录了企业从过去某一时点(如开始应用数据仓库的时点)到目前的各个阶段的信息，通过这些信息，可以对企业的发展历程和未来趋势做出定量分析和预测。

5、用来支持管理人员决策的数据集合

• 
  关系型数据库
  

数据库只关注当前时间数据，无法支持管理人员决策。

• 
  数仓
  

系统记录了企业历史数据，可以对企业的发展历程和未来趋势做出定量分析和预测。企业数据仓库的建设，是以现有企业业务系统和大量业务数据的积累为基础。供他们做出改善其业务经营的决策而把信息加以整理归纳和重组，并及时提供给相应的管理决策人员，是数据仓库的根本任务。

二、建设数仓的目的

数仓的建设并不是数据存储的最终目的地，而是为数据最终的目的地做好准备：清洗、转义、分类、重组、合并、拆分、统计等等。通过对数据仓库中数据的分析，可以帮助企业，改进业务流程、控制、成本、提高产品质量等。

1、理清数据资产提高排查和开发运维效率

场景：

• 不知道有什么数据、找谁要数据；

• 多个系统不同的数据字段的含义

• 数据如何生成和更新的，数据依赖关系割裂；

2、提高数据质量

场景

• 字段命名不规范、口径不一致；

• 条件的过滤和规则等的理解差异带来的算法不一致；

3、数据解耦

场景

• 上下游依赖混乱

• 复杂问题耦合在一起

• 每次从原始数据取数，数据开发周期长

• 业务数据轻微改动带来的变更过大，无中间表加工

4、解决频繁的临时性需求

场景

• 报送监管历史数据

• 临时数据需要交叉

虽然数仓建设能带来诸多的益处，但数仓的建设不是一天建成的，是一个庞大复杂耗时的工程，需要很多支持系统的配合：元数据管理系统、调度系统等，要根据业务发展所处的状态和未来的发展趋势以及分析决策的复杂性等综合来搭建。

总结：

1. 了解数仓的特点；
   

2. 了解建设数仓的目的意义，能解决什么问题等

还介绍了建立数仓的目的：数仓的建设并不是数据存储的最终目的地，而是为数据最终的目的地做好准备：清洗、转义、分类、重组、合并、拆分、统计等等。通过对数据仓库中数据的分析，可以帮助企业，改进业务流程、控制、成本、提高产品质量等。

下面介绍一下两个重要的数据处理的类型OLTP和OLAP，并通过比对总结，从而更好的理解两种数据处理类型。

三、数据处理“分

家

”

随着关系型数据库理论的提出，诞生了一系列经典的RDBMS，如DB2、Oracle，SQL Server、MySQL等。随着数据库使用范围的不断扩大，根据操作业务不同类型，被逐步划分为两大处理的类型：

1、处理业务型数据库

主要用于业务支撑。比如：银行往往会使用并维护若干个数据库，这些数据库保存着日常操作数据，如理财购买、核心系统、信用卡数据、内部管理系统等。

2、分析历史数据型数据库

主要用于历史数据分析。这类数据库作为公司的单独数据存储，利用历史数据对公司各主题域进行统计分析。比如：银行对客户AUM统计、对征信的统计评估等。

为什么要分家？

能不能构建一个同样适用于操作和分析的统一数据库？目前的解决方案是不适合！

• 因为数据之间会”打架”；

• 如果操作型任务和分析型任务抢资源怎么办呢？

• 同时处理数据怎么保证数据一致性呢？

后面我们会分析这两个类型是完全不一样的操作。即一个是面向操作即OLTP一个是面向分析（主题）即OLAP。

四、范式概念

在了解范式概念之前，我们先来了解一下函数依赖的概念。

1、函数依赖

根据下图来加深理解：

• 
  完全函数依赖
  

通过A and B能推出C，但是AB单独得不到C，那么可以说：C完全依赖于AB。

（学号，课名）推出分数，但是单独用学号推不出分数，那么可以说：分数完全依赖于（学号，课名）。

• 
  部分函数依赖
  

通过A and B 能推出C，通过单独的A 或者单独的B也能推出C，那么可以说：C部分依赖于AB

（学号，课名）推 姓名，而还可以通过学号直接推出姓名，那么可以说：姓名部分依赖于（学号，课名）

• 
  传递函数依赖
  

通过A得到B，通过B得到C，但是通过C不能得 A，那么可以说：C传递依赖于A

通过学号推出系名，系名 推系主任，但是 系主任不能推出学号，那么可以说：系主任传递依赖于学号。

2、范式定义

范式（数据库设计范式）是符合某一种级别的关系模式的集合。构造数据库必须遵循一定的规则。

在关系数据库中，这种规则就是范式。关系数据库中的关系必须满足一定的要求，即满足不同的范式。

3、范式类型

目前关系数据库有六种范式：

第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、

Boyce-Codd范式（BCNF）、第四范式（4NF）和第五范式（5NF）。

一般说来，数据库只需满足第三范式（3NF）就行了。

4、三范式

• 
  第一范式：属性不可切分
  

上表：商品这列中的数据不是原子数据项，是可以进行分割的。

• 
  
  第二范
  
  
  
  式：不能存在”部分函数依赖”
  

上表（学号，课名），分数完全依赖于（学号和课名），但是姓名并不完全依赖于（学号和课名)。

• 
  第三范
  
  
  式：不能存在”传递函数依赖”
  

上表：学号–>系名–>老师，但是老师推不出学号。

五、OLTP简介

1、OLTP概念

联机事务处理OLTP（on-line transaction processing）：是传统的关系型数据库的主要应用，主要是基本的、日常的在线/联机事务处理。

OLTP典型的应用领域包括银行、证劵等金融行业，电子商务系统等。比如：我们在某A银行APP上查询账户余额、收支信息和转账记录，在ATM机上存钱，取钱，将某A行账号的钱转到某B行账号上。这些都是典型的OLTP类操作。

这些操作都比较简单，主要是对数据库中的数据进行增删改查。操作主体一般是产品的用户。

2、OLTP关系模型

数据库中的关系模型是严格遵循第三范式（3NF），关系模型主要应用在OLTP系统中，为了保证数据的一致性以及避免冗余，所以大部分业务系统的表都是遵循第三范式的。

注:图片来源于网络

3、OLTP特点

• 从上面这个建模客户表图中可以看出，物理表数量多，而数据冗余程度低；

• 数据分布于众多的表中；

• 这些数据可以更为灵活地被应用，功能性较强；

• 但是一次修改，需要修改多个表，很难保证数据的一致性；

• 并且获取数据时候，需要通过join拼接出最后的数据。

六、OLAP简介

1、OLAP概念

OLAP是Online analytical processing，指联机分析处理。数数仓的主要应用。从字面上我们能看出是做分析类操作。通过分析数据库中的数据来得出一些结论性的东西。比如：给领导们看的报表，用于进行市场开拓的用户行为统计，不同维度的汇总分析结果等等。操作主体一般是运营、销售和市场等团队人员而不是用户，主要用于历史数据分析。

2、OLAP模型

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

注:图片来源于网络

• 上图为维度模型建模片段，主要应用于 OLAP 系统中；

• 通常以某一个事实表为中心进行表的组织，主要面向业务，特征是可能存在数据的冗余，但是能方便的得到数据。

关系模型虽然冗余少，但是在大规模数据，跨表分析统计查询过程中，会造成多表关联，这会大大降低执行效率。所以通常我们采用维度模型建模，把相关各种表整理成两种：事实表和维度表两种。关于这方面内容我们下节讲解。

七、OLTP VS OLAP

1、数据主要应用

2、数据内容

3、性能要求

总结：

1. 了解数据库的三范式

2. OLTP和OLAP两种数据处理类型；

3. 通过对比加深对OLAP的认知；
   

>>>>

Q&A

Q：


MySQL这样的OLTP数据库能处理OLAP业务吗？

A：

也可以处理这样的业务的，但是并没有人来使用这样的解决方案！

• MySQL是作为OLTP数据库使用的。但是也能执行一些OLAP操作，比如里面8.0包括窗口函数，通用表达式和更强大的Join能力，但这不是MySQL擅长的领域。

• OLTP和OLAP都是通过SQL来执行，但SQL语句只是描述了我想要什么，而并没有说明应该怎么做（不考虑hint等），即确定最优的执行计划。由于一般OLTP操作比较简单，所涉及的表也少，因此不需要相应的数据库具有强大的执行优化能力。

• OLAP类操作需要强大的执行计划产生和优化能力。

  当然，如果总数据量较小，那MySQL也是能够应付的。数据量大，需要OLAP解决方案。

参考书籍：

1. 数据仓库第4版

2. DAMA数据管理知识体系指南

3. 华为数据之道

推荐阅读：

浅谈数仓模型（维度建模）

数仓深度 | 数据模型设计（推荐收藏）