数据挖掘、数据仓库,近些年在国内越来越热、越来越流行,需求比较多,应用也比较广泛,它们常服务于商务智能活动。通俗地概括来讲,我们可将它们统称作数据分析、数据计算。
我们介绍数据仓库在商业应用,主要涉及有两个方面,一个是有关数据仓库的常用技术,另一个是有关数据仓库的应用案例。同时也涉及数据仓库的两个背景,在我们经历的北美项目中,一个主要方面属于实际的商业应用项目,另一方面属于高校的学术研究领域的项目。两者在很多方面有明显的区别。我们这里主要介绍数据仓库的商业应用,因为商业应用经验存在比较大的价值。
数据仓库的商业应用技术之一:异构数据集成技术
数据仓库是集成的,数据仓库的要素包括本身是集成的、面向主题的、只读的、历史变化的。
如下图1:
例如,应用Oracle作为数据仓库的支撑环境,它有很多数据源,是由业务生产系统源源不断产生的,可能包括DB2、SQL Server、MY SQL等等不同的源数据。
异构数据集成的方法有很多,主要包括:
1. 如果Oracle作为数据仓库是基于Windows环境的,通过MS ODBC开放数据库互联;第三方ODBC开放数据库互联,如Data Direct Connect for ODBC;专用数据网关,如Transpatent Gateway;
2. 如果Oracle作为数据仓库是基于Unix或Linux环境的,通过Unix ODBC开放数据库互联;专用数据网关等。
3. 通过外部文件到数据库的导出和导入。
数据仓库的商业应用技术之二:数据的ETL抽取、变换、载入技术
1. 三层ETL体系
我们将数据的抽取、变换、载入技术称为ETL技术。ETL技术中,按要素分为三层,即元数据层、数据操纵层、数据存储层,三层交互作用。ETL工作首先需要在元数据层定义和构建,同时也涉及到有关数据存储的方式定义;基于元数据层的对象,ETL工作在数据操纵层对数据进行实际操作,并把数据载入到数据存储层;ETL工作还需要在数据存储层做一些必要的数据管理和优化工作。这就形成了ETL数据操纵的三层体系,如下图。
元数据 -> 数据操作层 -> 数据存储层。
2. ETL递进式数据演变
ETL数据变换在实际项目中有很多的方法,很多阶段,在此我们根据经验分为4个阶段为:
LANDING:抽取数据到Landing层中。
STAGING:根据我们业务的要求进行数据变换到Staging层中。
DATA CENTER:再根据需求设计放在Data Center层(也是EDW企业级数据仓库)中。
DATA MART:最后根据主题存放在Data Mart层中,如下图。
3. 并行ETL架构
并行处理技术也是数据库的一项核心技术,它可以提高ETL过程中在数据层处理的执行效率,将大量的查询过程分布到多个节点上同时执行。一个并行处理体系结构的数据仓库系统,不仅应该确保底层硬件平台的所有资源都得充分利用,而且应该能够将这些资源适当分配给多个并发请求,以提高数据层的并发处理能力,如下图。
4. ETL任务调度及备份
ETL任务调度(Scheduling Tasks)很重要,需要实时的备份。常用的ETL任务调度工具(Scheduling Tools)有:
Unix scripts:Corn有比较稳定的可靠性。
Database Management Tool:Oracle Enterprise Manager
Third Party Tool:Control-M专用工具,专门为数据仓库完成任务,主要做ETL的Scheduling。
ETL任务调度备份方法有很多,如:
Scheduling Backup:Control-M as Master,
Unix Corn as Backup.
这样,相当于做了两个Scheduling设计,互为备份。
数据仓库的商业应用技术之三:数据仓库的架构技术
1. 多层次企业级数据仓库:DataMart-> EDW
在这个数据仓库架构的模型中,左边的是数据源通过变换到数据集市中,然后从数据集市再到企业级数据仓库(EDW)中,最后直接给终端用户使用。多层次主要体现在ETL和数据集成上,这个方法的优点在于建立了多个数据集市,它体现了一个分布式集成的概念,很大程度降低了企业级数据仓库建设的风险,更减少了资源投入,如下图。
2. 多层次企业级数据仓库: EDW -> DataMart
这个模型一开始就设计它的企业级数据仓库(EDW),这种方法针对于一些涵盖了多个业务系统、面向不同用户的需求、针对数据平台也不一样的企业,例如:银行。用这个方法,把所有的业务系统考虑入内,通常考虑整体设计,然后再分发出去。DataMart划分方法有很多种。它的优点是集成度比较好,总体设计一开始就把所有的数据源都放到企业级数据仓库。缺点是风险高,投入也相对很高,如下图。
通常来说,实际项目中采用第一种方法的比较多。
3. 近实时的数据仓库
数据仓库是动态的,是随时间变化的。应用数据仓库,我们可以每天、每个月、每年分段来调取数据,如下图。
近实时(Near Real Time)的要求是比较高的,例如我们建立了一个数据仓库是全球性的,数据仓库中心在多伦多,数据源分布在很多地方如北美、欧洲,它需要一个近实时的操作系统。近实时的概念是操作系统和业务系统产生的数据,在一小时之内完成所有ETL任务,最后进入数据仓库。它对数据源的业务系统有比较高的要求,如数据的稳定性、可靠性、网络传输速率等,同时也涵盖了很多方面的专门技术来解决实时性。
4. 后复合数据集市
由于业务的扩展,企业增加了一个新的生产系统,从而诞生了新的数据源。我们需要建立一个新的数据源(New Data Source)通过ETL工作集成到数据集市(DMART)中,并与企业级数据仓库(EDW)结合到一起,最后提供给终端用户,如下图。
数据仓库的商业应用技术之四:数据仓库的优化技术
数据仓库优化包括很多内容,包括数据库实例优化、数据库的设计优化、数据仓库设计(建模)优化、数据存储优化、存储过程优化、中间层支持优化、应用支持优化(智能报表、即时查询、数据挖掘等应用)。
数据仓库的客户有两个常见要求,一个要求是快,还有一个要求是稳定。快有很多方面,在核心的数据库,有太多的因素影响速度,所以优化时要各个方面都要考虑。
1. 数据仓库设计(建模)优化
在设计的时候有很多的情况发生,在这里重点提一点,数据仓库还要考虑一个时间的因素,有的时候开始设计的时候性能非常好,但随着系统长时间的运行,发生了很多无法解决的、由设计造成的问题,如性能问题。曾经有欧洲的一家汽车企业,设计师对数据仓库的模型设计想法非常好,但是不适宜一个长时间的运行,数据增长以后性能大幅下降,数据运行可能会非常的慢,到了无法容忍的地步,结果导致运行两年以后就不行了。想要再进行结构修改也不可行了,必须要全部重来。
2. 数据存储优化
数据存储优化主要是如何尽量减小存储空间和提升性能。这点很重要,数据仓库往往都是牺牲空间来提升速度。但是也需要优化,很多问题在一些小的数据仓库系统可能都不存在,但是在比较大型的数据仓库系统中就会出现了。数据仓库数据不断增加,当使用时间比较长之后就会造成数据量过大、性能会大幅下降,为了避免这样的情况,我们在开始设计时,就要考虑到后续的使用,需要进行数据存储优化,主要包括:
Data Block Design:基本存储单位的设计。
Table Spacing:表空间的设计。
Table Partitioning:表空间的优化。
Indexing:索引的设计。
Index Partitioning:索引优化。
Data Compressing:数据压缩(同时会牺牲一些性能)。
3. 存储过程优化:就是后台的一些存储过程的优化。
4. 中间层支持优化:WEB SERVER之类的系统优化。
5. 应用支持优化:主要有智能报表、即时查询、数据挖掘等应用,也就是前台的一些应用也是需要优化的。一个REQUEST发出去,返回的RESULT,这个过程是有很多的步骤,也是需要进行优化处理的。
另外,还需要在一些方面对数据仓库进行优化,如:异构数据库互联优化。异构数据库互联,做数据仓库第一步就会碰到,数据仓库肯定有很多不同的数据源。具体如下图所示。
上述例子就比较复杂,既有不同数据库,又有不同操作系统。异构数据库互联优化的案例:
A、文件导出导入 -〉开放数据库互联
由文件导出导入方案改为开放数据库互联方案,可优化异构数据库互联的性能。例如:Windows ODBC, Unix ODBC,性能和可控性上肯定会比较好一点,但是有的时候并不是这样简单的要求,还需要考虑数据安全性的要求。例如某些情况下,条件不允许做数据库的互联。还有业务系统的健壮性能也要考虑。
B、通用ODBC -〉第三方专用ODBC
由ODBC方案改为第三方专用ODBC方案,可优化异构数据库互联的性能。例如: MS ODBC -> Data Direct ODBC。
C、开放数据库互联-〉专用数据网关
由ODBC方案改为专用数据网关方案,可优化异构数据库互联的性能。例如: MS ODBC -> Transparent Gateway。