一.为什么需要数据仓库？

传统的数据库中，存放的数据都是一些定制性数据较多，表是二维的，一张表可以有很多字段，字段一字排开，对应的数据就一行一行写入表中，特点就是利用二维表表现多维关系。

但这种表现关系的上限和下限就定死了，比如QQ的用户信息，直接通过查询info表，对应的username、introduce等信息即可，而此时我想知道这个用户在哪个时间段购买了什么？修改信息的次数？诸如此类的指标时，就要重新设计数据库的表结构，因此无法满足我们的分析需求。

在产品脑图中可以很清晰的看到根据业务需求设计所需的字段，因此也导致数据库是根据业务需求进行设计。那么有的会问，为什么一开始就不考虑好这个扩展性呢？为什么数据库一开始就不以数据仓库的形式设计？

首先数据仓库，从字面上理解就可以感受到这是一个很大的空间，而且存储的物品很杂，里面会存放酱油、沐浴露、洗发精等物品，而数据库是存放酱油、盐等厨房用品，洗浴又是一个数据库。

另外一个就是，国内互联网的发展，一开始大家都是做个软件出来，大家一起用，这个时候只要满足的了需求即可，现今不止是需求还有用户的体验等各种方面，需要根据这些分析指标做调整。

小结：

数据库是跟业务挂钩的，而数据库不可能装下一个公司的所有数据，因此数据库的设计通常是针对一个应用进行设计的。

数据仓库是依照分析需求、分析维度、分析指标进行设计的。

什么是数据仓库？

数据仓库（Data Warehouse）简称DW或DWH，是数据库的一种概念上的升级，可以说是为满足新需求设计的一种新数据库，而这个数据库是需容纳更多的数据，更加庞大的数据集，从逻辑上讲数据仓库和数据库是没有什么区别的。为企业所有级别的决策制定过程，提供所有类型数据支撑的战略集合，主要是用于数据挖掘和数据分析，以建立数据沙盘为基础，为消灭消息孤岛和支持决策为目的而创建的。

数据仓库发展过程

2000年初，国内是简单的报表阶段，这个阶段主要是汇总一些数据，解决业务人员想要的报表。

如：销售额：xxx万元、销售量：20000件

2010年，数据集市阶段，进行一定的数据采集、整理，按照某业务部门的需求进行采集、整理，按照业务人员需要，进行多维度报表的展现，能够提供特定的领导决策数据。

如：1月~3月销售额：xxx万元、4月~6月销售额：xxx万元

2015年，各大公司开始注重用户体验，物流效率等问题，这个时候进入数据仓库阶段，主要按照数据模型，对整个企业的数据进行采集、整理，提供跨部门，完整一致性的业务报表数据，能够通过数据仓库生成对业务具有指导性的数据，为决策者提供更全面的数据。

如：某个月某个地区的用户数量下降，某个月某个地区的用户数量上升。

数据仓库特点

数据仓库（Data Warehouse，简写DW）面向主题的、集成的、相对稳定的、且随时间变化的数据集合，主要为企业撰写分析报告与决策做支撑。

1.面向主题

是企业系统信息中的数据综合、归类并进行分析的一个抽象，对应企业中某一个宏观分析领域所涉及的分析对象。比如购物是一个主题，那么购物里面包含用户、订单、支付、物流等数据综合，对这些数据要进行归类并分析，分析这个对象数据的一个完整性、一致性的描述，能完整、统一的划分对象所设计的各项数据。

2.数据集成

数据仓库的数据是从原有分散的数据库中的数据抽取而来的。

操作型数据和支持决策分析型（DSS）数据差别甚大，这里需要做大量的数据清洗与数据整理的工作。

第一：每一个主题的源数据在原有分散数据库中的有许多重复和不一致，且不同数据库的数据是和不同的应用逻辑捆绑的。

第二：数据仓库中的综合性数据不能从原有的数据库系统直接得到，因此在数据进入数据仓库之前要进过统一和综合。（字段同名异意，异名同义，长度等）

3.不可更新

数据仓库的数据主要是提供决策分析用，设计的数据主要是数据查询，一般情况下不做修改，这些数据反映的是一段较长时间内历史数据的内容，有一块修改了影响的是整个历史数据的过程数据。

4.随时间不断变化

数据仓库的数据是随着时间变化而不断增加新的数据。数据仓库随着时间变化不断删去久的数据内容，数据仓库的数据也有时限的，数据库的数据时限一般是60 ~ 90天，而数据仓库的数据一般是5年~10年。

数据仓库和数据库的区别

数据库的操作：一般称为联机事务处理OLTP（On-Line Transaction Processing），是针对具体的业务在数据库中的联机操作，通常对数据进行采集，处理，储存以及增删改查的操作

数据仓库的操作：一般称为联机分析处理OLAP（On-Line Analytical Processing），是针对某些主题（综合数据）的历史数据进行查询、分析，支持管理决策。

数据仓库常用系统架构

ODS层（临时存储层）：这一层做的工作是贴源，而这些数据和源系统的数据是同构，一般对这些数据分为全量更新和增量更新，通常在贴源的过程中会做一些简单的清洗，

