数据仓库的基本架构

数据仓库的基本架构
数据仓库的目的是构建面向分析的集成化数据环境，为企业提供决策支持（Decision Support）。其实数据仓库自己并不“生产”任何数据，同时自身也不须要“消费”任何的数据，数据来源于外部，而且开放给外部应用，这也是为何叫“仓库”，而不叫“工厂”的缘由。所以数据仓库的基本架构主要包含的是数据流入流出的过程，能够分为三层——源数据、数据仓库、数据应用：

从图中能够看出数据仓库的数据来源于不一样的源数据，并提供多样的数据应用，数据自上而下流入数据仓库后向上层开放应用，而数据仓库只是中间集成化数据管理的一个平台。
数据仓库的数据来源
数据仓库从各数据源获取数据及在数据仓库内的数据转换和流动均可以认为是ETL（抽取Extra, 转化Transfer, 装载Load）的过程，ETL是数据仓库的流水线，也能够认为是数据仓库的血液，它维系着数据仓库中数据的新陈代谢，而数据仓库平常的管理和维护工做的大部分精力就是保持ETL的正常和稳定。
数据仓库的数据存储
数据仓库并不须要储存全部的原始数据，同时数据仓库须要储存部分细节数据。简单地解释下：
a.为何不须要全部原始数据？数据仓库面向分析处理，可是某些源数据对于分析而言没有价值或者其可能产生的价值远低于储存这些数据所须要的数据仓库的实现和性能上的成本。好比咱们知道用户的省份、城市足够，至于用户究竟住哪里可能只是物流商关心的事，或者用户在博客的评论内容可能只是文本挖掘会有须要，但将这些冗长的评论文本存在数据仓库就得不偿失；
b.为何要存细节数据？细节数据是必需的，数据仓库的分析需求会时刻变化，而有了细节数据就能够作到以不变应万变。若是咱们只存储根据某些需求搭建起来的数据模型，那么显然对于频繁变更的需求会手足无措；
c.为何要面向主题？面向主题是数据仓库的第一特性，主要是指合理地组织数据以方面实现分析。对于源数据而言，其数据组织形式是多样的，像点击流的数据格式是未经优化的，前台数据库的数据是基于OLTP操做组织优化的，这些可能都不适合分析，而整理成面向主题的组织形式才是真正地利于分析的，好比将点击流日志整理成页面（Page）、访问（Visit或Session）、用户（Visitor）三个主题，这样能够明显提高分析的效率。
数据仓库基于维护细节数据的基础上在对数据进行处理，使其真正地可以应用于分析。主要包括三个方面：
1.数据的聚合
这里的聚合数据指的是基于特定需求的简单聚合（基于多维数据的聚合体如今多维数据模型中），简单聚合能够是网站的总Pageviews、Visits、Unique Visitors等汇总数据，也能够是Avg. time on page、Avg. time on site等平均数据，这些数据能够直接地展现于报表上。
2.多维数据模型
多维数据模型提供了多角度多层次的分析应用，好比基于时间维、地域维等构建的销售星形模型、雪花模型，能够实如今各时间维度和地域维度的交叉查询，以及基于时间维和地域维的细分。因此多维数据模型的应用通常都是基于联机分析处理（Online Analytical Process, OLAP）的，而面向特定需求群体的数据集市也会基于多维数据模型进行构建。
3.业务模型
这里的业务模型指的是基于某些数据分析和决策支持而创建起来的数据模型，好比用户评价模型、关联推荐模型、RFM分析模型等，或者是决策支持的线性规划模型、库存模型等；同时，数据挖掘中前期数据的处理也能够在这里完成。

数据仓库的数据应用
报表展现
报表几乎是每一个数据仓库的必不可少的一类数据应用，将聚合数据和多维分析数据展现到报表，提供了最为简单和直观的数据。
即时查询
理论上数据仓库的全部数据（包括细节数据、聚合数据、多维数据和分析数据）都应该开放即时查询，即时查询提供了足够灵活的数据获取方式，用户能够根据本身的须要查询获取数据。
数据分析
数据分析大部分基于构建的业务模型展开，固然也可使用聚合的数据进行趋势分析、比较分析、相关分析等，而多维数据模型提供了多维分析的数据基础；同时从细节数据中获取一些样本数据进行特定的分析也是较为常见的一种途径。
数据挖掘
数据挖掘用一些高级的算法可让数据展示出各类使人惊讶的结果。数据挖掘能够基于数据仓库中已经构建起来的业务模型展开，但大多数时候数据挖掘会直接从细节数据上入手，而数据仓库为挖掘工具诸如SAS、SPSS等提供数据接口。

数据仓库的开发流程：

第1天到第n天的现象
创建数据仓库不是一蹴而就的。相反，数据仓库只能一次一步地进行设计和载入数据，即它是进化性的，而非革命性的。数据仓库的创建要采用有序地反复和一次一步的方式。下图说明一个创建数据仓库的典型过程。

第1天，通晓本质上进行操做型处理的几个系统。
第2天，对数据仓库中第一个主题领域的最初几个表载入数据，此时就会产生必定的好奇心，用户开始发现数据仓库和分析处理。
第3天，更多的数据载入数据仓库，而且随着数据量增大，将吸引更多的用户。一旦用户发现有较容易载入的集成数据源，并有在时间维上观察数据的历史基础，这就不只仅是好奇心了。大约此时，认真的DSS分析员渐渐地被吸引到数据仓库中。
第4天，随着更多的数据载入数据仓库，一批存储在操做型环境的数据被适当地放入数据仓库中。如今，咱们就“发现”数据仓库是可用来进行分析处理的信息源。各类各样的DSS应用出现了。的确，伴随着如今存入数据仓库的大规模数据，此时开始出现如此多的用户和如此多的处理请求，以至于一些用户进入数据仓库的要求和分析工做被推迟。进入数据仓库的竞争成为使用数据仓库的障碍。
第5天，部门数据库(数据集市，或OLAP )开始兴起，各部门发现经过把数据从数据仓库输入它们本身的部门处理环境，会使它们的处理既便宜又容易。到达部门级的数据吸引着一些D S S分析员。
第6天，部门系统出现繁忙，获得部门数据比得到数据仓库的数据更便宜、更快、更容易。很快最终用户就放弃数据仓库的细节，去进行部门处理。
第n天，这种体系结构获得充分发展。生产系统的原始集合中只剩下操做型处理。数据仓库具备丰富的数据，并有一些数据仓库的直接用户和许多部门数据库。由于在部门级上得到处理所须要的数据既容易又便宜，因此大部分DSS分析处理都在部门级进行。
固然，从第1天到第n天的进化须要很长的时间，一般须要几年。而且在从第1天到第n天的处理过程当中，DSS环境在不断地提升和职能化。

元数据管理

元数据（Meta Date），其实应该叫作解释性数据，或者数据字典，即数据的数据。主要记录数据仓库中模型的定义、各层级间的映射关系、监控数据仓库的数据状态及ETL的任务运行状态。通常会经过元数据资料库（Metadata Repository）来统一地存储和管理元数据，其主要目的是使数据仓库的设计、部署、操做和管理能达成协同和一致。