数据仓库是一个面向主题的、集成的、随时间变化的、非易失的数据集合,用于支持管理者的决策过程。
·面向主题:主题简单的说就是与业务相关的数据类别,每一个主题对应一个宏观的数据分析邻域。数据仓库被设计成辅助人们分析数据。
·集成:集成与面向主题密切相关,想要从某个层面整体的分析数据,需要将多个分散的数据源统一成一致的、无歧义的数据格式后,再放到数据仓库中。因此数据仓库必须能够解决命名冲突、单位不一致等问题。当完成这些数据整合之后,该数据仓库就可以被称为集成的。
·随时间变化:为了发现业务变化的趋势、存在的问题或者新的机会,需要分析大量的历史数据。数据仓库关注的是数据随时间变化的情况,并且能够反应出在过去某个时间点的数据是怎样的,也就是说它关注的是某一历史事件点的数据快照。但是存储结构不会无限扩展,数据不可能只入不出,数据在数据仓库中也有生命周期,到一定时间点后数据会从数据仓库中移除,移除的方式可能是将细节数据汇总后删除、将老是数据转储到大容量介质后删除或者是直接物理删除。
·非易失:数据仓库中的数据是静态的,当数据进入数据仓库后,数据就不再有改变。数据仓库环境中一般不进行数据更新,当改变的数据进入数据仓库后,这样就保留了数据变化的历史轨迹。
数据仓库还有一个重要概念是粒度,粒度指的是数据的细节或汇总程度,细节程度越高,粒度级别越低。如单个事务是低粒度级别,而一个月的事务就是高粒度级别。一般来说进入数据仓库的数据属于低粒度级别,此时应对数据进行编辑、过滤和汇总,使其适应当前数据仓库环境的粒度级别。
在一个大组织中,往往都有两种类型的系统,操作型和分析型,这两种都是以数据库作为数据管理、组织、和操作的工具。操作型系统完成组织的核心业务,核心目标是尽可能块的处理事务,同时维护数据的完整性和一致性。而分析型系统的主要作用是通过数据分析评估组织的业务经营状况,并进一步辅助决策。
操作型系统是一类专门管理面向事务的应用的系统。“事务”一词这里指的是计算机或者数据库的术语。
事务是数据库中的一个逻辑单元,事务一般代表着数据改变。数据库中使用事务一般出于两个目的:
根据事务的定义,事务具有原子性、一致性、持久性、隔离性的特点:
操作型数据库是高并发、高吞吐量的系统,具有大量检索、插入、更新操作,事务数量庞大,但每个事物影响的数据量较小。常被整合到面向服务的架构(SOA)和Web服务里。
操作型系统的数据库的操作:
分析型系统是一种快速回答多维分析查询的实现方式。是更广泛范畴的所谓商业智能的一部分(商业智能还包含数据库、报表系统、数据可视化等研究方向)。
分析型系统的数据库的操作:
在数据库层面,分析型操作系统被定义成少量的事务,复杂的查询,处理归档和历史数据。这些数据很少被修改,从数据库抽取数据是最多的操作,也是识别这种系统最关键的特征。分析型数据库基本上都是读操作。
分析型系统与操作型系统以完全不同的方式使用数据库,操作型系统更加注重数据分析和报表,而操作型系统的目标是一个版有大量数据改变的事务优化系统。
对比项 | 操作型系统 | 分析型系统 |
---|---|---|
数据源 | 应用的操作信息,一般是原始数据 历史的、归档的数据, | 一般源于数据仓库 |
侧重点 | 数据更新 | 信息的检索与报表 |
应用 | 管理系统、交易系统、在线应用等 | 报表系统、多维分析、决策支持系统等 |
用户 | 终端用户、普通雇员 | 管理人员、市场人员、数据分析师 |
任务 | 业务操作 | 数据分析 |
数据更新 | 插入、更新,要求快速执行,立即返回结果。很少用到删除 | 大量数据装载,花费时间很会长 |
数据模型 | 实体关系模型 | 多维数据模型 |
设计方法 | 规范化设计,大量的表和表之间的关系 | 星型模式和雪花模式,少量的表 |
备份 | 定期执行全部或增量备份,不允许数据丢失 | 简单备份,数据可以重新加载 |
数据的时间范围 | 从天到年 | 几年或几十年 |
查询 | 简单查询,快速返回查询结果 | 复杂查询,执行聚合和汇总操作 |
速度 | 快,大表上建立索引 | 相对较慢,需要更多的索引 |
所需空间 | 小,只存储操作数据 | 大,需要存储大量历史数据 |
把数据仓库架构理解成构成数据仓库的组件机器之间的关系(如图1)。
图中整个环境分为两个操作型系统和数据仓库系统两个部分。操作型系统中的数据可能是结构化的、半结构化的以及非结构化的。这些数据经过抽取、转换和装载(ETL)过程进入数据仓库。
这里把ELT过程分为抽取和转换装载两个部分,抽取过程负责从操作型系统获取数据,这个过程不做数据聚合和汇总,但是会按照主题进行集成,物理上是将操作型系统的数据全量或增量复制到数据仓库的RDS中。转换装载过程是将数据进行清洗、过滤、汇总、统一格式化、等一系列的转换操作,使数据转为适合查询的格式,然后装载到数据仓库的TDS中。
RDS(Raw Data Stores)是原始数据存储的意思。将原始数据保存到数据仓库里是个不错的想法。ETL过程的bug或系统中的其他错误是不可避免的,保留原始数据使得追踪并修改这些错误成为可能。有时数据仓库的用户会有查询细节数据的需求,这些细节数据的粒度与操作型系统的相同。有了RDS,这种需求就很容易实现,用户可以查询RDS里的数据而不必影响业务系统的正常运行。这里的RDS实际上是起到了操作型数据存储(ODS)的作用。
TDS(Transformed Data Stores)意为转换后的数据存储。这是真正的数据仓库中的数据。大量的用户会在经过转换的数据集上处理他们的日常查询。如果前 面的工作做得好,这些数据将被以保证最重要的和最频繁的查询能够快速执行的方式构建。
自动化调度组件的作用是自动定期执行ETL过程,传统数据仓库一般利用系统自带的调度功能(如Linux的cron或Windows的计划任务)实现作业的自动执行。
数据目录有时也被称为元数据存储,它可以提供一份数据仓库中的数据清单。
查询引擎组件负责实际执行用户查询。传统数据仓库中,它可能是存储转换后数据(Oracle、MySQL等关系数据库系统内置)的查询引擎。
数据集市架构
数据集市是按主题域组织的数据集合,用于支持部门级的决策。有两种类型的数据集市:独立数据集市和从属数据集市。
独立数据集市集中于部门所关心的单一主题域,数据以部门为基础部署,无须考虑企业级别的信息共享与集成。独立数据集市从一个主题域或一个部门的多个事务系统获取数据,用以支持特定部门的业务分析需要。一个独立数据集市的设计既可以使用实体关 系模型,也可以使用多维模型。数据分析或商业智能工具直接从数据集市查询数据,并将查询结果显示给用户。一个典型的独立数据集市架构如图所示。
一个部门的业务相对于整个企业要简单,数据量也小得多,所以部门的独立数据集市具有周期短、见效快的特点。如果从企业整体的视角来观察这些数据集市, 你会看到每个部门使用不同的技术,建立不同的ETL的过程,处理不同的事务系统,而在多个独立的数据集市之间还会存在数据的交叉与重叠,甚至会有数据不一致的情 况。从业务角度看,当部门的分析需求扩展,或者需要分析跨部门或跨主题域的数据时,独立数据市场会显得力不从心。
另外一种数据集市是从属数据集市。从属数据集市的数据来源于数据仓库。数据仓库里的数据经过整合、重构、汇总后传递给从属数据集市。从属数据集市的架构如图所示。
Inmon企业信息工厂架构
企业级数据仓库:是该架构的中心,企业级数据仓库是一个细节数据的集成资源库。其中的数据以最低粒度级别被捕获,存储在满足三范式设计的关系数据库中。
部门级数据集市: 是面向主题数据的部门级视图,数据从企业级数据仓库获取。数据在进入部门数据集市时可能进行聚合。数据集市使用多维模型设计,用于数据分析。
Kimball数据仓库架构
Kimball与Inmon两种架构的主要区别在于核心数据仓库的设计和建立。Kimball的数据仓库包含高粒度的企业数据,使用多维模型设计,这也意味着数据仓库由星型模式的维度表和事实表构成。分析系统或报表工具可以直接访问多维数据仓库里的数据。在此架构中的数据集市也与Inmon中的不同。
混合型数据仓库架构
所谓的混合型结构,指的是在一个数据仓库环境中,联合使用Inmon和Kimball两种架构。从架构图可以看到,这种架构将Inmon方法中的数据集市部分替换成了一个多维数据仓库,而数据集市则是多维数据仓库上的逻辑视图。使用这种架构的好处是,既可以利用规范化设计消除数据冗余,保证数据的粒度足够细;又可以利用多维结构 更灵活地在企业级实现报表和分析。