网络支付海量数据存取处理的研究

（kkkloveyou 广州 广东商学院 信息学院）

摘要：随着网络购物的普及，网上支付业务蓬勃发展，同时网络支付行为带来的海量数据处理也给网络支付平台带来了巨大挑战。本文从针对网络支付带来的海量数据带来的问题，通过改进和优化数据库配置、数据分割、数据分类、处理算法、数据访问、虚拟内存和文本格式处理等方面，对网络支付带来的海量数据存取处理进行研究，提出了几个可行性的解决方案，具有实际指导作用。

关键词:网络支付 海量数据 处理

0.引言

截至2010年末，国内网络支付市场规模已经突破1万亿元。根据易观智库EnfoDesk《2011年Q3中国第三方支付市场季度监测》数据报告显示，2011年第3季度中国第三方互联网在线支付市场交易规模达到5643亿，环比增长22.4%，同比增长95%[1]。伴随着互联网的普及以及中国金融支付体系的不断完善与创新，网络支付的发展进入前所未有的腾飞年代[2]。从概念上看，网络支付是电子支付的一种形式。广义地讲，网上支付是以互联网为基础，利用银行所支持的某种数字金融工具，发生在购买者和销售者之间的金融交换，而实现从买者到金融机构、商家之间的在线货币支付、现金流转、资金清算、查询统计等过程。网络支付是采用先进的技术通过数字流转来完成信息传输的，其各种支付方式都是采用数字化的方式进行款项支付的[3]。相比与传统的支付方式，网络支付具有方便、快捷、高效、经济的优势。用户只要拥有一台上网的PC机，便可足不出户，在很短的时间内完成整个支付过程。但同时，网络支付带来的海量数据，正给网络支付平台带来了巨大挑战。以第三方网上支付平台支付宝为例，仅2011年11月11日当天，便创下当天支付交易量3369万笔，比去年纪录增长了近170%。网络支付海量数据的存取处理，成为一个不可忽视的课题。

1. 网络支付海量数据带来的瓶颈

1.1数据存取效率低下

网络支付数据往往呈现出线性增长，巨大的数据不断膨胀往往给应用系统带来一些难以忍受的后果, 最典型的是系统在运行过程中资源消耗需求量越来越大, 运行效率明显降低, 随着时间的推移, 达到难以忍受的程度[4]。数据访问时, 随着检索范围加大, 查询效率会显著降低,用户在查询时无法得到有效的数据后，将失去等待的耐心而逐步放弃使用系统, 使系统失去存在的意义[5]。

1.2数据安全性、完整性不能保证

网络支付对系统安全性完整性要求较高，以支付宝为例，2011年11月11日凌晨0:01分，支付宝在一分钟内的付款笔数就超过5.5万笔，涉及上百万资金。然而, 随着数据的积累, 数据表(Table)和数据库(DataBase)变得日渐庞大[6]，系统处理和响应的速度会越来越慢越来越慢。当系统响应慢到一定程度时, 数据处理的时效性就不能满足要求, 最后可能直接导致数据丢失。比如，用户A往用户B汇入30万人民币，当用户A 点击提交转账后，系统没有及时给予转账成功的反馈。于是用户A 认为转账没有成功，再次向用户B 汇入30万人民币。最后系统将60万人民币转给了用户B ，而这并不是用户A 所期望的。

2. 解决方案　

实现海量数据存取的方法主要从以下几个方面入手。

2.1数据库配置

选用合适的数据库。数据库管理系统要确保数据的安全, 防止非法用户窃取和破坏数据, 通常系统采用身份验证、口令、密码、控制用户权限等方法保证数据安全[7]。如支护宝用户账号密码、银行账目不得非法改动等均属数据安全性范畴。网上支付海量数据处理系统一般在网络(LAN或WAN) 环境下运行。系统的安全性十分重要。选用的平台必须有完整的安全机制。目前微软公司开发的SQL server 2008和Oracle 11g等都配备了非常之强大安全防护性能, 安全机制也比较完备, 它设有登录安全性、DB 安全性、DB 对象安全性等机制。在建表时, 可设置各种约束, 在数据库中可创建规则、默认值、存储过程、触发器等DB 对象, 来保证字段和记录的有效性。

