具体实施方式
为对本申请进行进一步说明,提供下列实施例:
请参考图1,图1示出了根据本申请一示例性实施例的数据处理方法,可以应用于服务器,该方法包括以下步骤:
步骤102,当检测到对用户账号下的剩余数据的查询需求时,从账号数据表中获取所述用户账号对应的剩余数据和历史处理时间;
在本实施例中,基于需求触发对用户账号下剩余数据的更新,因而即便已经生成了对应的增量数据,只要暂时不存在对剩余数据的“查询需求”,就无需执行相应的更新处理,所以当用户账号的数量巨大时,各用户账户对应的增量数据能够基于“查询需求”的触发时机不同,实现了对各用户账户下剩余数据的分散化更新处理,避免对系统造成过大的计算压力,有助于提升各用户账号下剩余数据的更新效率。
其中,对剩余数据的查询需求可以通过多种方式被触发,比如用户直接点击查询剩余数据状况,或用户启动基于剩余数据执行的业务处理时,间接导致对剩余数据的查询需求等。
步骤104,从增量数据明细表中确定对应于所述用户账号的增量数据明细信息,其中每条增量数据明细信息包括增量数据和该增量数据的被插入时间;
在本实施例中,通过建立账号数据表,可以准确存储每个用户账号对应的剩余数据,便于直接查询最终结果;而通过建立增量数据明细表,使得增量数据的生成与对剩余数据的更新相互分离,则一方面能够基于增量数据明细表来实现对增量数据的准确记录,另一方面可以确保通过结合账号数据表和增量数据明细表中的数据,随时对用户账号下的剩余数据进行更新处理。
在本实施例中,将增量数据插入增量数据明细表时,仅通过insert(插入)语句即可实现,使得插入增量数据的语句简单,并且有助于提升执行效率。
步骤106,根据对应的被插入时间晚于所述历史处理时间的所有增量数据,更新所述剩余数据,并将所述历史处理时间更新为所述所有增量数据对应的最晚被插入时间;
在本实施例中,通过记录历史处理时间和被插入时间,从而基于时间对比来实现对剩余数据的准确更新,避免增量数据被用于重复计算或被遗漏。
步骤108,向预设对象输出更新后的剩余数据。
由上述实施例可知,本申请通过对查询请求的触发情况进行检测,使得对用户账号下的剩余数据的更新处理时间与增量数据的生成时间相互分离,则即便同时生成所有用户账户对应的增量数据,也会由于查询请求的触发时间不同,实现对各用户账户下的剩余数据的分散化更新,从而降低了对系统计算能力的需求,并且有助于提升数据更新效率。
以图2为例进行说明。假定系统内存在多个用户账号分别为账号A、账户B和账号C,并且表1示出了包含各用户账号下的剩余数据的账号数据表。
用户账号 |
剩余数据 |
历史处理时间 |
A |
A0 |
2014.2.25 |
B |
B0 |
2014.3.29 |
C |
C0 |
2014.6.26 |
表1
假定在T1时刻,系统计算出了各用户账号分别对应的增量数据,并插入增量数据明细表中,具体如表2所示。当然,增量数据明细表可以采用如表2所示的形式,即所有用户账号下的增量数据等信息均集成为一张表;或者,也可以分别为每个用户账号生成对应的增量数据明细表,这对技术方案的实施没有影响。
用户账号 |
增量数据 |
被插入时间 |
A |
A1 |
2014.6.25 |
A |
A2 |
2014.6.26 |
A |
A3 |
T1 |
B |
B1 |
T1 |
C |
C1 |
2014.6.26 |
C |
C2 |
T1 |
表2
此时,虽然账号A、账号B和账号C对应的增量数据都已经生成并插入表2,但并不立即对这三个用户账号下的剩余数据进行更新处理,而是检测各用户账号对应的查询需求是否被触发。假定在T2时刻下,账号B对应的查询需求被触发(假定增量数据明细表仍如表2所示),则首先由表1查看账号B对应的历史处理时间为2014.3.29,即用户账号B对应的剩余数据B0是最近于2014年3月29日进行更新得到的;同时,假定时间T1为2014.6.27,则用户账号B在表2中对应的增量数据B1的被插入时间T1晚于相应的历史处理时间,需要基于增量数据B1对剩余数据B0进行更新,得到表3所示的新剩余数据B0’,并将历史处理数据更新为T1。
假定在T3时刻下,账号C对应的查询需求被触发(假定增量数据明细表仍如表2所示),则首先由表1查看账号C对应的历史处理时间为2014.6.26,即用户账号C对应的剩余数据C0是最近于2014年6月26日进行更新得到的;同时,假定时间T1为2014.6.27,则用户账号C在表2中对应的增量数据C1的被插入时间2014.6.26与相应的历史处理时间相同、增量数据C2的被插入时间T1晚于相应的历史处理时间,需要基于增量数据C2对剩余数据C0进行更新,得到表3所示的新剩余数据C0’,并将历史处理数据更新为T1。
假定在T4时刻下,账号A对应的查询需求被触发(假定增量数据明细表仍如表2所示),则首先由表1查看账号A对应的历史处理时间为2014.2.25,即用户账号A对应的剩余数据A0是最近于2014年2月25日进行更新得到的;同时,假定时间T1为2014.6.27,则用户账号A在表2中对应的增量数据A1的被插入时间2014.6.25晚于相应的历史处理时间、增量数据A2的被插入时间2014.6.26晚于相应的历史处理时间、增量数据A3的被插入时间T1晚于相应的历史处理时间,需要基于增量数据A1、A2和A3对剩余数据A0进行更新,得到表3所示的新剩余数据A0’,并将历史处理数据更新为A1、A2和A3中对应的最晚被插入时间T1。
用户账号 |
剩余数据 |
历史处理时间 |
A |
A0’ |
T1 |
B |
B0’ |
T1 |
C |
C0’ |
T1 |
表3
本申请的技术方案可以应用于各种数据处理的应用场景下;作为一示例性实施例,下面以“余额宝”的收益场景为例进行详细说明。请参考图3,上述收益场景可以基于服务器侧建立的离线计算系统、财务系统和应用系统相互配合实现,该方法可以包括以下步骤:
步骤302,离线计算系统根据每天获得的总收益金额、各用户账号下的投入资金、预设的收益分配原则等信息,离线计算各用户账号对应的收益金额;
在本实施例中,“离线计算”是指收益金额的计算过程对于“余额宝”、“支付宝”平台等的在线业务没有任何影响,并且计算过程是基于静态数据的处理过程,因而在系统更稳定的情况下,可以实现更高的处理效率。
步骤304,离线计算系统拆分计算结果;
在本实施例中,计算结果即步骤302中计算出的每个用户账号对应的收益金额。由于用户账号的数量很多,因而每个用户账号对应的收益金额可以视为一条数据项;根据预设的拆分数量,可以在每当产生该拆分数量的数据项时,就由这些数据项生成相应的文件,从而由财务系统以“文件”为单位实现对收益金额的解析和发放。
其中,拆分得到的每个文件均可以利用独立线程进行处理,从而后续对文件进行解析时,可以通过并行处理来提升效率。
步骤306,离线计算系统将文件存储至预设路径;
步骤308,离线计算系统将存储的文件名称和对应的存储路径告知财务系统;
在本实施例中,离线计算系统每生成一个文件时,就可以将其存储至相应的路径并告知财务系统,则离线计算系统对文件的生成和财务系统对文件的解析处理可以在时间上实现部分重叠,有助于提升处理效率。
步骤310,财务系统根据离线计算系统告知的文件名称和存储路径,为每个文件注册相应的子任务,并设置对应的处理状态;
在本实施例中,财务系统可以建立对应的子任务列表,在该子任务列表中记录每个子任务及其对应的处理状态,比如初始时的处理状态为“1”。
步骤312,遍历尚未处理的子任务,并对其进行处理;
在本实施例中,当建立了子任务列表时,可以通过在该子任务列表中查找处理状态为“1”的子任务,并对其进行处理。
步骤314,财务系统将收益金额与用户账号相关联地插入增量数据明细表中;
在本实施例中,每个文件可以进行一次事务级的批量插入操作,以确保更快的处理速度。以用户账号A为例进行说明,假定在解析处理某个文件时,解析出对应于用户账号A的收益金额为40,并插入表4所示的增量数据明细表中。
用户账号 |
收益金额 |
被插入时间 |
A |
100 |
2014.7.1 |
A |
50 |
2014.7.2 |
A |
40 |
2014.7.3 |
表4
假定当前日期为2014年7月3日,则如表4所示,收益金额为40的数据项对应的被插入时间为2014.7.3;同时,假定用户账号对应的数据项还包括在2014年7月1日插入的收益金额100、在2014年7月2日插入的收益金额50。
步骤316,当完成了对某个子任务的处理,即该子任务对应文件内的收益金额均以发放(即插入增量数据明细表中),则对该子任务的处理状态进行修改,以表明该子任务已完成,避免被再次遍历到;
在本实施例中,可以讲已完成处理的子任务的处理状态由初始时的“1”更新为“0”,以区分不同处理状态下的子任务。
步骤318,假定基于用户对余额的查询操作或消费操作,触发了对实际余额的查询需求;
步骤320,基于账号数据表和增量数据明细表中的记录,对用户账号下的实际余额进行更新。
在本实施例中,假定账号数据表中对于用户账号A下的记录数据项如表5所示。
用户账号 |
余额 |
历史处理时间 |
A |
1000 |
2014.7.1 |
表5
结合表4和表5中的数据项,由于表5中对应于用户账号A的余额1000的历史处理时间为2014.7.1,即2014年7月1日计算得到用户账号A的余额为1000。而表4中记录的用户账号A对应的收益金额中,收益金额100对应的被插入时间为2014.7.1,与表5中的历史处理时间相同,说明该收益金额100已经被计入余额1000中,则忽略该数据项;收益金额50对应的被插入时间为2014.7.2,晚于表5中的历史处理时间,即尚未被计入余额1000中,需要用于本次的余额更新操作;收益金额40对应的被插入时间为2014.7.3,晚于表5中的历史处理时间,即尚未被计入余额1000中,需要用于本次的余额更新操作。因此,对表5中的余额进行更新,得到表6所示的数据项。
用户账号 |
余额 |
历史处理时间 |
A |
1090 |
2014.7.3 |
表6
其中,选取表4中对应于用户账号A的最晚被插入时间,即收益金额40对应的被插入时间2014.7.3,已更新为表6中对应于用户账号A的余额1090的历史处理时间,则下次触发对用户账号A的余额更新操作时,只会考虑被插入时间晚于2014.7.3的数据项,避免表4中的数据项被重复应用,确保余额计算的准确性。
需要说明的是:本申请虽然采用了“步骤302”至“步骤312”的描述和图示方式,但需要根据实际需求调整其处理过程。比如作为一示例性实施方式,步骤302至步骤310中的每个步骤可以在完全执行完成后,再转入后一个步骤。比如步骤302中,可以对所有用户账号对应的收益金额均计算完成后,再转入步骤304进行拆分操作;类似地,可以在步骤304中将所有计算结果均拆分和生成相应的文件后,再转入步骤306进行文件的存储操作,可以在步骤306中将所有文件均存储完成后,再转入步骤308将所有文件的名称和存储路径告知财务系统,然后步骤310中为所有的文件注册相应的子任务。
而作为另一示例性实施方式,对于每个步骤:若当前步骤生成了可以由后一步骤进行处理的数据后,即可转入后一步骤进行处理,同时当前步骤可以继续接收并处理来自前一步骤的数据,则各步骤实现对数据的传输和处理。具体地,比如当步骤302计算第N项收益金额时,步骤304可能正在将第N-1至第N-49项收益金额拆分并生成为文件M,步骤306正在对文件M-1进行存储,步骤308正在将文件M-2的名称和存储路径告知财务系统,步骤310正在为文件M-3注册对应的子任务,步骤312则遍历得到文件M-4并对其进行处理,步骤314正在将文件M-5中的收益金额插入增量数据明细表中,而步骤316正在更新文件M-6的处理状态。
图4示出了根据本申请的一示例性实施例的服务器的示意结构图。请参考图4,在硬件层面,该电子设备包括处理器、内部总线、网络接口、内存以及非易失性存储器,当然还可能包括其他业务所需要的硬件。处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行,在逻辑层面上形成数据处理装置。当然,除了软件实现方式之外,本申请并不排除其他实现方式,比如逻辑器件抑或软硬件结合的方式等等,也就是说以下处理流程的执行主体并不限定于各个逻辑单元,也可以是硬件或逻辑器件。
请参考图5,在软件实施方式中,该数据处理装置可以包括获取单元、确定单元、更新单元和输出单元。其中:
获取单元,当检测到对用户账号下的剩余数据的查询需求时,从账号数据表中获取所述用户账号对应的剩余数据和历史处理时间;
确定单元,从增量数据明细表中确定对应于所述用户账号的增量数据明细信息,其中每条增量数据明细信息包括增量数据和该增量数据的被插入时间;
更新单元,根据对应的被插入时间晚于所述历史处理时间的所有增量数据,更新所述剩余数据,并将所述历史处理时间更新为所述所有增量数据对应的最晚被插入时间;
输出单元,向预设对象输出更新后的剩余数据。
可选的,还包括:
计算单元,分别计算每个用户账号对应的增量数据;
插入单元,将计算结果与用户账号相关联地插入至所述增量数据明细表中。
可选的,所述计算单元具体用于:
确定所有用户账号对应的总增量数据;
按照每个用户账号对应的数据分配权重,离线计算每个用户账号对应的增量数据。
可选的,所述插入单元具体用于:
按照预设的单位数据量,将所述计算结果拆分为多个文件;
分别解析每个文件,并将解析到的增量数据与用户账号相关联地插入至所述增量数据明细表中。
可选的,所述插入单元具体还用于:
为生成的每个文件注册对应的子任务,并将该子任务记录至预设的子任务表,其中该子任务对应的处理状态为第一状态;
遍历所述子任务表,提取处理状态为第一状态的子任务;
解析与提取的子任务相对应的文件,将解析出的增量数据与用户账号相关联地插入至所述增量数据明细表中,并将提取的子任务的处理状态更新为第二状态。
因此,本申请通过建立账号数据表和增量数据明细表,使得大量用户账号下的增量数据并非同时更新,而是基于需求实现分散化,从而降低了对系统运算能力的要求,并能够实现更高效率的数据更新处理。
在一个典型的配置中,计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flashRAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitorymedia),如调制的数据信号和载波。
还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
以上所述仅为本申请的较佳实施例而已,并不用以限制本申请,凡在本申请的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本申请保护的范围之内。