一. 基本架构

架构是指系统的一个或多个结构。结构中包括软件的构建（指软件的设计与实现），软件的外部可以看到属性以及它们之间的相互关系。

我们把数据仓库架构理解成构成数据仓库的组件及其之间的关系，如下图：
在这里插入图片描述

图中显示的整个数据仓库环境包括操作型系统和数据仓库系统两大部分。

操作型系统的数据

操作型系统的数据由各种形式的业务数据组成，这其中可能有关系数据库、TXT或CSV文件、HTML或XML文档，还可能存在外部系统的数据，比如网络爬虫抓取来的互联网数据等，数据可能是结构化、半结构化、非结构化的。这些数据经过抽取、转换和装载（ETL）过程进入数据仓库系统。

ETL过程
这里把ETL过程分成了抽取和转换装载两个部分。

抽取（E）
抽取过程负责从操作型系统获取数据，该过程一般不做数据聚合和汇总，但是会按照主题进行集成，物理上是将操作型系统的数据全量或增量复制到数据仓库系统的RDS中。

转换装载（TL）
转换装载过程将数据进行清洗、过滤、汇总、统一格式化等一系列转换操作，使数据转为适合查询的格式，然后装载进数据仓库系统的TDS中。

二. 主要数据仓库架构

数据仓库技术演化过程中，产生了几种主要的架构方法，包括数据集市架构、Inmon企业信息工厂架构、Kimball数据仓库架构和混合型数据仓库架构。

1. 数据集市架构

数据集市是按主题域组织的数据集合，用于支持部门级的决策。有两种类型的数据集市：独立数据集市和从属数据集市。

1.1. 独立数据集市

独立数据集市集中于部门所关心的单一主题域，数据以部门为基础部署，无须考虑企业级别的信息共享与集成。例如，制造部门、人力资源部门和其他部门都各自有他们自己的数据集市。

一个典型的独立数据集市架构如图所示。
在这里插入图片描述

独立数据集市的特点：

因为一个部门的业务相对于整个企业要简单，数据量也小得多，所以部门的独立数据集市具有周期短、见效快的特点。

每个部门相互独立构建，可能出现数据重叠、不一致等
如果从企业整体的视角来观察这些数据集市，你会看到每个部门使用不同的技术，建立不同的ETL的过程，处理不同的事务系统，而在多个独立的数据集市之间还会存在数据的交叉与重叠，甚至会有数据不一致的情况。

跨部门分析力不从心
从业务角度看，当部门的分析需求扩展，或者需要分析跨部门或跨主题域的数据时，独立数据市场会显得力不从心。而当数据存在歧义，比如同一个产品，在A部门和B部门的定义不同时，将无法在部门间进行信息比较。

1.2. 从属数据集市

从属数据集市的数据来源于数据仓库。数据仓库里的数据经过整合、重构、汇总后传递给从属数据集市。

在这里插入图片描述

建立从属数据集市的好处主要有：

● 性能：当数据仓库的查询性能出现问题，可以考虑建立几个从属数据集市，将查询从数据仓库移出到数据集市。
● 安全：每个部门可以完全控制他们自己的数据。
● 数据一致：因为每个数据集市的数据来源都是同一个数据仓库，有效消除了数据不一致的情况

1.3. Inmon企业信息工厂架构

介绍了两种数据集市，我们看下Inmon企业是如何构建数据仓库的
在这里插入图片描述

● 应用系统：
这些应用是组织中的操作型系统，用来支撑业务。操作型系统也叫源系统，为数据仓库提供数据。

● ETL过程：
ETL过程从操作型系统抽取数据，然后将数据转换成一种标准形式，最终将转换后的数据装载到企业级数据仓库中。ETL是周期性运行的批处理过程。

● 企业级数据仓库：
是该架构中的核心组件。企业级数据仓库是一个细节数据的集成资源库。其中的数据以最低粒度级别被捕获，存储在满足三范式设计的关系数据库中。（ing）

