数据仓库（Data Warehouse）是一个面向主题的、集成的、相对稳定的、且随时间变化的数据集合，用于支持管理决策。

主题是一个抽象的概念，是指用户使用数据仓库进行决策时所关心的重点方面，一个主题通常与多个操作型信息系统相关。

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

数据仓库的数据主要供企业决策分析之用，所涉及的数据操作主要是数据查询，一旦某个数据

进入数据仓库以后，一般情况下将被长期保留，也就是数据仓库中一般有大量的查询操作，

但修改和删除操作很少，通常只需要定期地加载、刷新。

数据仓库中的数据通常包含历史信息，系统记录了企业从过去某一时点（如开始应用数据仓库的时点）到目前的各个阶段的信息。

数据仓库反映历史变化的属性主要表现在：

    数据仓库中的数据时间期限要远远长于传统操作型数据系统中的数据时间期限，数据仓库中的数据时间期限往往为数年甚至几十年。

    数据仓库中的数据仅仅是一系列某一时刻（可能是传统操作型数据系统）生成的复杂的快照；

    数据仓库中一定会包含时间元素。

数据库与数据仓库的差异

   从数据存储的内容看，数据库只存放当前值，而数据仓库则存放历史值；数据库数据的目标是面向业务操作人员的，为业务处理人员提供数据处理的支持，而数据仓库则是面向中高层管理

人员的，为其提供决策支持等。



数据仓库的结构

从数据仓库的概念结构看，一般来说，数据仓库系统要包含数据源、数据准备区、数据仓库数据库、数据集市/知识挖掘库及各种管理工具和应用工具，如图 3-10 所示。数据仓库建立之后，首先要从数据源中抽取相关的数据到数据准备区，在数据准备区中经过净化处理后再加载到数据仓库数据库，最后根据用户的需求将数据导入数据集市和知识挖掘库中。当用户使用数据仓库时，可以利用包括 OLAP（On-Line Analysis Processing，联机分析处理）在内的多种数据仓库应用工具向数据集市/知识挖掘库或数据仓库进行决策查询分析或知识挖掘。数据仓库的创建、应用可以利用各种数据仓库管理工具辅助完成。



数据仓库框架由数据仓库基本功能层、数据仓库管理层和数据仓库环境支持层组成。



 

数据仓库基本功能层。

       数据仓库的基本功能层部分包含数据源、数据准备区、数据仓库结构、数据集市或知识挖掘库，以及存取和使用部分。

数据仓库管理层。

     数据仓库管理层由数据仓库的数据管理和数据仓库的元数据管理组成。

    数据仓库的数据管理层包含数据抽取、新数据需求与查询管理，数据加载、存储、刷新和更新系统，安全性与用户授权管理系统及数据归档、恢复及净化系统等四部分。

数据仓库的环境支持层。

      数据仓库的环境支持层由数据仓库数据传输层和数据仓库基础层组成。

 

数据仓库架构图：

数据仓库之OLAP与OLTP区别
关于数据仓库
数据仓库的定义
数据仓库的目的
数据仓库的特征
数据库与数据仓库的区别实际讲的是OLTP与OLAP的区别
OLTP（联机事务处理）
OLAP（联机分析处理）
OLTP与OLAP区别（图）

关于数据仓库
数据仓库的定义
一个面向主题，集成的，稳定，随时间变化的数据集合，以用于支持管理的决策过程。
数据仓库的目的
通过集成不同的系统信息为企业提供统一的决策分析平台，帮助企业解决实际的业务问题。
数据仓库的特征
①面向主题     ②集成   ③稳定性即非易失得④随时间而变化即时变化的
如今，数据仓库已经成为商务智能由数据到知识，由知识转化为利润的基础和核心技术
数据库与数据仓库的区别实际讲的是OLTP与OLAP的区别
OLTP（联机事务处理）
操作型处理，叫联机事务处理OLTP（On-Line TransactionProcessing），也可以称面向交易的处理系统，它是针对具体业务在数据库联机的日常操作，通常对少数记录进行查询、修改。用户较为关心操作的响应时间、数据的安全性、完整性和并发支持的用户数等问题。传统的数据库系统作为数据管理的主要手段，主要用于操作型处理。
OLAP（联机分析处理）
分析型处理，叫联机分析处理OLAP（On-Line Analytical Processing）一般针对某些主题的历史数据进行分析，支持管理决策。
OLTP与OLAP区别（图）
讲太多的概念型的东西确实不那么理解，根据《数据仓库与数据挖掘实践》一个简单的图表共大家分享OLTP与OLAP的区别 。





总结：以上为最近学习的数据仓库知识分享，小白也要和大家一起加油学习！

元数据
元数据概述
元数据的分类
①管理元数据
②用户元数据
元数据的作用

