CN102968374A

CN102968374A - 一种数据仓库测试方法

Info

Publication number: CN102968374A
Application number: CN2012104990177A
Authority: CN
Inventors: 付峰; 敖锦蓉; 洪松; 赵越; 舒琴
Original assignee: China Mobile Shenzhen Co Ltd
Current assignee: Medium shift information technology Co., Ltd.
Priority date: 2012-11-29
Filing date: 2012-11-29
Publication date: 2013-03-13
Anticipated expiration: 2032-11-29
Also published as: CN102968374B

Abstract

本发明涉及一种数据仓库的测试方法，包括以下的步骤：S1、确定待测试的数据仓库环境；S2、建立基于业务数据的数据模型；S3、建立测试用例，对数据仓库进行测试；S4、记录测试结果。实施本发明的一种数据仓库测试方法，能够适应当前新架构的数据仓库的特点，准确、快速的反应待测试数据仓库的各项特性。

Description

一种数据仓库测试方法

技术领域

本发明涉及数据仓库技术，更具体地说，涉及一种数据仓库测试方法。

背景技术

数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，其主要功能是进行分析型处理。数据仓库技术是企业经营分析系统的基础。经营分析系统可通过分析运营数据，为管理决策提供支持。随着网络技术和计算机应用的发展，互联网、电信和银行等行业的企业在运营过程中产生的数据量快速膨胀，对数据仓库的性能、可扩展性等有着巨大影响。传统的集中式数据仓库架构已经无法满足大型企业的经营分析系统在数据集成性、及时性和查询响应时间等各方面的要求。目前集团型企业和大型互联网企业均采用分布式的数据仓库架构设计，有效地提高了系统性能。在强调数据准确性和可用性的背景下，对经营分析系统的分布式数据仓库建立起一套完善的测试方法，可以获得系统架构和数据仓库在性能方面的分析结果，以便于验证各类数据仓库解决方案或产品的支持能力。

现有的数据仓库的测试方法多是针对传统的集中型数据仓库提出，例如业界广泛使用的TPC-H标准。TPC-H主要目的是评价特定查询的决策支持能力，强调服务器在数据挖掘、分析处理方面的能力。然而TPC-H的问题模型并不适合现在的分布式数据仓库：TPC-H测试模型对数据量的要求最大为TB级，并发量相对较小；TPC-H测试模型为数据库服务器连续7×24小时工作，可能只有1次/月的维护；多用户并发执行复杂的动态查询，同时有并发执行表修改操作。这与新型的分布式数据仓库的问题模型有很大差异。

针对现有的数据仓库的测试方法不再适用于新型分布式数据仓库的问题模型，有必要建立新的数据仓库的测试方法，以适应新型数据仓库架构的特点。

发明内容

本发明的目的在于，针对现有的测试方法无法准确、快速的反应新型数据仓库性能的缺陷，提供一种数据仓库测试方法以解决上述问题。

本发明解决上述问题的方案是：提供一种数据仓库测试方法，包括以下步骤：

S1、确定待测试的数据仓库环境；

S2、建立基于业务数据的数据模型；

S3、建立测试用例，对数据仓库进行测试；

S4、记录测试结果。

本发明的数据仓库测试方法，其中步骤S2包括：

描述测试所采用的数据表及其结构、数据表的使用及在测试过程中对数据表的操作；对数据量的要求可达到PB级（100万GB）。

本发明的数据仓库测试方法，其中步骤S3中，测试用例包括：

S31、功能测试；

S32、性能测试；

S33、稳定性测试；

S34、可扩展测试；

S35、可用性测试；

S36、个性化测试。

本发明的数据仓库测试方法，其中步骤S31包括：

S311、测试数据仓库对SQL标准（Structured Query Language，结构化谘询语言）的支持；

S312、测试数据仓库对OLAP函数（Online Analytical Processing联机分析处理）的支持；

S313、测试数据仓库对多租户架构下资源负载管理功能；

S314、测试数据仓库对日志、监控和告警系统管理的支持。

本发明的数据仓库测试方法，其中步骤S32包括：

