近两年，许多大型企业纷纷开始规划或者实施基于数据仓库技术的决策支持系统、客户关系管理系统、综合管理信息系统等各类应用分析平台。但在数据仓库项目的实施过程中，仍然存在不少对数据仓库概念的误解和应用的误区，希望本文能够帮助大家澄清部分焦点问题。
　　数据仓库是解决方案
　　数据仓库的定义比较多，现在国内使用比较广泛的是被尊称为数据仓库之父的Bill Inmon所下的定义：“数据仓库是面向主题的、集成化的、稳定的、随时间变化的数据集合，用以支持管理决策的过程。”

　　最常见的误解是把数据仓库当成产品，我们常见的Oracle、DB2、Teradata、SQL Server等都只是数据库产品（Sybase除外，其数据库与数据仓库分别是两种不同的产品），需要配合相应的ETL工具、数据展现与挖掘工具、硬件平台等，通过专业技术服务的开发与集成才能整合成符合特定需求的数据仓库解决方案。
　　数据仓库和业务处理系统一样都是一种解决方案，两者都需要一个数据库来进行驱动，只是两种系统的工作特性和负载完全不同，使得它们对于所用数据库引擎的要求也不一样。在评估数据仓库平台时需要特别注意这一点。
　　从工程的角度来看，数据仓库是一个集成的解决方案，由多种产品和专业技术服务组成，提供了一种对数据进行存储与分析的技术手段。
　　从结构上来看，一个数据仓库系统一般可以分为数据采集、数据的存储与管理、数据展现三个层次，每个层次都牵涉到一定的软硬件产品。中间的数据存储与管理层是整个数据仓库解决方案的核心，系统是否具有线性、可扩展性能和并行处理性能，主要取决于中间层的平台。
　　目的是数据的综合分析
　　我们实施数据仓库的目的不是保存数据，而是对大量的历史数据进行综合的分析和处理，帮助进行决策支持。因此明确数据仓库的信息访问流程非常重要。
　　如图所示，业务人员登录到WEB服务器后，其分析请求被传递到数据存取工具服务器。对于预先定义的报表或者多维分析，将直接从OLAP 服务器返回查询结果。对于动态的分析请求，则被转换成SQL并提交给中央数据库，经过处理后把查询结果返回到前台，以一定的方式进行展现。
　　现在国内许多数据仓库系统在使用时都局限于预先定义的多维分析和报表处理，限制了更能体现业务价值的动态分析和数据挖掘。国外一些先进企业的数据仓库系统在这方面就有很丰富的经验。他们十分注重对业务人员进行信息访问工具的培训，鼓励业务人员直接访问数据仓库，进行各种复杂分析和综合处理，以最大程度地挖掘业务价值。
　　“星形模式更适合数据仓库”说法过于片面
　　数据仓库中一个重要的环节就是建模，其中逻辑建模主要采用第三范式(Third Normal Form，简称3NF 和星形模式(Star Schema 两种方式。究竟哪一种方式更适合数据仓库呢？
　　模型规范化的过程是一种无损分解，可以从第一范式一直分解到第五范式。目前在数据仓库领域进行逻辑数据建模，大家的共识是规范到第三范式，因为更高阶的范式主要用来处理组合主键的问题，而在物理实施时还需要根据实际情况进行一定的不规范化(De-Normalize)处理。因此，用第三范式来描述数据仓库模型已经足够规范了。
　　星形模式的基本特点是由多个维表(Dimension Table)和事实表(Fact Table)组成。维表代表了相关的分析维度，事实表则是这些不同维度上的计算结果。星形模式存储了系统在不同维度上的预处理结果，因此进行多维分析时速度很快，但如果分析范围超出了预定义的维度，那么增加维度将是很困难的事情。
　　由于第三范式和星形模式的特点不同，简单地认为“星形模式更适合数据仓库”或者“第三范式更适合数据仓库”都显得过于片面。一般来说，通常使用第三范式来描述数据仓库系统后台的详细数据存储关系，在此基础上再根据特定的分析需求建立适当的星形模式，用于刷新OLAP服务器的立方体(Cube)，以方便前端数据查询和预定义的多维分析。
　　能否同时支持星形模式与第三范式？
　　笔者曾经看到一份某厂商提交给用户的报告，认为“Teradata只支持第三范式而不支持星形模式”。这就完全误解了逻辑数据模型与物理平台的关系。事实上，无论是星形模式还是第三范式，都是逻辑上的概念，与具体的物理平台并没有什么关系。
　　Teradata、UDB、Oracle、SQL Server等都是关系数据库产品，都能同时支持星形模式和第三范式。只是在物理实施时，由于各种数据库产品的特性、内部结构等方面的差异，当数据量很大时，一些数据库产品无法处理以规范方式（如第三范式）存储的海量数据，不得不采取星形模式或者其它不规范化方式（如小结表、预连接等）对数据进行预处理，以回答那些可以预知的业务问题。
　　很多数据库产品都是基于联机交易处理系统（OLTP）设计的，其内部结构更适合于进行交易处理，并不适合于数据仓库中大量的复杂数据分析与综合处理。这些数据库用于数据仓库引擎时，往往中央存储采用第三范式建模，然后按照各种预知的需求建立大量的数据集市，前台业务用户只是访问这些数据集市，从而屏蔽了业务用户对后台详细数据的访问。
　　前端展现工具并不万能
　　现在很多企业都在进行数据集中、统一平台与标准等工作，因此在选择数据仓库前端产品时，它们往往要问:能否选择一个统一的前端展现工具？哪些前端产品与哪些数据库产品的匹配性最好？
　　不同的前端产品具有不同的市场定位和功能特点，虽然各种工具产品的功能与特点确实有许多交叉和重合，但基本上没有一种前端产品可以涵盖一个企业所有业务部门的需求。国外许多发展多年的数据仓库系统大多是根据不同类型用户的使用特点与需求而选用不同的前端工具。如果我们去考察一个数据仓库用户，往往会发现他们同时使用了SAS、BO、Brio、Cognos 等多种工具。
　　磁盘容量不是越大越好
　　磁盘容量越来越大，从早期的9GB、18GB，到现在的36GB、73GB、146GB，而且更高容量的磁盘还会不断出现。那么在配置数据仓库的存储系统时，是否磁盘容量越大越好？如果不是，应该如何进行选择？
　　数据仓库负载主要是SQL查询处理，需要扫描大量的数据，因此数据仓库系统对磁盘存储系统的I/O要求很高。而影响一个磁盘存储系统总体I/O带宽的主要因素是磁盘个数和磁盘转速。
　　一般来说，随着磁盘数的增加，存储系统的I/O带宽也会相应增加。但磁盘数增加到一定程度，存储系统的I/O将趋于饱和。因此，存储系统的磁盘数并非越多越好。用户在进行选择时，要研究磁盘存储系统的I/O带宽与其磁盘数之间的关系图表，并注意存储系统的I/O能力在数据仓库负载不同时，会发生相应变化，一般情况下，可以认为数据仓库的典型负载为80%读、20%写。
　　另一个影响存储系统I/O能力的主要因素是磁盘转速，转速越高，I/O越好。目前市面上的磁盘转速主要有7200转、10000转和15000转。我们在选择磁盘时，应该是转速越高越好，更准确地说，是平均到每单位存储容量上的带宽越高越好。
　　正确认识数据仓库的开放性
　　现在很多人常常走入一个误区:把开放性理解成硬件平台能否支持多种操作系统或者数据库软件，数据库能否运行在多个操作系统或者硬件平台上。
　　一个系统是否开放，我们主要考察它的可移植性、互操作性以及可扩展能力。从这几点要求来看，考察数据仓库系统的开放性与OLTP系统的开放性并没有什么区别。
　　OLTP系统中的数据是自身在运行过程当中产生的，而数据仓库系统本身不产生数据，其数据需要从业务系统中获得。因此在考察数据仓库系统开放性时需要着重考察其对源数据的获取能力，Gartner Group把这种能力称之为适应性(Suitability)。
　　另外，由于数据仓库系统与业务处理系统的应用完全不同，其数据模型也完全不一样，两个系统之间的ETL（数据抽取、转换与加载）是非常复杂的。因此我们在考察数据仓库系统的开放性时，需要着重考察其从业务系统获取数据的能力。
　　数据仓库难有统一的性能指标
　　数据仓库系统中不同用户的信息访问特点不一样，一般用户的大部分需求可以从多维立方体、预定义报表中得到，这时，系统性能主要取决于网络传输速度、OLAP服务器的并发处理性能等因素。一般来说，这时的响应速度都在秒级。
　　对于数据仓库中的动态查询、数据挖掘等复杂分析，其性能主要取决于数据仓库引擎的并发处理能力和复杂SQL处理能力。但由于需求的不可预知性，很难定义明确的性能指标。
　　因此，我们在定义数据仓库系统性能指标时，应该根据不同用户的使用特点分别规划，然后再对资源进行合理的安排和调度，以满足大部分用户的性能要求。

（责编：韩雨彤）

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。