元数据概述
元数据：描述其它数据的数据（data about other data）
元数据是关于数据的数据，在某些时候不特指某个单独的数据，可以理解为是一组用来描述数据的信息组/数据组，该信息组/数据组中的一切数据、信息，都描述/反映了某个数据的某方面特征，则该信息组/数据组可称为一个元数据。
元数据可以为数据说明其元素或属性（名称、大小、数据类型等），或其结构（长度、字段、数据列），或其相关数据（位于何处、如何联系、拥有者）。
在日常生活中，元数据无所不在。只要有一类事物，就可以定义一套元数据。
元数据的分类
①管理元数据
管理元数据主要为负责开发，维护数据仓库的人员使用。管理元数据时存储关于数据仓库系统技术细节的数据，是用于开发和管理数据仓库使用的数据。
②用户元数据
用户元数据从业务角度描述了数据仓库中的数据，它提供了介于使用者和实际系统之间的语义层，使得不懂计算机技术的业务人员也能够读懂数据仓库中的数据。
元数据的作用
①元数据是进行数据集成所必须的。

②元数据可以帮助最终用户理解数据仓库中的数据。

③元数据是保证数据质量的关键。

④元数据可以支持需求化。
参考资料 《数据仓库与数据挖掘实践》

为什么需要数据仓库？

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

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

       在产品脑图中可以很清晰的看到根据业务需求设计所需的字段，因此也导致数据库是根据业务需求进行设计。

       那么有的会问，为什么一开始就不考虑好这个扩展性呢？为什么数据库一开始就不以数据仓库的形式设计？

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

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

小结：

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

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

 

什么是数据仓库？

       数据仓库（Data Warehouse）简称DW或DWH，是数据库的一种概念上的升级，可以说是为满足新需求设计的一种新数据库，而这个数据库是需容纳更多的数据，更加庞大的数据集，从逻辑上讲数据仓库和数据库是没有什么区别的。

       为企业所有级别的决策制定过程，提供所有类型数据支撑的战略集合，主要是用于数据挖掘和数据分析，以建立数据沙盘为基础，为消灭消息孤岛和支持决策为目的而创建的。

数据仓库发展过程

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

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

 

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

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

      

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

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

 

数据仓库特点

面向主题

       是企业系统信息中的数据综合、归类并进行分析的一个抽象，对应企业中某一个宏观分析领域所涉及的分析对象。

       比如购物是一个主题，那么购物里面包含用户、订单、支付、物流等数据综合，对这些数据要进行归类并分析，分析这个对象数据的一个完整性、一致性的描述，能完整、统一的划分对象所设计的各项数据。

       如果此时要统计一个用户从浏览到支付完成的时间时，在购物主题中缺少了支付数据或订单数据，那么这个对象数据的完整性和一致性就可能无法保证了。

 

数据集成

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

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

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

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

 

不可更新

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

       数据仓库的查询量往往很大，所以对数据查询提出了更高的要求，要求采用各种复杂的索引技术，并对数据查询的界面友好性和数据凸显性提出更高的要求。

 

随时间不断变化

       数据仓库中的数据不可更新是针对应用来说，从数据的进入到删除的整个生命周期中，数据仓库的数据是永远不变的。

       数据仓库的数据是随着时间变化而不断增加新的数据。

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

       数据仓库中包含大量的综合性数据，这些数据很多是跟时间有关的，这些数据特征都包含时间项，以标明数据的历史时期。

 

数据仓库和数据库的区别

       数据库的操作：一般称为联机事务处理OLTP（On-Line Transaction Processing），是针对具体的业务在数据库中的联机操作，具有数据量较少的特点，通常对少量的数据记录进行查询、修改。

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


			
比较项
			
			

			
操作型（OLTP）
			
			

			
分析性（OLAP）
			
		

			
关注
			
			

			
细节
			
			

			
综合或提炼
			
		

			
模型
			
			

			
实体 – 关系（E-R）
			
			

			
星型或雪花
			
		

			
操作
			
			

			
可更新
			
			

			
只读，只追加
			
		

			
操作粒度
			
			

			
操作一个单元
			
			

			
操作一个集合
			
		

			
场景
			
			

			
面向事务
			
			

			
面向分析
			
		

			
数据量
			
			

			
小
			
			

			
大
			
		

			
需求
			
			

			
日常操作
			
			

			
决策需求
			
		

			
业务方向
			
			

			
客户信息、订单等查询
			
			

			
客户登录间隔时间，市场细分等
			
		
 

数据仓库常用系统架构

 



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

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

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

 

为什么要分层？

       在未分层的情况下，数据之间的耦合性与业务耦合性是不可避免的，当源业务系统的业务规则发生变化时，可能影响整个数据的清洗过程。

       数据分层简化了数据清洗的过程，每一层的逻辑变得更加简单和易于理解，当发生错误或规则变化时，只需要进行局部调整。