S321、数据加载测试；

S322、基本操作测试；

S323、即席查询测试；

S324、数据的Rollback（回滚）操作测试；

S325、并发多任务测试；

S326、数据库数据导出测试；

S327、端到端测试；

S328、压力测试。

本发明的数据仓库的性能测试方法，其中步骤S321包括：

单表数据加载的性能测试和多表数据加载的性能测试。

本发明的数据仓库的性能测试方法，其中步骤S322包括：

·全表扫描测试，用于测试不同记录数级别的数据表全表扫描查询性能；

·多表关联测试，用于测试两个大表通过分区键关联时候的性能表现；

·Merge（合并）操作测试，用于测试Merge操作的性能；

·Insert（插入）操作测试，用于测试单表数据的INSERT操作性能；

·Update（更新）操作测试，用于测试单表update操作性能；

·Delete（删除）操作测试，用于测试单表delete操作性能；

·嵌套操作测试，用于测试SQL嵌套操作的性能；

·Distinct（差异）去重测试，用于测试distinct操作的性能及主机、数据库资源消耗情况。

本发明的数据仓库的性能测试方法，其中步骤S323验证数据仓库对即席查询的性能支持，通过执行预先选定的即席查询的10条SQL语句，记录每个语句的运行时间和资源消耗情况。

本发明的数据仓库的性能测试方法，其中步骤S34包括有索引情况下数据的Rollback性能测试和无索引情况下数据的Rollback性能测试。

本发明的数据仓库的性能测试方法，其中步骤S325包括：

·多任务并发查询，用于验证单个用户下使用相同SQL语句做并发查询的效率；

·多任务并发Insert，用于验证使用同一用户做多次并发insert操作的效率；

·多任务混合负载，用于验证在不同类型负载的情况下，数据库的运行效率及其对服务器资源的消耗；

·边加载边查询，用于测试加载操作和查询操作并行情况下的性能。

本发明的数据仓库的性能测试方法，其中步骤S326用于测试数据库自有的数据导出工具的性能。

本发明的数据仓库的性能测试方法，其中步骤S327用于模拟业务的若干个操作流程，验证数据仓库产品的综合性能表现。

本发明的数据仓库的性能测试方法，其中步骤S328测试数据库在压力之下的处理能力，验证数据仓库产品在处理请求过载下的表现。

本发明的数据仓库测试方法，其中步骤S33考察数据仓库产品在大业务量和长时间高负载的情况下（超出额定工作时间或超出额定负载）持续稳定运行的能力。

本发明的数据仓库测试方法，其中步骤S34包括扩展性测试和考察计算节点是否可以收缩。

本发明的数据仓库测试方法，其中步骤S35包括：模拟常见故障包括网络连接异常、磁盘存储故障、节点级故障和极限故障情况下的高可用性测试。

本发明的数据仓库测试方法，其中步骤S36包括：归档压缩测试、非结构化数据测试、行列安全控制测试、人为误操作后快速回复、网站购买行为分析测试、访问轨迹分析测试、分词统计测试、基于Wiki情感分析测试、运用Kmeans（k-means算法）实现客户分群测试。

实施本发明的数据仓库测试方法，能够适应当前新架构的数据仓库，在进行具体测试前，先进行具体的数据仓库环境设置，针对具体的数据仓库结构，实施合适的测试用例，使得测试数据仓库的方法能够准确、快速的反应待测试数据仓库的各项特性。

附图说明

以下结合附图对本发明进行详细说明，其中：

图1为本发明数据仓库测试方法的流程图；

图2为本发明数据仓库测试架构的第一实施例；

图3为本发明数据仓库测试架构的第二实施例；

图4为本发明数据仓库测试架构的第三实施例。

具体实施方式

以下结合附图和具体实施方式对本发明进行详细说明。

如图1所示为本发明数据仓库测试方法的流程图。对不同架构的数据仓库进行测试，首先执行步骤S1：确定待测试的数据仓库环境，即确定具体的数据仓库的组成架构以及对应的测试架构（例如在图2至图4中给出三种具体的数据仓库架构）；在确定了数据仓库的具体架构后，对设备域和功能配置进行说明，再对参测硬件配置和参测软件产品需求的各项要求进行设定。

