原创《数据仓库测试特性与中国建设银行测试实践》
本文是测试方面有关在职研究生论文范文与中国建设银行和数据仓库和特性有关论文范文。
随着信息技术的不断深入普及,互联网服务、金融、电信、医学影像和基因测序等业务领域出现数据资产的爆发式增长.人类创造数据的速度前所未有,现今数据产生速度超过30000GB/s 并仍在不断加快.全球数据总量在2013 年约为4.4ZB,到2020 年预计增长十倍达到44ZB 的规模.为了对数据资产进行系统的分析处理,形成商业智能,数据仓库（Data Warehouse）应运而生.
数据仓库是一个面向主题的（Subject Oriented）、集成的（Integrated）、相对稳定的（Non-Volatile）和反映历史变化（Time Variant）的数据集合,用于支持管理决策(Decision Making Support).
随着国际金融形势的变化和国内互联网金融行业的发展,金融企业的竞争方式已悄然发生了变化.如何在复杂多变的市场条件下,在金融企业盈利增长、管理效率提升的同时,加强信息监管,实施风险控制以赢得竞争优势,已经成为众多金融企业追逐的目标.数据资产日益成为银行业重要的资产之一,对数据资产的开发利用程度,反映了一个银行的整体管理水平.数据资产开发对银行的价值例举如图1 所示.
一、中国建设银行数据仓库现状
中国建设银行（以下简称“建行”）数据仓库始建于2005 年,历经十余年持续的建设、扩充和完善,特别是经过新一代功能系统重构后,目前已经形成基于一套蓝图、一个平台和一个口径,实现对三类数据的整合加工处理系统.其中,一套蓝图是指建立一套银行内部统一的基础数据定义,涵盖建行基础核心数据的统一企业数据结构,用来指导和规范多个应用信息系统中对同类业务对象的定义,从而保障全行数据的一致性和数据质量；一个平台是指建立一个统一的、共享的基础数据平台,为不同业务需求提供规范的数据,屏蔽上游数据模型变化对下游的影响；一个口径是指全行各类分析管理、监管报送和数据挖掘的数据,统一从仓库提取,避免多头数据,保证数据来源的准确性和唯一性；三类数据是指顺应数据分析发展业态,涵盖结构化、半结构化和非结构化数据的入库、加工分析处理,实现了数据类型的全覆盖.数据分析发展业态如图2 所示.
二、数据仓库测试常见问题
保障数据仓库系统生产运行平稳有序,不仅是银行自身业务及外部监管要求,也是测试岗位职责所在.数据仓库的测试工作与交易线存在显著差异,具体表现在以下方面.
1. 版本就绪晚,管控难度大
不同于交易线系统一般与一个或几个系统之间存在关联调用关系,数据仓库集中了全行业务数据进行接入加工处理,与投产的各上游系统之间均存在关联关系.
上游各系统立项时间、开发启动、里程碑、版本质量和需求变更的频度千差万别,通常必须等到上游关联各系统数据模型基本稳定后,数据仓库才有稳定版本,才具备整体测试条件,版本就绪通常迟于交易线的整体进度.
由于上游关联系统众多,且各系统数据模型在封版之前都可能存在变更,导致仓库版本变更频繁,容易形成“变更风暴”,给版本管控带来很大挑战.数据仓库的测试实施,呈现出前期缺版本缺数据,中期存在多个版本,后期测试缺时间缺人手的态势,测试步调呈现前松后紧.
2. 上线功能点多,直观性差
历次大的版本投产,一般会涉及少到千级多达万级的作业开发和变更,与交易线单系统交易数目通常以十、百计对比,呈现数量级别的差异；测试内容不仅包括应用级别的单作业手工测试、调度绿灯测试和自动调度测试,还可能包括平台级别的ETL 服务器、调度服务器、事件服务器、Teradata 和Greenplum 等能力测试.
数据仓库是公司业务数据的集中接收处理,供下游进行商业报表展示和数据挖掘,在数据链条中承担中介和桥梁的作用,数据仓库的构建通常基于三个模型组织：（1）概念模型,对业务的范围和使用,从高度上进行抽象概括,也就是划分主题域.
（2）逻辑模型,对概念模型中的主题进行细化,定义实体与实体之间的关系以及实体的属性.
（3）物理模型,依照逻辑模型,在数据库中进行建表、索引等.通常来说,仓库不直接面对用户,程序逻辑基于模型构建,缺少图形界面,抽象化程度高,直观性差.
3. 测试环境和数据要求高
交易线系统通常是Apache+weblogic+Oracle 的架构,生产及测试环境普遍基于虚拟机的形式组织部署,机器台数少,部署方式相对简单.然而,数据仓库系统机器组成成分多：Apache、weblogic、事件服务器、调度服务器、Greenplum、Hadoop 和Teradata 集群都有涉及,机器台数多,部署复杂.另一方面,由于数据仓库系统通常是计算密集型和I/O 密集型,测试环境需要与生产一致,且基于物理机的环境展开,对测试环境的要求高.上游各系统数据对于数据仓库来说,可能存在着系统内部、系统和系统之间的紧耦合关系.对于大型企业来说,一个目标表的加工涉及的源表数目众多,从源表到最终形成报表数据可能还会历经多层链路.如果采用人工造数等手段构造数据,很难模拟出数据之间内在关联关系,极可能导致加工中间表中不存在数据,导致后续测试无法正常进行.
4. 呈现测不准特性
不同于交易线系统普遍存在的某支或某几支交易存在高频调用的情况,数据仓库中的作业每日至多调用一次,甚至有一部分作业月跑、季跑甚至年跑.所以对数据仓库系统来说,并不存在典型作业的概念.
不同于交易线系统交易的响应时间通常以毫秒至多以秒计,具有同步实时性的特征.对于仓库来说上游系统数据到达仓库基本是分时、分批的.作业之间存在依赖关系,需要依赖于调度服务器、ETL、TD 及GP 的资源使用情况,作业的执行时间短的以分钟计,长的可以以天计数,具有异步非实时的特征.
5. 数据库分布式特性
不同于交易线数据库采用主备控制器+SAN 存储,配置Failover 模式,数据仓库的数据库产品由于处理的数据量巨大（PB 级）,已经远超过单控制器处理能力,所以均是采用分布式形式部署,将计算压力分散到各个节点上.典型的产品既有基于关系型的擅长处理结构化数据的Teradata 和Greenplum,也有基于非关系型的擅长处理半结构化及非结构化数据的Hive 及Hbase 等.Teradata 逻辑架构如图3 所示.
6. 边界风险
对于同一个目标指标项的加工,数据仓库可能存在若干的实现路径,各路径的加工时效性、资源消耗等均可能存在差别,在路径规划上需要根据各种限制条件进行取舍.
对于涉及到核心帐务等业务的重要性高、历史数据量大的上游系统,版本切换时可能会涉及到上游TB 级别全量数据迁移转换及下发,还可能涉及到广域网的数据传输、NAS 的资源瓶颈等.数据仓库后续的加工处理都基于全量数据做拉链表来进行,需要做估算甚至专项测试.
三、应对措施
在建行数据仓库的测试中,针对上述各风险问题,采取如下措施进行应对.
1. 迭代供数及平台统一管控
针对版本就绪晚的问题,在测试实践中,与数据架构、上下游系统一起建立联动机制,从开发进度里程碑、物理模型进展、下游报表系统各表项数据成分加工路径和重大风险点等几方面,采取循环迭代的方式,分批次提供数据模型（物理模型）和供数,并逐步扩大上游原系统的供数范围,尽可能在最小的约束条件下做最多的事情,尽最大可能将测试提前,应对版本就绪晚的客观约束.随着测试的开展,在后期需要注意人手的调配,避免因人手不足影响到测试进度.
数据仓库上下游千头万绪,自身作业数目众多,仅靠人工很难实现有效的管控.针对管控难度大的问题,在建行实践中,开发部署数据线自动化平台,划分阶段和岗位,明确流程和职责,实现对需求接入、数据订阅、审核、供数状态、供数计划偏差和变更控制的全局整体把控.流程如图4 所示.
2. 分类分级测试及加强模型学习
针对数据仓库上线功能点多的问题,在测试实践中采取将测试内容分类,在类别中又进行分级的策略开展测试.
根据建行数据仓库部署特性,可以将测试内容划分为平台级和应用级.其中平台级测试包含：数据缓存服务器、事件服务器、调度服务器和ETL 服务器；应用级测试包含：单作业测试、作业间依赖关系测试、多作业并发测试和端到端加工测试.随着仓库的不断建设,平台日趋稳定,针对此项的测试活动可以考虑不断缩小以至终止.
对于应用级别测试,也要划分若干优先级.针对重要的加工指标一定要进行充分测试,推荐采取“对帐”的方式进行验证,即：业务人员手工计算出的结果要与作业加工处理结果一致,才能保证功能逻辑正确,避免开发人员对业务理解偏差或程序逻辑构建缺陷引发的重大功能缺陷.对于非功能测试来说,测试场景不仅考虑一般营业日,还要考虑月末、季度末和年末等特殊营业日,以及上线追数等对系统资源消耗大的场景.总体来说,对于上线的功能点,需要分清轻重缓急,全面覆盖,重点保证,确保无重大功能差错.
逻辑数据模型为企业描绘出一幅整体的业务蓝图,一个可扩展的、动态的模型能够经得住时间的考验,当业务改变时,能够将对数据模型的影响减至最小甚至完全不受影响.
仓库的数据模型应该是中性的,能够满足各种不同的分析逻辑的要求,因此它不同于通常所看到的为了支持某个特定的、预先定义的处理过程而设计的模型.可以说,一套良好的建模是数据仓库涉及的精髓所在.
对于仓库的测试人员来说,必须对模型有深入的理解掌握,才能应对仓库测试直观性差的问题,从宏观上把握好测试,从业务角度理解数据,克服就数据论数据的误区.从微观上理解各业务功能差别,有助于划分好测试的优先级.
3. 基于物理机器和迁移数据开展测试
数据仓库的测试环境不仅要求部署的机器台数多、逻辑单元多（缓冲区、事件服务器集群、调度服务器集群和ETL 服务器集群等）,而且测试性能表现对存储空间（TB 级）、读写速度（500MB/s 以上并行读写）和节点间网络带宽（20Gb 甚至40Gb 专用网络）等要求高.在测试环境尤其是非功能环境搭建上,需要与生产环境采用一致的物理机器.在部署上,如若受制于机器台数限制,可以采取最小部署模式,如Greenplum集群采用2Master+2Segment 形式,Hadoop 集群采用2Namenode+3Datanode 形式部署.
测试数据尽可能地采用生产迁移转换数据,这类数
据来源于生产实际,数据质量高,原生地体现系统内及系统间的内在依赖关系.必须注意的是,此类数据需要数据仓库人员、上游各系统人员、数据中心管理人员和测试环境管理人员等通力协作,规划各方职责和数据流转流程,避免出现相互推诿.另外要加强对生产数据进行脱敏操作,配备专人进行审核,避免泄密事件发生.
4. 静动结合降低资源消耗,减少不确定性
建行的数据仓库构建,划分为若干主题区域,同一区域内作业运行特性千差万别,作业至多日跑一次,交易线选取典型交易的测试方法并不适用于仓库测试.数据仓库作业的执行,需要等待数据齐备、事件服务器通知、调度服务器调度、ETL 服务器和数据库服务器资源情况综合齐备方可执行,即使对于同一个日跑作业来说,每日执行的开始时间和运行时长都具有不确定性.
如何在既没有典型作业,作业运行情况又不确定的条件下进行数据仓库的非功能测试,我们在测试实践中总结如下措施：
（1）最小数据类型
数据类型的定义与相关数据的加载和使用紧密相关,数据类型的定义决定了数据所占用的空间大小.数据类型选取得当,可以降低I/O 开销,节省计算资源.（2）简化数据定义
为了尽可能地保持数据仓库类型的一致性和规范性,并在数据迁移时降低数据转换的复杂性,数据仓库中的数据类型定义不宜过于复杂.
（3）核对分布键
数据表尤其大表必须显示指定分布键,不允许使用默认分布键的方式建立数据表,保障大表数据不出现偏斜,确保集群资源得到充分利用.
（4）大小表拼接
禁止使用产生笛卡尔积的关联形式（如CROSSJOIN 或者关联的两张表在关联字段上存在大量重复）；多表做关联时,关联结果较小的优先做JOIN；在关联大表的时候, 禁止使用存在大量重复记录的两个表进行关联 ,以免因重复记录关联产生巨大的中间结果,造成磁盘占用比例的大幅增长.
（5）物化视图
对于基于多表基础上建立的视图,如果频繁地查询,会导致频繁的多表访问,对此建议将视图物理化,节省系统的CPU 及I/O 资源消耗.
（6）适当分区尽量把数据均匀分拆.若每个分区储存的数据量相当,那么查询性能的改善将与分区的数量相关.例如,把一张表分为10 个分区,命中单个分区条件的查询扫表性能将比未分区的情况下提高10 倍.
通过上述静态手段,可以尽可能地降低作业运行时的资源开销,从而节约系统资源.
（7）作业依赖及优先级适当调整
作业都被归属到若干的调度组里,每个作业又被定义为A、B、C 三类优先级,优先级高的作业,在争夺资源时处于有利位置,更容易被调度执行.在测试及生产实践中,可以根据监管报送、网点开门等实际业务需要,将作业优先级做适当调整.在版本上线的一段时间（可设置1 个月作为观察窗口）动态观察各作业运行情况,进行适时调整.
（8）适当降低范式约束
不同于交易线系统普遍采用第三范式或是BCNF 范式进行开发,降低数据冗余.数据仓库系统的表设计可以考虑适当降低范式要求,恰当的数据冗余,可以降低作业的执行复杂度,甚至可以减少作业加工的层级,从而加快数据的加工处理.
采取上述措施,可以有效地在具有测不准特性的数据仓库系统中,降低系统的不确定性,保证时效性.
5. 重点关注分布键等特性
不同于交易线系统的Oracle 数据库等重点关注索引, 对于分布式关系型数据库（Teradata 和Greenplum）来说,重点关注分布键是衡量数据在分布式系统中是否均衡分布的重要指标.理想情况下,如果数据分布式系统中均匀分布,在计算处理中,各节点的系统资源都可以得到利用.所以,在非功能测试中,需要重点关注大表（通常是数据量以亿计数的表）的数据分布是否均衡.两类数据库产品均有经验语句审核分布键建立的合理性,如图5 所示.
对于分布式非关系型数据库（HBase）,重点关注Rowkey 建立是否合理.如果合理,在处理查询请求时,各节点都能得到利用.在Hbase 产品中,可以通过HMaster 的控制界面,做一段时间内各节点查询请求的计数统计来衡量Rowkey 选取的合理性.Rowkey 建立不合理的实例如图6 所示.
对于分布式非关系型数据库（Hive）,重点关注oderby 与sortby 的区别.如果使用orderby 之类语句,所有涉及到的数据都会调用同一reduce 作业进行处理,导致性能瓶颈.对于大结果集合的排序,可以考虑先进行sortby 排序,保证多个reduce 并行进行,每个reduce的数据内部是有序的,再进行一次归并排序,从而输出全局有序的数据.
对于分布式非关系型数据库来说,需要注意在大量小文件进入时,对其进行压缩（archive）操作,可以降低对namenode 节点的内存资源消耗,提高系统I/O 的利用率； 在mapreduce 计算中, 引入combiner 函数,降低节点间的网络开销；在数据跨集群拷贝上,利用hadoop 自带的distcp 提升拷贝的并行性；在结果表的组织上,可以根据业务查询宽窄表需要,灵活选取行存储模式还是列存储模式,降低磁盘I/O 资源消耗.
6. 边界风险应对
（1）时效性风险
由于仓库下游各管理分析类应用要求不同,如：开门报表、T+1 报表和外部监管等,对仓库加工处理的时效性要求也有不同要求.对待此类边界问题,可以从两方面规划.
①约束上游各系统卸数时间：采用计划倒排机制,根据下游各系统要求仓库的最晚供数时间,减去仓库自身加工处理时间,计算上游各系统数据最晚到达时间,并留有余量,保证数据按时按需加工处理完毕.
②路径规划：对于同一个目标指标项的加工,仓库内部可以规划出不同的加工路径,路径长短直接决定仓库的加工处理时效.从仓库规划设计时,就要根据下游不同供数时效性要求,规划出高、中、低三类数据处理路径.根据下游的时效性要求不同,选择在不同的路径上进行设计开发.
（2）全量数据下发风险
在投产切换上,如果上游核心数据表出现重大调整,经常采用的策略是上游全量历史数据迁移转换成新的数据表格式并下发到仓库入库,仓库在新的全量数据基础上,按照日期进行拉链表操作.核心表的数据下发,可能到达TB 级的量级,需要考虑到网络带宽、NAS 的读写速度和Xcom 参数调整（若涉及到主机）.必要时需进行专项的迁移转换及数据传输下发验证,保证仓库在投产时点能正常开始运行.
除上述这些应对措施之外,数据仓库的测试人员,也需要有比较充分的知识储备,服务好测试工作.
Teradata、Greenplum 及Hadoop 逻辑组成各异, 例如对于TD 来说,需要掌握PE、AMP 和Spool 等概念；对于GP 来说需要掌握Master、Segment、PLSQL 和资源队列等概念；对于Hadoop 来说需要掌握HDFS、Namenode 和Datanode 等概念.在数据库操作语言上,不仅需要掌握操作关系型数据库的SQL,还要能操作Hive 的类SQL 及操作HBase 的shell 等.从应用开发语言上,不仅需要掌握Ja,也要掌握现在流行的Scala、Python 和Perl 等语言.
目前数据仓库集成了建行200 多个新一代组件、管理分析系统和原有业务应用的万余张报表,并接入海关、工商和法院等外部系统数据,存量数据达到PB 级,每日增量数据达到TB 级,日运行作业数目达到十万级.
生产平稳有序,未发生重大生产事件.
图6 Rowkey 建立不合理示意
栏目编辑：孔蕊 kongrui@fcc.com.cn
测试论文参考资料：
该文评论：本文是一篇适合中国建设银行和数据仓库和特性论文写作的大学硕士及关于测试本科毕业论文，相关测试开题报告范文和学术职称论文参考文献。