通过大量的预处理来提升应用系统查询速度，进而提升的用户体验，因此数据仓库会冗余大量的数据，是典型的空间换时间的策略。

 

元数据

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

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

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

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

 



 

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

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

       通过模型的建设，我们可以很清晰的看到数据之间内在的关联关系，从而建立起全方位的数据视角，并消灭信息孤岛和数据差异化的问题，进而保证数据的一致性。

       模型可以很好的帮助我们分离出底层技术的实现和上层业务的展现，当上层业务发生变化时，通过数据模型，底层的技术实现可以适应的了业务的变动，进而解决数据库的灵活性。

       在模型中可以很好的看出开发人员和业务人员之间的系统建设范围的界定，及未来的规划。

 

什么是数据模型？

       数据模型是数据关系的一种映射， 就是将业务之间的关系，用模型图形化的描绘出来，而不再是脑海的一个模糊的关系。

       在设计数据仓库模型和架构时，我们需要懂具体的技术，也需要了解行业的知识和经验来帮助我们对业务进行抽象、处理，进而生成各个阶段的模型。

 

数据模型架构

 



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

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

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

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

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

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

 

维度和指标（度量）

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

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

       指标（度量）就是从维度的基础上去衡算这个结果的值。

       比如银行采集数据：


			
时间（维度）
			
			

			
分行（维度）
			
			

			
存款额（指标）
			
		

			
1999年
			
			

			
A分行
			
			

			
1000W
			
		

			
2000年
			
			

			
A分行
			
			

			
2000W
			
		

			
2001年
			
			

			
A分行
			
			

			
3000W
			
		

			
1999年
			
			

			
B分行
			
			

			
500W
			
		

			
2000年
			
			

			
B分行
			
			

			
1600W
			
		

			
2001年
			
			

			
B分行
			
			

			
3300W
			
		
       维度一般是一个离散的值，比如时间维度上每一个独立的日期或地域，因此统计时，可以把维度相同记录的聚合在一起，应用聚合函数做累加、均值、最大值、最小值等聚合计算。

       指标（度量）就是被聚合的通计算，即聚合运算的结果，一般是一个连续的值。

       比如我们可以从银行的存款额和企业的贷款额之间的计算，推算出目前的市场状况是如何，如果企业的贷款额高，银行的存款额也高，说明人们不愿意消费了，都把钱存起来，企业产品卖不出去，要发工资，那么自然要贷款了，这只是一个例子，具体还需要结合很多数据做分析。

 

事实表和维度表

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

       事实表（Fact Table）是指存储有事实记录的表，如系统的日志、销售记录、用户访问日志等信息，事实表的记录是动态的增长的，所以体积是大于维度表。

       用户访问日志（事实表）：用户名、url、时间…

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

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

       省份表（维度表）：北京市、广东省、上海市…

 

数据模型建立过程

 



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

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

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

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

 

范式建模法



       数据仓库的概念模型（域模型）应该包含企业数据模型的概念模型（域模型）之间的关系，以及各主题域的定义。

       数据仓库的概念模型（域模型）应该比业务系统的主题域模型范围更加广。

       在数据仓库的逻辑模型需要从业务系统的数据模型中的逻辑模型中抽象实体，实体的属性，实体的子类、关系等，在某些时候反而限制了数据仓库模型的灵活性，在底层数据向数据集市汇总时，需要进行一定的变通。

 

维度建模法



       维度建模法的特点在于需要进行大量的数据预处理、预计算，因此会导致大量的数据处理工作，而且业务发生变化，需要重新进行维度的定义时，往往需要重新进行维度数据的预处理、预计算，使用时直接调用计算好的结果，进而导致大量的数据冗余，最大的作用就是解决了性能的问题。

 

实体建模法



       实体建模法是一种抽象客观世界的方法，细分为一个个实体，以及实体之间的关系，将一个业务划分为3个过程，因此只能局限在业务建模和领域建模的阶段，因此到了逻辑建模阶段和物理建模阶段，则是范式和维度建模的发挥了。

 

星型模型架构 VS 雪花模型架构

       当设计好概念模型时，就要根据概念模型设计逻辑模型，而在设计逻辑模型是，通常根据事实表和维度表的关系，将常见的模型架构分为星型模型和雪花型模型。

       星型模型架构是一种非正规化的结构，特点是有一张事实表，多张维度表，是不存在渐变维度的，事实表和维度表通过主外键相关联，维度表之间是没有关联，因为维度表的数据冗余，所以统计查询时不需要做过多外部连接。

        雪花模型架构就是将星型模型中的某些维度表抽取成更细粒度的维度表，然后让维度表之间也进行关联，通过最大限度的减少数据存储量以及联合较小的维度表来改善查询性能。

 



 

      《怎样分析数据致提高产出？》https://blog.csdn.net/Su_Levi_Wei/article/details/103794163