数据库缓存的配置也相当重要，缓存大小设置的好差也关系到数据处理的成败，例如，网上支付平台在处理2 亿条数据操作时，缓存设置为100000条/Buffer，这对于这个级别的数据量是可行的

2.2数据分类

　 为了减少数据的冗余, 防止存储异常, 提高处理速度, 在开发过程中, 针对各类管理对象都进行编号处理, 并保存在不同的“对象定义表”中，即建立视图(VIEW)。视图中的数据来源于基表，对海量数据的处理，可以将数据按一定的规则分散到各个基表中，查询或处理过程中可以基于视图进行，这样分散了磁盘I/O。同类对象放在同一个定义表中, 编号不重复, 并用不同的字段定义管理对象的属性。记录和加工业务数据时, 只处理对象编号和业务数据, 把结果放在不同的“业务数据表”中。在进行数据检索和存取时, 通过数据视图或直接进行“对象定义表”和“业务数据表”的联接。根据业务数据被加工汇总的程度, 又进一步把“业务数据表”划分为不同的“原始业务数据表”、“按日汇总业务数据表”、“按月汇总业务数据表”。经过记录和加工的业务数据, 有部分是用来指导和规范业务活动的, 把这部分数据分别存放在不同的“业务管理表”中。数据分类结构如图1 所示。

Flag1

2.3数据分割

海量数据处理难因为数据量大，那么解决海量数据处理难的问题其中一个技巧是减少数据量。可以对海量数据分批处理，然后处理后的数据再进行合并操作，这样逐个击破，有利于小数据量的处理，不至于面对大数据量带来的问题在使用系统过程中。临时表的使用和中间使用也是如此，如果对于超海量的数据，大表处理不了，只能拆分为多个小表。

在具体的项目中，用户最关心的数据是当月的业务数据, 其次是当年的业务数据, 再次是往年的业务数据。查询业务数据的频率从高到低排列, 依次为当月、当年、往年, 而且查询的时间段极少跨年度。根据这个规律, 在数据库设计中, 把“业务数据表”按年度分割存放, 每年的“业务数据表”放在一个数据库(“年度数据库”)中, 同时对当月的“业务数据表”另外放在一个数据库(“当前数据库”)中, 这就保证了每个数据库和每个表的内容不会无限增长。“对象定义表”中的各个字段值具有相对稳定的特点, 因此也把它们按年度来保存。每个“年度数据库”中保存一份对应的“对象定义表”,当年的“对象定义表”保存在“当前数据库”中。“业务管理表”存放的是一些规则和规律, 数据量不大, 但是要求被查询时能迅速返回结果, 而且这些规则和规律只对正在发生和将来发生的业务起作用, 因此把它们放在“当前数据库”中。数据分割存放结构如图2 所示。

Flag2

2.4数据处理算法

对海量的数据处理，对大表建立索引是必行的，建立索引要考虑到具体情况，例如针对大表的分组、排序等字段，都要建立相应索引，一般还可以建立复合索引，对经常插入的表则建立索引时要小心，笔者在处理数据时，曾经在一个ETL 流程中，当插入表时，首先删除索引，然后插入完毕，建立索引，并实施聚合操作，聚合完成后，再次插入前还是删除索引，所以索引要用到好的时机，索引的填充因子和聚集、非聚集索引都要考虑。索引的优点和局限索引可以提高查询的效率，但会降低DML操作的效率。所以建立索引时需要权衡。对于DML操作比较频繁的表，索引的个数不宜太多;不同值较多的列上可建立检索，不同值少的列上则不要建。比如在用户表的“性别”列上只有“男”与“女”两个不同值，因此就没必要建立索引。如果建立索引不但不会提高查询效率，反而会严重降低更新速度[7]。

