数据仓库基本架构是怎么样的

这篇文章主要为大家展示了“数据仓库基本架构是怎么样的”，内容简而易懂，条理清晰，希望能够帮助大家解决疑惑，下面让小编带领大家一起研究并学习一下“数据仓库基本架构是怎么样的”这篇文章吧。

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

元数据管理

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

以上是“数据仓库基本架构是怎么样的”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注亿速云行业资讯频道！