数据仓库的设计
数据仓库的设计与传统的OLTP系统设计有较大区别, 设计者不但要设计一个数据库和一个用户接口, 还必须设计数据装载策略、数据存取工具和不间断的维护方案。
在数据库设计时也要从传统的数据库规范化转到强调维的设计, 以便有更好的数据查询响应性能。
数据仓库设计的主要步骤如下:
1. 系统主题的确定
这要求系统设计人员多与业务人员沟通, 详细了解业务需求、报表需求,再归纳成数据仓库的主题。
例如, 经销商主题, 包含经销商各个历史时期的级别、 销售额、信贷、活动区域等。 产品主题,包含每个产品在各个历史时期、各个区域的销售额、促销力度、 销售件数、产品类别等。
2. 数据库的逻辑设计
在确定主题后, 需要对主题包含的信息进行详细定义,
并对事实表和维表的关系详细定义。比如, 经销商主题中的销售额,
定义为几个字段: NetSales (净销售额)，表示扣除了一切优惠折扣，数据类型为
Number(12,3); CusSales, 表示产品目录价的销售额, 数据类型为 Number(12,3);
TitleCode, 表示级别, 如101表示全国一级代理, 202表示省二级代理,
数据类型为 VarChar2(3)等。
3. 数据库的物理设计
物理设计主要考虑数据的存储方式, 使得系统有较好的性能。
对于记录庞大的事实表, 可以考虑分区存放。
而记录很少的维表则可以集中存放于某一表空间,
甚至可以让其数据在首次读取时驻留在系统内存中, 以加快数据存取速度。
索引的建立也在物理设计中完成, 索引是一把双刃剑，能提高读取速度,
也会使数据更新速度降低, 并占用大量磁盘空间。
后面的案例分析中将谈到这点。
独立磁盘阵列(RAID)方案的设计与数据更新网络的设计也需在此阶段完成。
合适的RAID方案对最终系统的性能有很大的影响。
4. 源数据获取、清洗、整理及装载设计
数据仓库的数据总是来自前台作业系统、业务部门的计划数据、各类广告促销活动及其影响数据,
以及购买回来的商业数据库。 这些数据并非照搬过来就行,
而是要按照前面提到的步骤, 以统一定义的格式从各个系统抽取出来, 经过清洗,
再经过数据装载和整理程序进入数据仓库。
5. 数据表达及访问设计
数据按统一格式、不同的主题存放到数据仓库后，下一步要着手数据表达及访问。
这主要考虑用户对信息的具体需求, 对应采用不同的方式。 比如,
使用Oracle数据库存放数据, 可以用PL/SQL编制报表, 也可以用Developer
2000或Visual Basic编制报表, 当然也可以采用一些业界优秀的OLAP产品,
例如Cognos公司的Transformer、PowerPlay Enterprise、
Oracle公司的Express等。
6. 不间断的维护方案的设计
数据仓库的运作与传统的作业系统有很大区别, 它需要不间断地维护,
否则它的性能将越来越差。 例如, 数据访问采用基于代价的优化(CBO),
事实表记录实施时有300万笔记录,
一个月后记录数为3000万，当时的CBO根本无法得到现在的最优化存取路径。
必须设计一个不间断的维护方案, 让系统保持优良的性能。
7. 编码、测试及实施
下面的工作就是编码、测试及实施了。
最终的数据仓库系统结构大致如图1所示，依据不同的情况,
系统结构图也会有些差别。
优化及案例分析
下面以一个具体的数据仓库系统为例,
对优化的一些细节进行分析。该数据仓库的系统配置如下：
数据库服务器: Windows 2000 Server + Oracle8i + IIS + PowerPlay
Enterprise Server
应用服务器: Windows 2000 Server + Transformer
客户端: IE5.0以上版本。
1. RAID
存储子系统的性能是数据仓库系统调整最重要的方面之一。
先考虑对性能要求的几个主要指标，一个是随机读(Random
Read)，性能好时对于Oracle的有索引查询或哈希(Hash)查询及回滚段读取有利。
第二个是随机写(Random
Write)，性能好时对Oracle的DBWN写进程、负载较重的OLTP系统有利,对数据仓库影响较小。第三个是顺序读(Sequential
Read)，性能好时对于备份、 全表扫描、索引创建、并行查询、临时段读取,
及由重做日志文件恢复数据库有利。另一个是顺序写(Sequential
Write)，性能较好时对Oracle的LGWR写进程、写临时段、SqlLoader参数为Direct的写数据、表空间的建立有利。
本例中数据仓库是24小时在线服务的,
系统的容错能力要求也很高。最后考虑的方案为RAID 1+0, 即每两个硬盘做镜像,
然后所有硬盘条带化配置, 既保证最佳的容错和读写性能, 又使I/O负载平衡。
在实施时, RAID卡参数的设置也要仔细考虑。 比如, 预先读、 延迟写、
RAID卡内存配置等对I/O都具有很大影响。
2. 索引的建立
索引是一把双刃剑, 能提高读取速度, 也会使数据更新速度降低,
并占用大量磁盘空间。 索引的建立与查询和数据更新有直接关系。
对庞大记录的事实表查询符合条件的记录时, 依据相关条件建立索引,
系统性能一般会有巨大改进, 但是, 如果索引对数据的区分度太差,
没有此索引反而更好。 增加索引, 将使数据插入与删除性能降低,
数据更新速度则可能提高。 所有这些需要综合考虑, 以建立合适的索引。
3. CBO的实际运作
基于代价的优化器(CBO)是一组例程, 它有助于选取满足传递给Oracle SQL
引擎做处理的查询所需数据的最佳存取路径。
存取路径是Oracle根据对象上的索引和相关的统计数据所选取的汇集、组装查询结果的方法。
对于处理海量数据的数据仓库, CBO是惟一的查询优化方法。
有效地使用CBO方法, 要求定期分析应用程序里的表和索引。
分析这些对象的频率取决于这些对象的改变速率。 对于批处理数据加载程序,
应该在每次事务后, 重新分析它们。 如果系统不允许, 至少也要安排一个进程,
定期在系统负载较轻时分析数据库对象。
要分析一个模式的所有对象，可以使用DBMS_UTILITY软件包的ANALYZE_SCHEMA过程。
它有两个常用参数: 模式的名字和选项(Compute 或 Estimate)。 如:
execute DBMS_UTILITY.ANALYZE_SCHEMA(‘CIA_ADMIN’, ‘COMPUTE’);
如果系统在用计算(Compute)选项时用时太多, 也可改成粗估(Estimate)选项,
并可以选择对多大的样本空间进行估计分析。 在本案例中, 曾计划每月运行一次,
后来发现, 由于每天加载的数据特别大, 10天后的性能就开始下降,
于是改为每天晚上负载最轻时, 由进程安排自动进行分析,
这样每天的性能都保持在最佳水平。
4. 直接装载、分区选择、网络设置等
除了上面几点外, 直接装载、分区选择、网络设置等也对系统性能有影响。
作为数据仓库, 必然要不断加载越来越多的数据。
Oracle的数据加载工具SqlLoader有两种方式: 直接加载和常规加载。
常规加载读取数据并将其传给Oracle SQL引擎,
由SQL引擎使用SQL的Insert语句将数据放入数据库中,由于每行都采用一个Insert语句,
需要更多资源。 直接加载时, SqlLoader将根据数据被存储的数据库表的结构,
在内存中把数据组装和格式化成同样的形式,
这就比常规加载快很多。另外,本案例中还将所有事实表都配置为Nologging模式,
这样将抑制重演日志的产生, 从而得到更快的速度。
由于采用RAID 1+0模式, 数据库的分区存储对存取性能影响不大。
但分区存储对数据维护有一定好处。 例如,
将事实表数据按不同季度存放在不同的分区(Partition),
可以单独对数据表的某个分区的数据重新整理, 而不影响这个表的其他部分,
从而获得较好的维护成本。数据加载可以在Database Server上运作,
如果通过网络加载,
需要考虑客户机与数据库服务器之间的通信是否具备足够带宽,
本案例中使用了100M专用网络端口。 另外,
Oracle的网络配置对系统性能也有一定影响。 例如,
将Oracle侦听器中没有用的网络协议删除, 如Named Pipes及SPX等,
将TRACE_LEVEL_LISTENER的参数改成OFF, 并将sqlnet.ora
中的参数设置SQLNET.AUTHENTICATION_SERVICES= (NTS) 注释掉,
将加快网络访问速度。
用户对数据的存取
数据仓库是帮助我们进行商务分析的一个强有力的工具。
数据仓库的成功与否完全依赖于对数据的访问是否简捷快速。
本例将对数据的访问分为如下三个方面: 标准报表, 随机动态的查询和多维分析。
对于标准报表, 由于格式固定, 采用由数据中心用Visual
Basic或PL/SQL程序批量生产, 分发给用户或Notes
站点上供用户浏览。对于随机动态的查询, 采用Oracle的SQL*Plus,
熟练的用户可以方便地获取数据仓库的数据。多维分析其实就是一种联机分析处理(OLAP),
它必须支持多维性, 可钻取性, 可旋转性及多视图模式等功能。
本案例采用的是Cognos公司的PowerPlay Enterprise Server,
每天收齐全国各个分公司, 工厂及总部ERP系统各模块数据后,
由其中的部件Transformer自动完成多维数据立方体的创建,
然后由部件Upfront自动分发到数据仓库的Web站点。 这样,
用户就可以及时获取全国的最新数据。
下图是用户通过Intranet定制的一份图形报表,
显示了2001年12月与2002年1月在各个区间段的销售对比。
在设计时就考虑数据仓库系统的优化十分重要, 根据系统应用情况的变化,
不断地改进优化系统性能同样十分重要。
本文提到的细节分析与读者的实际情况也许有差别,
但希望这种思考问题的方法对读者有一定的启发作用。
小结
数据仓库的设计与优化是一个实践性很强的工作，除了要掌握数据仓库的理论知识外，更重要的是在实际工作中慢慢摸索、积累，只有这样才能充分发挥数据仓库的功
效，为各种应用提供更多的帮助和支持。
