1.4.1　基本架构

“架构”是什么？这个问题从来就没有一个准确的答案。在软件行业中，一种被普遍接受的架构定义是指系统的一个或多个结构。结构中包括软件的构建（构建是指软件的设计与实现），构建的外部可以看到属性以及它们之间的相互关系。这里参考此定义，把数据仓库架构理解成构成数据仓库的组件及其之间的关系，那么就有了如图1-1所示的数据仓库架构图。

图1-1　数据仓库架构

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

这里把ETL过程分成了抽取和转换、装载两个部分。抽取过程负责从操作型系统获取数据，该过程一般不做数据聚合和汇总，但是会按照主题进行集成，物理上是将操作型系统的数据全量或增量复制到数据仓库系统的RDS（Raw Data Stores）中。转换、装载过程将对数据进行清洗、过滤、汇总、统一格式化等一系列转换操作，使数据转化为适合查询的格式，然后装载进数据仓库系统的TDS（Transformed Data Stores）中。传统数据仓库的基本模式是首先用一些过程将操作型系统的数据抽取到文件，然后用另一些过程将这些文件转化成MySQL或Oracle这样的关系数据库的记录，最后用第三部分过程把数据导入进数据仓库。

RDS是原始数据存储的意思。将原始数据保存到数据仓库里是个不错的想法。ETL过程的bug或系统中的其他错误是不可避免的，保留原始数据使得追踪并修改这些错误成为可能。有时，数据仓库的用户会有查询细节数据的需求，这些细节数据的粒度与操作型系统的相同。有了RDS，这种需求就很容易实现，用户可以查询RDS里的数据且不会影响业务系统的正常运行。这里的RDS实际上是起到了操作型数据存储（Operational Data Store，ODS）的作用，关于ODS相关内容将在1.4.3小节详细论述。

TDS意为转换后的数据存储。这是真正的数据仓库中的数据。大量的用户会在经过转换的数据集上处理他们的日常查询。如果前面的工作做得好，这些数据将以保证最重要的和最频繁的查询能够快速执行的方式构建出来。

这里的原始数据存储和转换后的数据存储是逻辑概念，它们可能物理存储在一起，也可能分开。当原始数据存储和转换后的数据存储物理上分开时，它们不必使用同样的软硬件。传统数据仓库中，原始数据存储通常是本地文件系统，原始数据被组织进相应的目录中，这些目录是基于数据从哪里抽取或何时抽取建立（例如以日期作为文件或目录名称的一部分）；转换后的数据存储一般是某种关系数据库。

自动化调度组件的作用是自动定期重复执行ETL过程。不同角色的数据仓库用户对数据的更新频率要求也会有所不同，财务主管需要每月的营收汇总报告，而销售人员想看到每天的产品销售数据。作为通用的需求，所有数据仓库系统都应该能够建立周期性自动执行的工作流作业。传统数据仓库一般利用操作系统自带的调度功能（如Linux的cron或Windows的计划任务）来实现作业自动执行。

数据目录有时也被称为元数据存储，它可以提供一份数据仓库中数据的清单。用户通过它可以快速解决这些问题：什么类型的数据被存储在哪里？数据集的构建有何区别？数据最后的访问或更新时间，等等。此外，还可以通过数据目录感知数据是如何被操作和转换的。一个好的数据目录是让用户体验到系统易用性的关键。

查询引擎组件负责实际执行用户查询。传统数据仓库中，它可能是存储转换后数据的Oracle、MySQL等关系数据库系统内置的查询引擎，还可能是以固定时间间隔向其导入数据的OLAP立方体，如Essbase cube。

用户界面指的是最终用户所使用的接口程序。可能是一个GUI软件，如BI套件中的客户端软件，也可能就是一个浏览器。