必要时我们还可以给数据表创建“ 索引表”。例如，当需要进行模糊查询的时候，我们一般采取的解决办法是执行sql语句like select * from table where 某列 like‘ %×××%’，这样如前所述，即便该列已经加了索引，在进行like 查询时候，索引也起不到任何作用。那么，这种情况，应该怎么处理呢？

我们以搜寻用户账户数据为例，假设一个表中存有一百万条数据，那么我们可以设计这个表有一个pk_id 列（长整型）来唯一标识一条记录。表中存在一列是描述信息列。该列的内容都是英文字母。这样，我们通过程序，先将该月数据进行处理，创建26 套索引表，每个索引表有两个列，一列（sKey）存放关键字，一列（sID）存放这些关键字在数据主表中出现的那些记录的pk_id（以某一特定分隔符来分割表示。例如 第 1、3、5 这3 条记录中存在关键字“TOY”那么在 T 索引表中有这样一条记录，TOY1，3，5）。这样，如果程序要搜索关键字是“TOY”的信息记录。执行过程是这样的：首先从T 索引表中，用“Select top 1 sID from T 索引表 where sKey =’TOY’” , 然后得到主数据表中的pk_id 为 1、3 、5 这三条记录 是含有关键字“TOY”的记录。这时，再执行“ select * from mainData where pk_id in（1，3，5）”, 得到所需数据。经过实际测试，用上述方法，比直接采用“select * from mainData where 描述信息列 like‘ %TOY%’”方式，系统返回结果的时间要快十倍以上，特别是在单表数据量超过百万后，效果更佳突出。

又如在实际的数据访问中, 作业层工作人员最关注原始数据和流水清单数据, 而管理层和决策层人员最关注按日或按月汇总的业务数据报表。大部分用于管理和指导的数据也是要求按日或按月汇总。因此, 很多数据不是需要使用时才从原始数据来直接汇总加工, 而是可以采用“以空间换时间”的原则,在适当的时间, 事先进行数据的按日或按月汇总, 生成对应的汇总数据表。利用这种规律, 在受理作业层工作人员对原始数据和流水清单的要求时, 可以直接从“原始业务数据表”中访问检索; 同时, 在受理管理层和决策层人员的业务数据报表要求时, 避免了对大量原始数据的直接访问检索和加工汇总, 可以针对性地从“按日汇总业务数据表”或“按月汇总业务数据表”中的少量数据中检索汇总, 这样大大地提高了系统响应的速度和效率。

具体的数据处理算法如下: (1) 每天新增的管理对象和对管理对象的修改直接保存在“当前数据库”的各个“对象定义表”中。(2) 在每日规定的结算时间或业务活动结束后, 进行每日数据结算。对原始业务数据进行加工整理, 生成各类按日汇总业务数据, 保存在“当前数据库”的各个“按日汇总业务数据表”中, 同时更新“业务管理表”。(3) 在每月月底的月报截止日, 进行月份数据结算和转存。把当月的“业务数据表”分类汇总, 生成按月汇总业务数据, 保存在“当年数据库”的各个“按月汇总业务数据表”中。(4) 把“当前数据库”中的各个“按日汇总业务数据表”转存到“当年数据库”的对应“按日汇总业务数据表”中, 并且清空“当前数据库”中的各个“按日汇总业务数据表”。(5) 在每年年底, 进行年度数据转存。把“当前数据库”中的各个“对象定义表”复制一份到“当年数据库”中, 生成新一年的数据库表结构。(6)将“当前数据库”作为新一年的“当月数据库”,删除“对象定义表”中已经淘汰的管理对象, 整理“业务管理表”[8][9][10]。

2.5数据访问