DW层（数据仓库层）：将一些数据关联的日期进行拆分，使得其更具体的分类，一般拆分成年、月、日，而ODS层到DW层的ETL脚本会根据业务需求对数据进行清洗、设计，如果没有业务需求，则根据源系统的数据结构和未来的规划去做处理，对这层的数据要求是一致、准确、尽量建立数据的完整性。

APP层（引用层）：提供报表和数据沙盘展示所需的数据。

为什么要分层？

在未分层的情况下，数据之间的耦合性与业务耦合性是不可避免的，当源业务系统的业务规则发生变化时，可能影响整个数据的清洗过程。数据分层简化了数据清洗的过程，每一层的逻辑变得更加简单和易于理解，当发生错误或规则变化时，只需要进行局部调整。

元数据

在操作数据仓库时，操作的都是元数据，而元数据分为技术元数据和业务元数据。

(1)技术元数据：是指数据仓库开发、管理、维护相关的数据，描述了数据的原信息，转换描述、数据映射、访问权限等。

(2)业务元数据：为管理层和业务分析人员服务，从业务的角度描述数据，包括行业术语、数据的可用性、数据的意义等。

元数据的存储有常用的两种，一种是以数据集为基础，每一个数据集有对应的元数据文件，每一个元数据文件对应数据集的元数据内容，另一种是以数据库为基础，由若干项组成，每一项标识元数据的一个元素。

为什么需要为数据仓库建模？

 进行全面的业务梳理时，我们可以通过业务模型，全面了解业务结构及运行情况，按照业务特定的规律分门别类和程序化，改进业务的流程。

通过模型的建设，我们可以很清晰的看到数据之间内在的关联关系，从而建立起全方位的数据视角，并消灭信息孤岛和数据差异化的问题，进而保证数据的一致性。模型可以很好的帮助我们分离出底层技术的实现和上层业务的展现，当上层业务发生变化时，通过数据模型，底层的技术实现可以适应的了业务的变动，进而解决数据库的灵活性。在模型中可以很好的看出开发人员和业务人员之间的系统建设范围的界定，及未来的规划。

什么是数据模型？

数据模型是数据关系的一种映射， 就是将业务之间的关系，用模型图形化的描绘出来，而不再是脑海的一个模糊的关系。在设计数据仓库模型和架构时，我们需要懂具体的技术，也需要了解行业的知识和经验来帮助我们对业务进行抽象、处理，进而生成各个阶段的模型。

数据模型架构

在大体上，我们将数据模型分为5大块。

(1)系统记录域：数据仓库业务数据存储区，保证数据的一致性。

(2)内部管理域：用于内部管理的元数据，统一的元数据管理。

(3)汇总域：这里的数据来自系统记录域的汇总，保证分析域的主题分析性能，满足部分报表查询。

(4)分析域：各个业务部分的具体主题业务分析，可以单独存储在相应的数据集市中。

(5)反馈域：用于相应的前端的反馈数据，视业务的需要设置这个域。

维度和指标（度量）

维度和指标是数据分析领域常用的概念，亦是在设计数据仓库过程中需要考虑的。

(1)维度：就是数据的观察角度，即从哪个角度去分析问题，看待问题。

(2)指标(度量): 就是从维度的基础上去衡算这个结果的值。

比如银行采集数据：

指标的构成是：维度+汇总方式+度量，比如：“订单总金额”，“订单”表明维度的限定，“总”表明汇总方式是求和，“金额”可以表明度量单位是货币单位。

事实表和维度表

事实表和维度表是在设计数据仓库过程中需要考虑的。

(1).事实表（Fact Table): 是指存储有事实记录的表，如系统的日志、销售记录、用户访问日志等信息，事实表的记录是动态的增长的，所以体积是大于维度表。用户访问日志（事实表): 用户名、url、时间…

(2).维度表（Dimension Table）也称为查找表（Lookup Table）是与事实表相对应的表，这个表保存了维度的属性值，可以跟事实表做关联，相当于是将事实表中经常重复的数据抽取、规范出来用一张表管理，常见的有日期(日、周、月、季度等属性）、地区表等，所以维度表的变化通常不会太大。

维度表的存在缩小了事实表的大小，便于维度的管理和CURD维度的属性，不必对事实表的大量记录进行改动，并且可以给多个事实表重用。

数据模型建立过程

(1)业务模型：业务分解和程序化，确定好业务的边界及业务流程，如订单、支付都是一个单独的业务模块

(2)领域模型：业务概念的抽象、分组，整理分组之间的关联，比如用户购物的业务，抽成一个更大的模型，这个模型一般相对于行业。

(3)逻辑建模：领域模型中的业务概念实体化，并考虑实体的具体属性及实体与实体之间的关系，比如订单（订单号、付款人…）和支付（金额、支付时间…）的关系。

(4)物理模型：解决实际应用的落地开发、上线等问题，及性能等一些具体的技术问题。

另外数据模型的整个完整的过程包括：

1.业务调研定义问题

2.构建业务模型

3.明确数据定义

4.数据准备

5.构建产品模型

6.评估模型

7.模型应用

文章内容来源：CSDN 作者  Levi_