● 部门级数据集市：
是面向主题数据的部门级视图，数据从企业级数据仓库获取。数据在进入部门数据集市时可能进行聚合。数据集市使用多维模型设计，用于数据分析。
重要的一点是，所有的报表工具、BI工具或其他数据分析应用都从数据集市查询数据（提升效率），而不是直接查询企业级数据仓库。

2. Kimball数据仓库架构

在这里插入图片描述

Kimball与Inmon两种架构的主要区别在于核心数据仓库的设计和建立。Kimball的数据仓库包含高粒度的企业数据，使用多维模型设计，这也意味着数据仓库由星型模式的维度表和事实表构成。

分析系统或报表工具可以直接访问多维数据仓库里的数据。

Kimball的数据集市是一个逻辑概念，只是多维数据仓库中的主题域划分，并没有自己的物理存储，也可以说是虚拟的数据集市。

3. 混合型数据仓库架构

在这里插入图片描述
所谓的混合型结构，指的是在一个数据仓库环境中，联合使用Inmon和Kimball两种架构。

从架构图可以看到，这种架构将Inmon方法中的数据集市部分替换成了一个多维数据仓库，而数据集市则是多维数据仓库上的逻辑视图。

使用这种架构的好处是，既可以利用规范化设计消除数据冗余，保证数据的粒度足够细；又可以利用多维结构更灵活地在企业级实现报表和分析。(一般的企业都应该是这样设计的？)

三. 操作数据存储（ODS）

操作数据存储又称为ODS，是Operational Data Store的简写，其定义是这样的：一个面向主题的、集成的、可变的、当前的细节数据集合，用于支持企业对于即时性的、操作性的、集成的全体信息的需求。

操作型数据存储在某些方面具有类似于数据仓库的特点，但在另一些方面又显著不同于数据仓库。

和数据仓库一样，是面向主题的。
和数据仓库一样，其数据是完全集成的。
数据是当前的，这与数据仓库存储历史数据的性质明显不同。ODS具有最少的历史数据（一般是30天到60天），而尽可能接近实时地展示数据的状态。
数据是可更新的，这是与静态数据仓库又一个很大的区别。ODS就如同一个事务处理系统，当新的数据流进ODS时，受其影响的字段被新信息覆盖。
数据几乎完全是细节数据，仅具有少量的动态聚集或汇总数据。通常将ODS设计成包含事务级的数据，即包含该主题域中最低粒度级别的数据。
在数据仓库中，几乎没有针对其本身的报表，报表均放到数据集市中完成；与此不同，在ODS中，业务用户频繁地直接访问ODS。

在一个数据仓库环境中，ODS具有如下几个作用

充当业务系统与数据仓库之间的过渡区
数据仓库的数据来源复杂，可能分布在不同的数据库，不同的地理位置，不同的应用系统之中，而且由于数据形式的多样性，数据转换的规则往往极为复杂。如果直接从业务系统抽取数据并做转换，不可避免地会对业务系统造成影响。而ODS中存放的数据从数据结构、数据粒度、数据之间的逻辑关系上都与业务系统基本保持一致，因此抽取过程只需简单的数据复制而基本不再需要做数据转换，大大降低了复杂性，同时最小化对业务系统的侵入。

转移部分业务系统细节查询的功能
某些原来由业务系统产生的报表、细节数据的查询能够在ODS中进行，从而降低业务系统的查询压力。

完成数据仓库中不能完成的一些功能
用户有时会要求数据仓库查询最低粒度级别的细节数据，而数据仓库中存储的数据一般都是聚合或汇总过的数据，并不存储每笔交易产生的细节数据。
这时就需要把细节数据查询的功能转移到ODS来完成，而且ODS的数据模型是按照面向主题的方式组织的，可以方便地支持多维分析。即数据仓库从宏观角度满足企业的决策支持要求，而ODS层则从微观角度反映细节交易数据或者低粒度的数据查询要求。

参考：《Hadoop构建数据仓库实践》