此后，执行步骤S2：建立基于业务数据的数据模型；具体的，建立测试所采用的数据表及其结构、数据表的使用及在测试过程中对数据表的各项相关操作。这些数据表的结构以及后续的相关操作是对应于步骤S1的具体数据仓库架构建立的，以确保获得的测试结果的准确和快速。

执行完步骤S2后，首先执行一次对硬件和数据库在测试过程中的初始化，该初始化的步骤在整个测试过程中只执行一次，即在测试开始后不得调整硬件方式。然后再执行步骤S3：建立测试用例，对数据仓库进行测试。测试用例确定了本次测试中具体的测试项目，每个测试项目都具体反映了数据仓库一个方面的性能。具体的S3的步骤包括以下的测试步骤：

S31、功能测试，该步骤具体包括：

S311、测试数据仓库对SQL标准的支持；

S312、测试数据仓库对OLAP函数的支持；

S313、测试数据仓库对多租户架构下资源负载管理功能；

S314、测试数据仓库对日志、监控和告警系统管理的支持。

此后进行步骤S32，对整个数据仓库的性能进行测试，具体包括以下的步骤：

S321、数据加载测试；

S322、基本操作测试；

S323、即席查询测试；

S324、数据的Rollback操作测试；

S325、并发多任务测试；

S326、数据库数据导出测试；

S327、端到端测试；

S328、压力测试。

其中步骤S322验证数据仓库产品在基本操作上的性能表现，包括步骤：全表扫描测试、多表关联测试、Merge操作测试、Insert操作测试、Update操作测试、Delete操作测试、嵌套操作测试、Distinct去重测试等。

步骤S322模拟业务的若干个操作流程，验证数据仓库产品的综合性能表现。

步骤S323验证数据仓库产品在处理请求过载下的表现。

此后进行步骤S34的测试：扩展性测试和考察计算节点是否可以收缩。

此后进行步骤S35的测试：模拟常见故障包括网络连接异常、磁盘存储故障、节点级故障和极限故障情况下的高可用性测试。

此后进行步骤S36的测试：：归档压缩测试、非结构化数据测试、行列安全控制测试、人为误操作后快速回复、网站购买行为分析测试、访问轨迹分析测试、分词统计测试、基于Wiki情感分析测试、运用Kmeans（k-means算法）实现客户分群测试。

进行完上述所有步骤的测试后，将测试结果输出以便进行分析。

以上的测试方法尤其适合对分布式结构的数据仓库进行测试分析。例如图2-图4给出了三种不同的组网方式。

如图2所示为本发明数据仓库测试架构的第一实施例，主测试节点200由多台PC服务器201组成，具体的选用中端内置大容量硬盘通用X86架构服务器。扩展性测试节点300由多台PC服务器301组成，选用的PC服务器301与主测试节点200所使用的PC服务器构成相同。辅助服务器100包括磁盘阵列101、SAN变换器102、接口文件加载服务器104、测试管理展现终端103组成。其中接口文件加载服务器104为通用X86架构服务器和高端存储组成，测试管理展现终端103由普通配置PC终端或者PC服务器构成，以万兆以太交换机400为核心构成测试环境基础网络环境，链接所有参与测试的服务器设备（接口文件加载服务器104、测试管理展现终端103、PC服务器201、PC服务器301），负责测试环境的设备内联和外联。

图3为数据仓库测试架构的第二实施例，该数据仓库测试架构包括主测试节点200、扩展性测试节点300、辅助服务器100；其中主测试节点200、扩展性测试节点300的结构与图2中的第一实施例对应组件相同，辅助服务器100包括ETL磁盘阵列105、SAN交换机106、接口文件加载服务器104、测试管理展现终端103，其中SAN交换机106与ETL磁盘阵列105、接口文件加载服务器104、测试管理展现终端103通信连接。以万兆以太交换机400为核心构成测试环境基础网络环境，链接所有参与测试的服务器设备（接口文件加载服务器104、测试管理展现终端103、PC服务器201、PC服务器301），负责测试环境的设备内联和外联。主测试节点200和扩展性测试节点300还通过多个SAN交换机106与仓库储存阵列500相连。