因数据是按年度存放的, 在访问数据时, 为使处理简单, 约定访问的时间段范围不能跨年度。这样在访问数据前, 首先判断要访问哪类数据。若为管理数据, 则直接从当月数据库中的“对象定义表”和“业务管理表”中查找。若为定义数据或业务数据, 则调用一个公用存储过程, 输入参数为访问时间段的起始日期和截止日期, 返回“对象定义表”和“业务数据表”所在的数据库名( 若访问时间段正好跨当年当月和当年往月时, 则要另外返回一标记说明业务数据跨数据库) 。而后, 在指定的数据库中访问对应的数据表。在对海量数据进行查询处理过程中，查询的SQL 语句的性能对查询效率的影响是非常大的，编写高效优良的SQL 脚本和存储过程是数据库工作人员的职责，也是检验数据库工作人员水平的一个标准，在对SQL 语句的编写过程中，例如减少关联，少用或不用游标，设计好高效的数据库表结构等都十分必要。

2.6 加大虚拟内存

如果系统资源有限，内存提示不足，则可以靠增加虚拟内存来解决。具体设置是，在[我的电脑]图标里点[右键]-[属性]弹出来的窗口里点[高级]选项卡，显示的第一项（性能）点[设置]在弹出来的窗口里点[高级]选项卡，显示内容的最下面（虚拟内存）点更改，然后在弹出的窗口里按需要改就好了，选择相应的分区选自定义大小输入后点右边的[设置]，最后点[确定]并重启，设置完成。比如，在实际项目中遇到针对18 亿条的数据进行处理，当主机内存仅为为1GB，1 个P4 2.4G 的CPU，对这么大的数据量进行聚合操作肯定是有问题的。如果采用了加大虚拟内存的方法，在6块磁盘分区上分别建立了6个4096M 的磁盘分区，用于虚拟内存，这样虚拟的内存则增加为4096*6+1024=25600M，很好的解决了数据处理中的内存不足问题。

2.7使用文本格式进行处理

对一般的数据处理可以使用数据库，如果对复杂的数据处理，必须借助程序，那么在程序操作数据库和程序操作文本之间选择，是一定要选择程序操作文本的，原因为：程序操作文本速度快；对文本进行处理不容易出错；文本的存储不受限制等。例如一般的海量的网络日志都是文本格式或者csv 格式（文本格式），对它进行处理牵扯到数据清洗，是要利用程序进行处理的，而不建议导入数据库再做清洗[11]。

3.结束语

本文通过分析网络支付业务的海量数据带来的问题，通过改进和优化数据库配置、数据分割、数据分类、处理算法、数据访问、虚拟内存和文本格式处理等方面，对网络支付带来的海量数据存取处理进行研究，提出了几个可行性的解决方案。该方案在实际系统中发挥了重要作用，具有实际指导作用。

参 考 文 献

[1]易观国际[EB/OL].2011[2011-11-8]. http://www.199it.com/archives/18036.html

[2]别坤.网络支付的技术演进[J].互联网周刊.2011,(02):40-41.

[3]Baidu baike[EB/OL].2010[2010-6-13]. http://baike.baidu.com/view/157458.html.

[4]何芳原.浅谈海量数据处理技术研究[J].硅谷.2009(08):59-60

[5]张金乙,姜文志,蒋伟俊,等.高速海量数据的接收和存储系统的设计与实现[J].计算机时代. 2007( 12):67-68.

[6]戴子良.海量数据处理分析[J] . Windows IT Pro Magazine. 2007(1): 37-39.

[7]李向阳,李朝庆.海量数据处理的几个技术问题及其解决方案[J].保险职业学院学报.2005(05):51-52

[8]张占杰.浅谈海量数据处理技巧[J]科技传播. 2011(02):170-171

[9][韩]李华植.海量数据库解决方案[M].郑保卫,盖国强译,京:电子工业出版社.2011

[10]周喜.Oracle外部过程在高性能海量数据处理中的应用[J].福建电脑2008(05):91-92

[11]林茂.虚拟现实项目中海量数据处理方法分析[J].价值工程.2011(19):158-159

（转载请注明出处）