银行卡统计分析系统试运行情况汇报
银行卡统计分析系统试运行情况汇报1试运行基本情况按照项目整体进度的安排，在各级领导的支持下，在项目组全体成员的共同努力下，项目组如期完成了银行卡统计分析系统各项功能的开发、测试工作，以及ASE到IQ的移植。为了确保系统正常上线，在总行卡部、科技部的组织下，项目组到山东分行进行试运行。项目组全体成员于6月11日抵达济南，从11日至22日进行了为期12天的紧张工作，完成了试运行的所有工作，试运行也达到了预期的目标。全体成员中业务人员共 3人，包括总行卡部2人，山东分行1人；技术人员共12人，包括总行开发中心3人，广州分中心4人，山东分行3人，外协2人。2试运行环境按照项目组下发的软硬件配置清单，山东分行提前搭建了试运行环境并且准备了2007年3、4、5月份的数据，详细情况如下:1）硬件环境Ø 数据库服务器：RP8420小型机、32个CPU、96G内存，500G可用磁盘空间；Ø 应用服务器： PC Server，内置16个CPU、3G内存、70G磁盘空间Ø 多维服务器： PC Server，内置16个CPU、3G内存、70G磁盘空间2）软件环境Ø 数据库服务器： 操作系统HP-UX B.11.11；数据库Sybase ASE 12.5.3，初始化建立名为yhktj的数据库，大小600M，日志200M；数据库Sybase IQ 12.6数据库，数据段空间200G，server名与数据库名均为yhktj。Ø 应用服务器：操作系统 SuSe Linux 9.0；应用服务器为IBM WebSphere Application Server for Network Deployment 5.1.1.10 Ø 多维服务器：操作系统Windows Server 2003 Standard Edition；多维服务器为Cognos 8.2.43；Web服务器为Windows下的Internet信息服务(IIS)；Cognos数据库Sybase ASE 12.52；IQ客户端Sybase IQ Network Client Windows 12.63）数据环境：试运行的数据与将来实际生产的数据完全一致，分行准备了2007年3、4、5月份的生产数据，其中32张ABIS源数据, 3张AIPS源数据，总共35张表，数据文件每日增量0.9G，月底全量29G。3试运行过程此次试运行工作是对整个系统的全面检验，在试运行过程中项目组与山东分行的科技和业务人员一起，从环境搭建、数据准备、应用部署、系统运行、系统测试几个方面进行，达到了非常好的效果。1）环境搭建山东分行系统人员按照项目组试运行方案中的要求，安装了HP-UX、ASE12.5并按要求完成了相关参数的配置，安装了Suse Linux 9和Websphere5.1，总行项目组成员完成了IQ12.6，多维服务器的安装和配置。项目组根据以上安装情况，完善形成了银行卡统计分析系统后台安装手册、银行卡统计分析系统WebSphere安装手册、银行卡统计分析系统Cognos安装手册。2）数据准备山东分行按照试运行方案的要求完成了2007年3、4、5月份ABIS和AIPS数据的准备，随后又准备了2006年12月底和2007年1月、2月份的数据。在试运行的过程中发现分行准备的有些数据有问题，比如4月1日的CSD表有些记录被截断，分行人员从AIPS系统中重新抽取一次就没有问题了。根据数据准确情况，形成了银行卡统计分析系统数据处理策略。3）应用部署项目组在环境搭建完成后，执行安装程序完成后台所有应用程序的部署，初始化前、后台用到的所有参数表，根据系统环境修改环境变量；完成应用程序在WebSphere上的发布，Cognos应用程序的部署，完成监控系统的发布。项目组根据应用部署情况，完善了银行卡统计分析系统部署手册。4）系统运行在试运行的前期，系统运行的工作主要由项目组承担，系统运行比较稳定后，项目组逐渐把运行工作移交给分行人员进行。目前除了Cognos的一个问题导致系统不太稳定外，分行人员已经基本掌握系统的运行情况。其中从2006年12月底到2007年2月的数据由分行独立完成。5）系统测试项目组配合业务人员一起完成了系统测试，在测试的过程中，主要针对数据准确性、功能、性能、数据处理情况等几个方面。4试运行效果经过项目组全体成员的共同努力，目前系统的数据准确性、功能、性能、数据处理都达到了预定的效果，系统基本满足上线的条件。具体为：1）系统运行情况在以上所示机器资源配置和数据量的情况下，在7个并发的情况下，每日后台批量处理时间为30分钟，月底为5小时。运行过程中发现Cognos关于刷新Cube的程序不是太稳定，有时会中断，导致整个作业挂起。2）数据准确性业务部门对卡量、余额类，交易类，风险类，辅助采集类等数据与山东分行的数据广场和经营管理系统的数据进行核对，经过核对考虑统计口径上的差别，数据是准确的。项目组根据核对结果形成了数据准确性核对分析报告（附件一）。核对的大概情况为：借记卡卡量：总行统计口径为不包含注销卡、睡眠卡且人民币主账户状态为正常的卡，山东分行统计口径为卡状态为正常、未启用、睡眠卡，考虑统计口径上的差异，数据是完全能够对上的。借记卡余额：总行统计口径为不包含注销卡、睡眠卡，主卡下的账户状态为正常的人民币主账户余额，山东分行统计口径为卡状态为正常、未启用、睡眠卡，主卡下的账户状态为正常的账户余额，考虑统计口径上的差异，数据是完全能够对上的。准贷记卡卡量：总行统计口径为不包含注销卡、睡眠卡，人民币账户状态为正常的卡，山东分行统计口径为卡状态为正常的卡，考虑统计口径上的差异，数据是完全能够对上的。准贷记卡余额：总行统计口径为不包含注销卡、睡眠卡，主卡下的账户状态为正常的人民币账户余额，山东分行统计口径为卡状态为正常(包含睡眠卡)，主卡下的账户状态为正常的账户余额，考虑统计口径上的差异，数据是完全能够对上的。信用额度：总行统计是按照消费的信用额度进行的，分行是按照取现的信用额度进行的，这个问题还需要与相关人员确认。交易类数据：此类数据与山东分行数据广场差别较大，统计口径上存在较大的差别，如：存现交易：总行统计口径是银行卡交易明细（PPTJ）表中PPTJTRCODE=1的交易，山东分行数据广场除了统计PPTJ表中PPTJTRCODE=1的交易，还包括APSH表中符合APSHTRCOD in (1051,4212,2301,2309) and APSHDBKNO=0 and APSHACTNO in(PDCR or PCCI)的交易。其中1051为活期存现交易；2301、2309为还款交易，目前总行没有要求把这三种交易统计到卡存现交易中，4212为银行卡现金存现交易，但每笔4212交易在PPTJ中都已经有一笔PPTJTRCODE=1的交易与之相对应。取现交易：总行统计口径是银行卡交易明细（PPTJ）表中PPTJTRCODE=2的交易，山东分行数据广场除了统计PPTJ表中PPTJTRCODE=2的交易，还包括APSH表中符合APSHTRCOD in (2122,4213,4214) and APSHDBKNO=0 and APSHACTNO in(PDCR or PCCI)的交易。其中2122交易为准贷记卡密码重置交易，4213为银行卡活期账户取款交易，4214为银行卡现金取款交易，但这两个交易在PPTJ中都已经有一笔PPTJTRCODE=2的交易与之相对应。消费交易：总行统计口径是银行卡交易明细（PPTJ）表中PPTJTRCODE in (4,5,9,13,19,33)的交易，山东分行数据广场除了统计PPTJ表中PPTJTRCODE in (4,9)的交易，还包括APSH表中符合APSHTRCOD in (3961,2118,4254) and APSHDBKNO=0 and APSHVCHNO like P_Z% and APSHACTNO in(PDCR or PCCI)的交易。该部分交易包括转账电话交易；且山东分行数据广场中没有将PPTJTRCODE=19（网上消费）的交易统计在内，也没有剔除PPTJTRCODE in (5,13,33)的消费撤消交易。转入交易：总行统计口径是银行卡交易明细（PPTJ）表中PPTJTRCODE in (10,27)的交易，山东分行数据广场除了统计PPTJ表中PPTJTRCODE=10的交易，还包括APSH表中符合APSHTRCOD in (3958,3959,3960,3961,4210,3034,3042,2310,2368,3003,1045) and APSHDBKNO=0 and APSHACTNO in(PDCR或PCCI)的交易。其中3958位批量代付,3959 为转94，3960为转94，3961为个人折、卡互转，4210为过渡转入，3034 为活期主账户转开子账户，3042 为主账户转零整续存，2310为 放款转支票户/银行卡户/活期储蓄户，2368 为放款转银行卡户/活期储蓄户，3003为 活期子账户过渡转入，1045为转账存款，这些都与总行卡部定义的转入交易概念不一致。转出交易：总行统计口径是银行卡交易明细（PPTJ）表中PPTJTRCODE in (11,27)的交易，山东分行数据广场除了统计PPTJ表中PPTJTRCODE=11的交易，还包括APSH表中符合APSHTRCOD in (2113,3957,4211,3004,3961,1046) and APSHDBKNO=0 and APSHACTNO in(PDCR或PCCI)的交易。其中2113为准贷记卡转账销户，3957为代收，4211为过渡转出，3004为活期子账户过渡转出，3961为个人折、卡互转，1046为转账取款，这些都与总行卡部定义的转出交易概念不一致。2）功能业务部门对电子报表、数据查询、辅助采集、多维分析、系统管理和帮助等功能的测试，在测试的过程中提出了一些需求变更和新增了一些需求。针对这些情况，项目组进行初步分析整理，形成了试运行功能分析报告 （附件二）。3）性能项目组与分行系统人员一起对机器的性能进行分析，统计出运行过程中CPU、内存等的使用情况，并参照TPCC值衡量出系统配置情况。TPC-C = M × M0 ×（1M2）×（1M3） /（M1） 其中M：为需要处理的原数据记录数。经分析，山东分行2007年4月处理的月底全量源数据记录数约为11409万条记录(27.2GB的数据量,一条记录按平均0.25K计算)； M0：为处理一条记录所需的事务数，由于数据在进入中央数据库的过程中为批量处理，这里M0 可取为0.1，即1个事务内平均可处理10条记录。 M2：为主机CPU处理余量。实际应用表明，一台主机服务器的CPU利用率高于80%则表明系统会产生瓶颈，而利用率处于70%时，是处于利用率最佳状态。因此，这里设定M2=30%。 M3：为从原始数据加工到最终数据的过程中，处理的记录数与原始数据记录数的比，实际应用表明： M3=8比较适当。 M1：数据处理完成时间，这里M1=240。即数据处理完成时间不超过240分钟(4小时)。 所以：TPC-C = M × M0 ×（1M2）×M3 /（M1） 114090000×0.1×(1+30%)×(1+8)/240 556,188.8CPU个数556,188.8/5000012个综上，山东分行的数据量在全行属于大行，结合全国其余几家大行的情况，因此将数据库服务器的CPU设置为：12个4个16个；内存设置为：16(CPU)×464G；并发作业数等于数据库可用CPU个数减1，即：16(CPU)2(系统使用)-4(解压缩等操