图4为数据仓库测试架构的第三实施例，该数据仓库测试架构包括主测试节点200、扩展性测试节点300、辅助服务器100；主测试节点200包括多台一体机节点202，扩展性测试节点300包括多台一体机节点302。辅助服务器100内包括磁盘阵列101、接口文件加载服务器104和测试管理展现终端103。磁盘阵列101与接口文件加载服务器104相连接，该数据仓库测试架构还通过万兆以太交换机400为核心构成测试环境基础网络环境，链接所有参与测试的服务器设备（接口文件加载服务器104、测试管理展现终端103、一体机节点202、一体机节点302）。

为了更好的说明本发明的测试方法的实现方式，现结合图2的架构详细说明测试用例的实现方式，需要理解的是，在结合其他的架构时，测试用例只要做对应变换即可。

首先依据图2搭建好连接架构，然后依据前述中的测试用例依次进行性能测试。

S311、测试数据仓库对SQL标准的支持：

1、连接测试数据库；

2、自动执行测试语句集，测试语句集：

1）执行建立INTEGER类型的表，预期成功：

CREATE TABLE TYPE001(COL INTEGER);

2）执行建立INT类型的表，预期成功：

CREATE TABLE TYPE002(COL INT);

S312、测试数据仓库对OLAP函数的支持：

1、使用数据库标准客户端连接测试数据库；

2、检查测试数据库表DTL_BILL及测试数据；

3、若不存在或者无数据；则执行

create_DTL_BILL脚本，数据生成，执行insert_DTL_BILL脚本；

4、执行SQL-1测试语句avg()over：

SELECT subs_id,avg(mer_amt-disc_amt)over(partition by subs_idorder by acct_prd_ytm)from DTL_BILL;

5、登记输出结果，通过记录数及随机抽取记录检验的方式判定执行结果正确性。

S313、测试数据仓库对多租户架构下资源负载管理功能：

1、分别使用USER1和USER2连接数据库；

2、通过产品内置工具命令，调整USER2用户任务为高优先级；

3、用USER1用户执行A组SQL,同时USER2用户执行B组SQL；

4、记录每条SQL的执行耗时并比较；

5、执行后清理执行数据库清理，删除USER1和USER2。

S314、测试数据仓库对日志、监控和告警系统管理的支持：

该测试细分为三个步骤：

日志：

1、在当前会话中启动针对排序操作的跟踪；

2、执行排序操作的SQL语句；

3、记录是否产生诊断日志，诊断日志的内容需要包含当前执行的SQL语句、排序统计信息（排序区大小、比较次数、使用内存等）。

监控：

1、对语音话单表做SQL语句部分要求的查询操作；

2、在“测试管理展现终端”中登录图形化监控系统，检查是否具备如下的监控信息并以截图的方式记录：

1)可以看到执行过的SQL的历史记录，具体信息包括SQL语句、当前状态、执行开始时间、执行耗时等

2)监控界面同时提供TOP10执行耗时较长的SQL语句列表

3、监控完毕，终止SQL执行。

SELECT

substr(CALL_BGN_TM,1,2)，

sum(CFEE),

avg(LFEE),

max(LFEE2),

min(INFO_FEE),

avg(DISC_CFEE),

avg(DISC_LFEE),

sum(DISC_LFEE2),

sum(DISC_INFO_FEE),

count(distinct(MSISDN))

FROM

GSM_VOIC_CDR

GROUP BY

substr(CALL_BGN_TM,1,2);

告警：

1、创建一个小容量的表空间，并向里面导入大量数据，超过表空间的容量；

2、通过查看图形化的界面或后台告警日志查看表空间告警信息；

3、记录是否具备告警信息功能，并详细记录告警信息的字段信息。

create table TB_SVC_SUBS_HIST_TMP6as select*fromTB_SVC_SUBS_HIST where1=0;

insert into

drop table TB_SVC_SUBS_HIST_TMP6

S321验证数据仓库产品在单一操作上的最佳表现：

●数据的导入和导出测试：

1.调用命令装载文件到数据库：具体的命令为：scenario/6.3.3.1/load.sh

2.记录每个数据文件装载的开始、结束时间、执行时长；

3.装载期间的主机资源使用情况（CPU占用率、内存、磁盘ＩＯ、网络）。

●Update测试

具体的命令为：

UPDATE GSM_VOIC_CDR

SET CALL_DUR=CALL_DUR+2,INFO_FEE=INFO_FEE*10

WHERE

IMEI_NBR=’ABCDEFGHIJKLMN’

and SVC_TYP in('000','001')

and CALL_DUR>10

●Rollback测试

具体的命令为：

delete from DTL_BILL_TMP1；

select count(*)from DTL_BILL_TMP1;

rollback；

SQL-2：部分数据delete后回滚：

delete from DTL_BILL_TMP1 where subs_id like‘%139%’；

Select count(*)from DTL_BILL_TMP1where subs_id like‘%139%’;

Rollback

●小查询：

1.SELECT count(*)

FROM TB_SVC_SUBS_HIST A

LEFT OUTER JOIN

DTL_BILL B on A.SUBS_ID=B.SUBS_ID

WHERE A.MSISDN=’xxxxxxxxxx’

轮询100万个号码。

2.记录执行时长和主机资源使用情况（CPU占用率、内存、磁盘ＩＯ、网络）

S322、端到端测试：

1.启动背景作业之后加载详单文件加载到指定的几个表中

2.执行两个sql

3.记录加载和SQL运行时长及主机资源使用情况（CPU占用率、内存、磁盘ＩＯ、网络）

S323、压力测试：

1.执行清理缓存操作；

2.每隔10秒启动10个shell脚本，直至600个脚本全部启动；

3.保持系统运行2小时，记录运行期间系统资源，包括CPU、内存、网络、磁盘ＩＯ）并记录各SQL的处理时长。

S33、稳定性测试：

●采用能力摸高的方式操作，测试数据库在压力之下的处理能力

1.执行清理缓存操作；

2.每隔10秒启动10个shell脚本，直至600个脚本全部启动；

3.保持系统运行2小时，记录运行期间系统资源，包括CPU、内存、网络、磁盘ＩＯ）并记录各SQL的处理时长

●验证数据仓库产品在大业务量的背景上持续稳定运行的能力：

保持系统在该负载情况下运行12小时。

S34、扩展性测试和考察计算节点是否可以收缩：

1.由8节点扩展到10；再由10到12。每一次扩展完成后，并行提交两个sql，分别考察它们的运行时间，运行期间系统资源，包括CPU、内存、网络、IO的消耗情况。

2.由12收缩到10，收缩完成后，并行提交两个sql，分别考察它们的运行时间，运行期间系统资源，包括CPU、内存、网络、IO的消耗情况。

S35、可用性测试：

●网络连接异常测试：

1.执行清理缓存操作；

2.创建所需的表结构；

3.加载并在任务终端上并行循环运行SQL语句；

4.任务开始后结束前随机拔掉网线

5.记录前台应用是否中断、应用SQL是否能够继续完成。

●磁盘存储故障测试：

1、拔掉某一raid（Redundant Arrays of Inexpensive Disks，磁盘阵列）组中的一块磁盘；

2、拔掉相同raid组中任意一组中的第二块磁盘，破坏该raid组。

●节点级故障测试

1、启动主机及数据库相关性能监控脚本；

2、在任务终端上并行提交运行SQL语句；

3、模拟单计算节点故障，随机选一个计算节点，同时拔出其全部网线连接；

4、记录前台应用是否中断；

5、如果应用不中断，记录两条SQL的完成时间；

6、如果中断，记录故障处理步骤、修复脚本，计算节点故障恢复时间，分别记下修复后重新运行两条SQL所花费时间。

●极限故障测试

1、启动主机及数据库相关性能监控脚本；

2、在任务终端上并行提交运行SQL语句；

3、厂商选择性将最多资源退服，记录资源退服情况；

4、记录前台应用是否中断；

5、如果应用不中断，记录两条SQL的完成时间；

S36、个性化测试：

●归档压缩测试：

压缩比是表占用的空间（包括索引）和原始文件的比例

●非结构化数据测试：

1.编写脚本，加载包含客户信息的TB级别的音频、视频、Word、PDF等类型文档的非结构化数据，测试数据入库时间，检查非结构化数据是否真实入库；

2．编写脚本，根据客户服务条件等检索客户服务时的音频、视频文档，下载该文档数据。记录查询性能及数据下载性能

●人为误操作后快速回复：

1.创建测试用数据表TABLE1和TABLE2；

2.对表TABLE1进行DELETE操作，操作完成后提交，通过命令恢复表TABLE1删除的数据。

3.对表TABLE2进行3次或以上UPDATE操作，操作完成后提交，通过命令查看更改的历史记录，并可以恢复任意以前版本的数据。

4.在表TABLE2恢复后，对此表进行DROP操作，操作完成后，通过命令恢复被删除的表和数据。

●分词统计测试：

1.编写和运行Tokenize SQL_MR脚本，记录脚本执行的时间，验证结果的正确性。

2.DDL语句描述

SELECT"TOKEN",COUNT(*)

FROM PUBLIC.TOKENIZE(ON TOKENIZE_DOCUMENTS)

GROUP BY"TOKEN"

ORDER BY"TOKEN"。

以上给出了结合一则具体数据仓库架构进行性能测试所使用的测试命令和具体步骤，在进行其他架构的测试时，只要进行适应性调整即可。

以上仅为本发明具体实施方式，不能以此来限定本发明的范围，本技术领域内的一般技术人员根据本创作所作的均等变化，以及本领域内技术人员熟知的改变，都应仍属本发明涵盖的范围。

Claims

1.一种数据仓库测试方法，其特征在于，包括以下步骤：

S1、确定待测试的数据仓库环境；

S2、建立基于业务数据的数据模型；

S3、建立测试用例，对数据仓库进行测试；

S4、记录测试结果。

2.根据权利要求1所述的数据仓库测试方法，其特征在于，所述步骤S2包括：

描述测试所采用的数据表及其结构、数据表的使用及在测试过程中对数据表的操作。

3.根据权利要求1所述的数据仓库测试方法，其特征在于，所述步骤S3中，测试用例包括：

S31、功能测试；

S32、性能测试；

S33、稳定性测试；

S34、可扩展测试；

S35、可用性测试；

S36、个性化测试。

4.据权利要求3所述的数据仓库测试方法，其特征在于，所述步骤S31包括：

S311、测试数据仓库对SQL标准的支持；

S312、测试数据仓库对OLAP函数的支持；

S313、测试数据仓库对多租户架构下资源负载管理功能；

S314、测试数据仓库对日志、监控和告警系统管理的支持。

5.根据权利要求3所述的数据仓库测试方法，其特征在于，所述步骤S32包括：

S321、数据加载测试；

S322、基本操作测试；

S323、即席查询测试；

S324、数据的Rollback操作测试；

S325、并发多任务测试；

S326、数据库数据导出测试；

S327、端到端测试；

S328、压力测试。

6.权利要求3所述的数据仓库测试方法，其特征在于，所述步骤S33考察数据库系统在超出额定工作时间或超出额定负载的情况下是否能稳定提供服务。

7.权利要求3所述的数据仓库测试方法，其特征在于，所述步骤S34包含扩展性测试和考察计算节点是否可以收缩。

8.权利要求3所述的数据仓库测试方法，其特征在于，所述步骤S35包括：模拟常见故障包括网络连接异常、磁盘存储故障、节点级故障和极限故障情况下的高可用性测试。

9.权利要求3所述的数据仓库测试方法，其特征在于，所述步骤S36包括：归档压缩测试、非结构化数据测试、行列安全控制测试、人为误操作后快速回复、网站购买行为分析测试、访问轨迹分析测试、分词统计测试、基于Wiki情感分析测试和客户分群测试。