CN117149702A - 一种业务数据的处理方法及相关设备 - Google Patents

Abstract

本申请实施例提供了一种业务数据的处理方法及相关设备，用于生成快照数据，以尽可能地维持快照数据的准确性以及CBS系统的稳定性。本申请实施例方法包括：获取目标业务库中的所有初始业务数据；生成对应于所述目标业务库中任一初始业务数据的初始快照数据，并将所述初始快照数据保存至所述目标业务库；其中，所述初始快照数据用于描述所述初始业务数据的版本数据；当所述CBS系统接收所述初始业务数据的业务变更指令，根据所述业务变更指令调用所述目标业务库中的所述初始快照数据，对所述初始快照数据进行修改，获取目标快照数据。

Description

一种业务数据的处理方法及相关设备

技术领域

本申请实施例涉及信息技术处理领域，尤其涉及一种业务数据的处理方法及相关设备。

背景技术

对于跨银行现金管理平台(CBS，cross-bank solution for cash management)系统的合同、收款或还款等模块中，若出现相关的业务操作，可能会导致业务数据发生变化，从而触发相关的更新任务，以更新业务日期之后的快照数据。在这种设计下，由于每条业务数据每天都需要保存一个快照版本，追踪生成的数据量直接受业务数据数量和业务日期数量的乘数影响，对数据的存储和性能方面要求较高。同时，在信贷业务逻辑下，业务间的关联性较大，因此，对于数据准确性、系统的稳定性或系统性能等方面都有严格要求。

因此，亟需一套功能链完善可靠的历史快照数据的生成方案。

发明内容

本申请实施例提供了一种业务数据的处理方法及相关设备，用于生成快照数据，以尽可能地维持快照数据的准确性以及CBS系统的稳定性。

本申请实施例第一方面提供了一种业务数据的处理方法，应用于CBS系统，所述方法包括：

获取目标业务库中的所有初始业务数据；

生成对应于所述目标业务库中任一初始业务数据的初始快照数据，并将所述初始快照数据保存至所述目标业务库；其中，所述初始快照数据用于描述所述初始业务数据的版本数据；

若所述CBS系统接收所述初始业务数据的业务变更指令，根据所述业务变更指令调用所述目标业务库中的所述初始快照数据，对所述初始快照数据进行修改，获取目标快照数据。

可选地，所述获取目标业务库中的所有初始业务数据之前，所述方法还包括：

获取原始业务库的增量数据及全库数据；其中，所述增量数据为所述原始业务库于任一时间点后存储的业务数据，所述全库数据为所述原始业务库于所述任一时间点前存储的业务数据；

将所述增量数据及所述全库数据同步至所述目标业务库，以使得所述目标业务库生成所述初始业务数据；

所述获取目标快照数据之后，所述方法还包括：

将所述目标快照数据保存至所述目标业务库，以使得所述目标业务库根据所述目标快照数据、所述增量数据及所述全库数据生成目标业务数据。

可选地，所述根据所述业务变更指令调用所述目标业务库中的所述初始快照数据，对所述初始快照数据进行修改，获取目标快照数据包括：

当所述CBS系统触发末位任务时，从所述目标业务库中的业务数据表获取所有所述初始业务数据；其中，所述末位任务用于描述交易日中所有任务列表中排序为末位的任务，所述业务数据表包括对应于任一交易记录数据的初始业务数据；

根据所有所述初始业务数据，于快照数据表中确认对应于任一所述初始业务数据的所述初始快照数据；其中，所述快照数据表包括对应于所述初始业务数据的快照数据；

若存在未与所述初始业务数据对应的初始快照数据，将任一交易日中未对应的初始业务数据进行还原，获取未对应的交易记录数据；

根据所述交易记录数据生成未对应交易日的初始快照数据，将所述未对应的初始快照数据存入所述快照数据表，以根据所有所述初始快照数据生成所述目标快照数据。

可选地，所述从所述目标业务库中的业务数据表获取所有所述初始业务数据，包括：

将所述业务数据表进行分段，获取第一子业务数据表及第二子业务数据表；

读取第一子业务数据表中的所述初始业务数据，并记录游标位置点；其中，所述游标位置点用于描述所述第一子业务数据表与所述第二子业务数据表的分段位置点；

基于所述游标位置点，读取所述第二子业务数据表中的所述初始业务数据。

可选地，所述根据所述业务变更指令调用所述目标业务库中的所述初始快照数据，对所述初始快照数据进行修改，获取目标快照数据包括：

当所述CBS系统触发针对于所述目标快照数据的所述业务变更指令时，获取增量数据；其中，所述增量数据为目标时间点后产生的业务数据；

将所述增量数据更新至原始业务库的原始业务表，将所述增量数据同步至目标业务库的业务数据表；其中，所述业务数据表包括对应于任一交易记录数据的初始业务数据；

根据所述业务变更指令，确定与所述增量数据的交易日对应的快照数据表中的初始快照数据；其中，所述快照数据表包括对应于所述初始业务数据的快照数据；

根据所述增量数据对所述初始快照数据进行修改，获取所述目标快照数据。

可选地，所述根据所述业务变更指令，确定与所述增量数据的交易日对应的初始快照数据之前，所述方法还包括：

将所述业务变更指令设置为目标执行任务，并将所述目标执行任务放置于待执行任务列表，以生成执行记录数据，以使得所述CBS系统执行所述根据所述业务变更指令，确定与所述增量数据的交易日对应的初始快照数据的步骤；

所述根据所述增量数据对所述初始快照数据进行修改之后，所述方法还包括：

当所述初始快照数据修改失败，且未超过预设重置次数时，将所述目标执行任务放置于失败任务列表；

设置调用任务，以于预设时间段从所述失败任务列表中调用所述目标执行任务，以使得所述CBS系统执行所述根据所述业务变更指令，确定与所述增量数据的交易日对应的初始快照数据的步骤。

可选地，所述所述根据所述增量数据对所述初始快照数据进行修改之后，所述方法还包括：

当所述初始快照数据修改成功，将所述目标快照数据更新至所述快照数据表。

本申请实施例第二方面提供了一种业务数据的处理系统，应用于CBS系统，包括：

获取单元，用于获取目标业务库中的所有初始业务数据；

生成单元，用于生成对应于所述目标业务库中任一初始业务数据的初始快照数据，并将所述初始快照数据保存至所述目标业务库；其中，所述初始快照数据用于描述所述初始业务数据的版本数据；

修改单元，用于当所述CBS系统触发所述初始业务数据的业务变更指令，根据所述业务变更指令调用所述目标业务库中的所述初始快照数据，对所述初始快照数据进行修改，获取目标快照数据。

本申请实施例第二方面提供的用于执行第一方面所述的业务数据的处理方法。

本申请实施例第三方面提供了一种业务数据的处理装置，包括：

中央处理器，存储器，输入输出接口，有线或无线网络接口以及电源；

所述存储器为短暂存储存储器或持久存储存储器；

所述中央处理器配置为与所述存储器通信，并执行所述存储器中的指令操作以执行第一方面所述的业务数据的处理方法。

本申请实施例第四方面提供了一种计算机可读存储介质，其特征在于，所述计算机可读存储介质包括指令，当所述指令在计算机上运行时，使得计算机执行第一方面所述的业务数据的处理方法。

从以上技术方案可以看出，本申请实施例具有以下优点：通过本申请实施例公开的一种业务数据的处理方法，先获取目标业务库中的所有初始业务数据；再生成对应于目标业务库中任一初始业务数据的初始快照数据，并将初始快照数据保存至目标业务库；其中，初始快照数据用于描述初始业务数据的版本数据；最后，若CBS系统接收初始业务数据的业务变更指令，根据业务变更指令调用目标业务库中的初始快照数据，对初始快照数据进行修改，获取目标快照数据。由此，通过将快照数据保存至目标业务库，且目标业务库仅进行快照数据的更新工作，从而尽可能地降低了业务操作之间的相互影响，维持快照数据的准确性以及CBS系统的稳定性。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。

图1为本申请实施例公开的一种业务数据的处理方法的流程示意图；

图2为本申请实施例公开的另一种业务数据的处理方法的流程示意图；

图3为本申请实施例公开的一种业务数据的处理系统的结构示意图；

图4为本申请实施例公开的一种业务数据的处理装置的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

当前，对CBS系统的合同、放款等模块符合条件的业务数据，每天通过定时任务生成该数据的快照版本。在放款、还款、收息等有可能会导致业务数据发生变化的操作发生的时候，也会触发更新业务日期之后的快照版本数据。如果同一个业务日期下发生多次修改，只保存最后一次修改的快照版本。在这种设计下，合同/放款在有效业务日期范围内每天都会生成一条快照版本数据，方便客户回顾业务数据在过去每一天发生的变化过程。

在当前的处理方案中，客户有需求需要查看业务数据在有效期范围内每一天的数据变化过程。例如当前账务日期是7月1日，合同的有效期是5月1日到8月31日。用户需要查看有效期起始日(5月1日)到账务日期(7月1日)之间每天的快照数据变化，包括合同信息直接的修改，以及放款、还款等操作间接导致合同信息的间接修改。而且由于每条业务数据每天都需要保存一个快照版本，最终生成的数据量直接受业务数据数量和业务日期数量的乘数影响，对数据的存储和性能方面要求较高。

由此，本申请实施例提供了一种业务数据的处理方法及相关设备，以解决上述问题，并生成相关的快照数据。

为方便理解，本申请实施例主要以信贷业务进行详细描述，在其他类似的业务中，也可以使用本申请技术方案所提出的处理方法，具体此处不做赘述。

请参阅图1，图1为本申请实施例公开的一种业务数据的处理方法的流程示意图。包括步骤101-步骤103。

101、获取目标业务库中的所有初始业务数据。

由上述描述可知，为尽可能地提高CBS系统的稳定性和相关性能，本申请将相关的业务数据均保存在目标业务库。由此，若要对快照数据进行修改和调整，需要先获取到目标业务库中所有初始业务数据。

在其中一个具体的实施例中，目标业务库是一种开源分布式数据库TIDB，该目标业务库可以存储与CBS系统中各类交易服务相关的业务数据。例如，与信贷服务相关的交易数据，具体此处不对具体的业务数据进行限制。基于该实施例，在另外一个具体的实施例中，CBS系统可以通过Feigh接口调用目标业务库中的业务数据表，从而获取目标业务库中存储的初始业务数据。其中，Feigh接口可以理解为一种组件，用于调用远程服务。换言之，也可以理解为远程服务提供一个HTTP接口供外接调用。再有，初始业务数据在业务数据表可以进行分类统计，例如，每一笔交易数据作为一条完成的初始业务数据，由此，业务数据表中存在多条初始业务数据，具体此处不进行赘述。

102、生成对应于目标业务库中任一初始业务数据的初始快照数据，并将初始快照数据保存至目标业务库。

当获取到初始业务数据后，便可以生成目标业务库中对应于任一初始业务数据的初始快照数据，从而将该初始快照数据保存至目标业务库。其中，该初始快照数据可以理解为用于描述初始业务数据的版本数据。

在其中一个具体的实施例中，由于在每一笔交易发生后，当天需要保存该笔交易的最后一个版本，其中，该版本即为快照数据。因此，对于目标业务库中任一笔初始业务数据，CBS系统上的数据快照服务data-handing可以生成每条业务数据的快照数据，并保存在TIDB上。

为方便理解，以下进行举例说明。比如这笔交易是8月1号发生，到今天8月8号为止，1号到8号每天都需要保存这交易的最后一次版本数据，所以一共保存了1号到8号的8条版本数据。具体此处不做赘述。

103、当CBS系统接收初始业务数据的业务变更指令，根据业务变更指令调用目标业务库中的初始快照数据，对初始快照数据进行修改，获取目标快照数据。

当CBS系统系统接受到关于初始业务数据的业务变更指令时，便可以根据该业务变更指令调用目标业务库中的初始快照数据，从而对该初始快照数据进行实时的更新和修改，从而获取目标快照数据。

在其中一个具体的实施例中，当CBS系统监测到信贷服务中发生交易变化，即发生会影响快照数据的动作的时候，可以通过feign接口调到data-handing服务，从而触发快照数据的实时修改。其中，交易变化可以理解为放款、还款或余额变动等。

基于该实施例，在另外一个具体的实施例中，CBS系统还可以通过相关程序读取TIDB中的目标业务库发生变化的业务数据，从而确定相关的信贷服务发生交易变化，由此可以修改TIDB的快照数据，以生成目标快照数据。

通过本实施例公开的一种业务数据的处理方法，先获取目标业务库中的所有初始业务数据；再生成对应于目标业务库中任一初始业务数据的初始快照数据，并将初始快照数据保存至目标业务库；其中，初始快照数据用于描述初始业务数据的版本数据；最后，若CBS系统接收初始业务数据的业务变更指令，根据业务变更指令调用目标业务库中的初始快照数据，对初始快照数据进行修改，获取目标快照数据。由此，通过将快照数据保存至目标业务库，且目标业务库仅进行快照数据的更新工作，从而尽可能地降低了业务操作之间的相互影响，维持快照数据的准确性以及CBS系统的稳定性。

为方便对上述中所描述的业务数据的处理方法进行详细描述，请参阅图2，图2为本申请实施例公开的另一种业务数据的处理方法的流程示意图。包括步骤201-步骤210。

201、获取原始业务库的增量数据及全库数据，并将增量数据及全库数据同步至目标业务库，以使得目标业务库生成初始业务数据。

本实施例中步骤201与前述图1中步骤101类似，具体的，在交易发生时，由于CBS系统的线程有限，因此可以将交易发生时的实时交易数据存储到原始业务库中，从而CBS系统可以通过获取原始业务库中的增量数据及全库数据，再将增量数据及全库数据同步至目标业务库，从而使得目标业务库生成初始业务数据。不难理解的是，全库数据可以理解为原始业务库中在某一时间点前存储的交易数据，而增量数据则是在该时间点后，同步前的交易数据。

在其中一个具体的实施例中，在发生信贷服务时，原始业务库可以将发生信贷服务时所产生的业务数据进行存储，其中，此处的业务数据可以理解为上述中的全库数据。若将全库数据存储完成时，在该信贷服务上又产生新的交易数据，原始业务库仍可以将该交易数据进行存储。其中，新的交易数据可以理解为增量数据。由此，CBS系统可以通过canal集群从原始业务库收集增量数据binlog并发送到kafka。然后，数据同步服务data-sync可以将开源平台kafka的增量数据binlog转成数据库sql，然后在TIDB重现sql，这时候相当于把原始业务库的数据原封不动地同步到目标业务库的TIDB上。

需要理解的是，在该实施例中，增量数据的格式多为binlog，因此，多以binlog数据描述增量数据。而kafka是一种开源平台，数据同步服务data-sync可用于解析binlog格式的增量数据。具体此处不对开源平台kafka或功能data-sync等进行详细描述。

202、生成对应于目标业务库中任一初始业务数据的初始快照数据，并将初始快照数据保存至目标业务库。

本实施例中步骤202与前述图1中步骤102类似，具体此处不做赘述。但需要说明的是，在其中一个具体的实施例中，快照数据的生成过程主要存在两种生成方式。一种是通过定时任务生成，另外一种是通过实时触发生成。为方便描述，对于第一种方式可参阅步骤203-步骤205。对于第二种方式可参阅步骤206-步骤209。

203、当CBS系统触发末位任务时，从目标业务库中的业务数据表获取所有初始业务数据，并根据所有初始业务数据，于快照数据表中确认对应于任一初始业务数据的初始快照数据。

由上述描述可知，本步骤主要是通过定时任务生成快照数据。具体的，在CBS系统触发末位任务时，可以从目标业务库中的业务数据表中获取所有的初始业务数据，从而根据所有的初始业务数据，在快照数据表中确定对应于任一初始业务数据的初始快照数据。不难理解的是，末位任务用于描述在交易日的任务列表中排序为末位的任务。业务数据表包括多条初始业务数据，即与任一交易记录数据对应的初始业务数据。快照数据表则包括基于初始业务数据生成的快照数据。不难理解的是，在另外一个实施例中，快照数据表也可以包括经过修改后的快照数据，具体此处不做赘述。

在其中一个具体的实施例中，可以将生成快照数据的任务作为日终任务的最后一个任务触发启动。再从TIDB的业务数据表中扫描出需要生成快照数据的所有初始业务数据。由此，CBS系统可以遍历所有的初始业务数据，并查出每一条初始业务数据在快照数据表中生成的初始快照数据，即已有的快照数据。

基于上述实施例，在另外一个具体的实施例中，由于在扫描过程中，如果一次性查出所有业务数据会造成服务器的内存压力。因此，可以采用游标查询的方式，批量取出业务数据进行查询。具体的，可以将业务数据表进行拆分，从而获取多个子业务数据表，然后读取第一子业务数据表后，可以记录相关的游标位置点。然后基于游标位置点读取第二子业务数据表，直至所有的子业务数据表读取完成。不难理解的是，游标位置点可以理解为相邻两个子业务数据表的区分位置点。

在另外一个实施例中，游标查询是指在读取业务数据的时候，不是在同一时间段将所有满足条件的业务数据全部读到内存，而是每次读取一部分业务数据，记录下读取的位置(这个位置就叫游标)，处理完之后再读取下一部分，如此重复直到读完所有满足条件的业务数据。这样可以避免大量业务数据由于在同一时间段读取到内存而导致内存溢出问题。

对应的，为方便对已有快照数据进行详细描述，以下进行举例说明。例如，本交易日为2023年8月8日。1、新建一笔交易，业务日期起始日是8月1号，因为产品要求从业务日期起始日开始每天都需要生成快照数据，所以预期结果是8月1号到8月8号每天都会生成一条快照数据。因为是新建的业务数据，若未存在相关的快照数据，就会创建8月1号到8月8号这些天的8条快照数据。由此，已有快照数据则是8月1号到8月8号的快照数据。

204、若存在未与初始业务数据对应的初始快照数据，将任一交易日中未对应的初始业务数据进行还原，获取未对应的交易记录数据。

通过上述的筛选方式，若存在未与初始业务数据对应的初始快照数据，则将该交易日的初始业务数据进行还原，从而获取相关的交易记录数据。

在其中一个具体的实施例中，按照查漏补缺的方式，查询是否存在未根据初试业务数据而生成的初始快照数据。若未存在，则使用放款、还款、余额变动等现有的业务数据还原出来业务日期当天的交易记录数据。

为方便理解，以下进行举例说明。具体的，更新的业务日期是8月5号，在检查快照业务表时，发现未存在8月5日至8月8日的快照数据，但存在8月5日至8月8日的业务数据。由此，便可以基于业务数据生成相关的交易记录数据。

205、根据交易记录数据生成未对应交易日的初始快照数据，将未对应的初始快照数据存入快照数据表，以根据所有初始快照数据生成目标快照数据。

基于上述步骤中的交易记录数据生成对应交易日的初始快照数据，并将该快照数据存入快照数据表，由此根据所有初始快照数据生成目标快照数据。从而执行步骤210。

在其中一个实施例中，可以根据相关的交易记录数据创造从而快照有效期的起始日到账务日期当天缺漏的快照数据，从而将创建的快照数据批量更新到快照数据表。

基于上述实施例，可以直接更新8月5号到8月8号的快照数据。不难理解的是，以上仅为举例说明，具体此处不对其他的交易日的快照数据的生成方式进行赘述。

206、当CBS系统触发针对于目标快照数据的业务变更指令时，获取增量数据，并将增量数据更新至原始业务库的原始业务表，将增量数据同步至目标业务库的业务数据表。

由上述描述可知，本步骤主要是通过实时触发的方式生成快照数据。具体的，当CBS系统触发针对于目标快照数据的业务变更指令时，会触发快照数据修改的流程。具体的，先获取增量数据，再将增量数据更新至原始业务库的原始业务表，从而将增量数据同步至目标业务库的业务数据表。具体的同步实现方式可参阅步骤201。

在其中一个具体的实施例中，在业务服务(信贷服务)上发生影响快照数据的操作的时候，会触发快照修改流程。在处理完相关的业务逻辑后，先把业务数据更新到原始业务库，这部分业务数据会通过数据同步服务data-sync同步到TIDB的业务数据表上。然后通过feign接口调用快照服务data-handing，把要更新的业务数据同步至目标业务库的业务数据表。

207、将业务变更指令设置为目标执行任务，并将目标执行任务放置于待执行任务列表，以生成执行记录数据。

为方便修改快照数据，将相关的业务变更指令设置为执行任务，即目标执行任务，并将目标执行任务放置于待执行任务列表，从而生成执行记录数据。

在其中一个具体的实施例中，将业务变更指令封装为一个待执行的任务，并放入执行任务的线程池运行，然后生成执行记录。其中，该执行记录可以理解为记录针对于某一交易日的执行任务，也可以理解为记录存在关联的交易日的执行任务。

208、根据业务变更指令，确定与增量数据的交易日对应的快照数据表中的初始快照数据，并根据增量数据对初始快照数据进行修改，获取目标快照数据。

基于上述步骤，便可以根据与业务变更指令相关的目标执行任务，确定与新增的增量数据的交易日对应的快照数据表中的初始快照数据，从而根据增量数据对初始快照数据进行调整和修改，以获取目标快照数据。

在其中一个具体的实施例中，执行与业务变更指令相关的目标执行任务时，可以查询需要修改的业务日期当天的快照数据，并利用上述步骤207中所同步的对象和业务数据(即相关的增量数据或其他业务数据)，进行业务逻辑处理，从而将初始快照数据更新为目标快照数据。

基于上述实施例，具体的，还可以是从快照数据表中查出要修改的业务日期当天的快照数据，从而用同步过来的最新对象以及业务数据，从而进行业务逻辑处理，以更新初始快照数据。若更新成功，执行步骤210。若更新失败，执行步骤209。

209、当初始快照数据修改失败，且未超过预设重置次数时，将目标执行任务放置于失败任务列表，并设置调用任务，以于预设时间段从失败任务列表中调用目标执行任务。

当初始快照数据修改失败，且修改次数未超过预设重置次数时，则将目标执行任务放置于失败任务列表，并设置相关的调用任务，从而在预设时间段内从而失败任务列表中继续调用该目标执行任务，以执行步骤208。

在其中一个具体的实施例，若初始快照数据修改失败，且失败此处不超过额定次数(例如，3次或者4次等)，就将该目标执行任务放入失败队列，从而等待批量调度任务再次执行更新。在其中一个实施例中，调用任务的执行时间可以是15分钟，也可以是20分钟，具体此处不进行限制。

在另外一个具体的实施例中，当初始快照数据修改失败，且修改次数超过预设重置次数时，则直接结束。不再对该初始快照数据进行更新。

210、将目标快照数据保存至目标业务库，以使得目标业务库根据目标快照数据、增量数据及全库数据生成目标业务数据。

当目标快照数据更新完成后，便可以将该目标快照数据保存至目标业务库。从而，目标业务库中的快照数据表可以进行相对应的更新。同时，目标业务库可以根据相关的目标快照数据、增量数据及全库数据生成目标业务数据，以便于相关用户的使用等。

通过本实施例公开的一种业务数据的处理方法，可以使用高性能的分布式数据库TIDB作为存储系统，以有效解决mysql性能瓶颈问题。同时，还可以通过多种手段，例如通过锁等手段，保证一个合同下的多个放款单、一个放款单下的多个还款单在并发执行或者非顺序执行的情况下，仍能保证最终结果准确性。再有，还可以通过使用失败队列等手段，保证失败任务具备一定的重试机制，并保证重试的可靠性。

应该理解的是，虽然如上所述的各实施例所涉及的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，如上所述的各实施例所涉及的流程图中的至少一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。

若方案涉及敏感信息(如用户信息、企业信息)，则应当说明针对敏感信息的收集、使用和处理需要遵守相关国家和地区的法律法规和标准，且需要在相应主体(如用户或企业等)许可或同意的情况下进行。

请参阅图3，图3为本申请实施例公开的一种业务数据的处理系统的结构示意图。

获取单元301，用于获取目标业务库中的所有初始业务数据；

生成单元302，用于生成对应于目标业务库中任一初始业务数据的初始快照数据，并将初始快照数据保存至目标业务库；其中，初始快照数据用于描述初始业务数据的版本数据；

修改单元303，用于当CBS系统触发初始业务数据的业务变更指令，根据业务变更指令调用目标业务库中的初始快照数据，对初始快照数据进行修改，获取目标快照数据。

示例性地，系统还包括：同步单元304及保存单元305；

获取单元301，还用于获取原始业务库的增量数据及全库数据；其中，增量数据为原始业务库于任一时间点后存储的业务数据，全库数据为原始业务库于任一时间点前存储的业务数据；

同步单元304，用于将增量数据及全库数据同步至目标业务库，以使得目标业务库生成初始业务数据；

保存单元305，用于将目标快照数据保存至目标业务库，以使得目标业务库根据目标快照数据、增量数据及全库数据生成目标业务数据。

示例性地，系统还包括：确定单元306；

获取单元301，具体用于当CBS系统触发末位任务时，从目标业务库中的业务数据表获取所有初始业务数据；其中，末位任务用于描述交易日中所有任务列表中排序为末位的任务，业务数据表包括对应于任一交易记录数据的初始业务数据；

确定单元306，用于根据所有初始业务数据，于快照数据表中确认对应于任一初始业务数据的初始快照数据；其中，快照数据表包括对应于初始业务数据的快照数据；

获取单元301，还用于当存在未与初始业务数据对应的初始快照数据时，将任一交易日中未对应的初始业务数据进行还原，获取未对应的交易记录数据；

生成单元302，具体用于根据交易记录数据生成未对应交易日的初始快照数据，将未对应的初始快照数据存入快照数据表，以根据所有初始快照数据生成目标快照数据。

示例性地，系统还包括：读取单元307；

获取单元301，具体用于将业务数据表进行分段，获取第一子业务数据表及第二子业务数据表；

读取单元307，用于读取第一子业务数据表中的初始业务数据，并记录游标位置点；其中，游标位置点用于描述第一子业务数据表与第二子业务数据表的分段位置点；

读取单元307，还用于基于游标位置点，读取第二子业务数据表中的初始业务数据。

示例性地，系统包括：

获取单元301，具体用于当CBS系统触发针对于目标快照数据的业务变更指令时，获取增量数据；其中，增量数据为目标时间点后产生的业务数据；

同步单元304，具体用于将增量数据更新至原始业务库的原始业务表，将增量数据同步至目标业务库的业务数据表；其中，业务数据表包括对应于任一交易记录数据的初始业务数据；

确定单元306，具体用于根据业务变更指令，确定与增量数据的交易日对应的快照数据表中的初始快照数据；其中，快照数据表包括对应于初始业务数据的快照数据；

获取单元301，还用于根据增量数据对初始快照数据进行修改，获取目标快照数据。

示例性地，系统还包括：设置单元308；

设置单元308，用于将业务变更指令设置为目标执行任务，并将目标执行任务放置于待执行任务列表，以生成执行记录数据，以使得CBS系统执行根据业务变更指令，确定与增量数据的交易日对应的初始快照数据的步骤；

设置单元308，还用于当初始快照数据修改失败，且未超过预设重置次数时，将目标执行任务放置于失败任务列表；

设置单元308，还用于设置调用任务，以于预设时间段从失败任务列表中调用目标执行任务，以使得CBS系统执行根据业务变更指令，确定与增量数据的交易日对应的初始快照数据的步骤。

示例性地，系统还包括：更新单元309；

更新单元309，用于当初始快照数据修改成功时，将目标快照数据更新至快照数据表。

下面请参阅图4，本申请实施例公开的一种业务数据的处理装置的结构示意图包括：

中央处理器401，存储器405，输入输出接口404，有线或无线网络接口403以及电源402；

存储器405为短暂存储存储器或持久存储存储器；

中央处理器401配置为与存储器405通信，并执行存储器405中的指令操作以执行前述图1或图2所示实施例中的业务数据的处理方法。

本申请实施例还提供一种芯片系统，其特征在于，芯片系统包括至少一个处理器和通信接口，通信接口和至少一个处理器通过线路互联，至少一个处理器用于运行计算机程序或指令，以执行前述图1或图2所示实施例中的业务数据的处理方法。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，read-onlymemory)、随机存取存储器(RAM，random access memory)、磁碟或者光盘等各种可以存储程序代码的介质。

Claims (10)

1.一种业务数据的处理方法，其特征在于，应用于CBS系统，所述方法包括：

获取目标业务库中的所有初始业务数据；

生成对应于所述目标业务库中任一初始业务数据的初始快照数据，并将所述初始快照数据保存至所述目标业务库；其中，所述初始快照数据用于描述所述初始业务数据的版本数据；

若所述CBS系统接收所述初始业务数据的业务变更指令，根据所述业务变更指令调用所述目标业务库中的所述初始快照数据，对所述初始快照数据进行修改，获取目标快照数据。

2.根据权利要求1所述的业务数据的处理方法，其特征在于，所述获取目标业务库中的所有初始业务数据之前，所述方法还包括：

获取原始业务库的增量数据及全库数据；其中，所述增量数据为所述原始业务库于任一时间点后存储的业务数据，所述全库数据为所述原始业务库于所述任一时间点前存储的业务数据；

将所述增量数据及所述全库数据同步至所述目标业务库，以使得所述目标业务库生成所述初始业务数据；

所述获取目标快照数据之后，所述方法还包括：

将所述目标快照数据保存至所述目标业务库，以使得所述目标业务库根据所述目标快照数据、所述增量数据及所述全库数据生成目标业务数据。

3.根据权利要求1所述的业务数据的处理方法，其特征在于，所述根据所述业务变更指令调用所述目标业务库中的所述初始快照数据，对所述初始快照数据进行修改，获取目标快照数据包括：

当所述CBS系统触发末位任务时，从所述目标业务库中的业务数据表获取所有所述初始业务数据；其中，所述末位任务用于描述交易日中所有任务列表中排序为末位的任务，所述业务数据表包括对应于任一交易记录数据的初始业务数据；

根据所有所述初始业务数据，于快照数据表中确认对应于任一所述初始业务数据的所述初始快照数据；其中，所述快照数据表包括对应于所述初始业务数据的快照数据；

若存在未与所述初始业务数据对应的初始快照数据，将任一交易日中未对应的初始业务数据进行还原，获取未对应的交易记录数据；

根据所述交易记录数据生成未对应交易日的初始快照数据，将所述未对应的初始快照数据存入所述快照数据表，以根据所有所述初始快照数据生成所述目标快照数据。

4.根据权利要求3所述的业务数据的处理方法，其特征在于，所述从所述目标业务库中的业务数据表获取所有所述初始业务数据，包括：

将所述业务数据表进行分段，获取第一子业务数据表及第二子业务数据表；

读取第一子业务数据表中的所述初始业务数据，并记录游标位置点；其中，所述游标位置点用于描述所述第一子业务数据表与所述第二子业务数据表的分段位置点；

基于所述游标位置点，读取所述第二子业务数据表中的所述初始业务数据。

5.根据权利要求1所述的业务数据的处理方法，其特征在于，所述根据所述业务变更指令调用所述目标业务库中的所述初始快照数据，对所述初始快照数据进行修改，获取目标快照数据包括：

当所述CBS系统触发针对于所述目标快照数据的所述业务变更指令时，获取增量数据；其中，所述增量数据为目标时间点后产生的业务数据；

将所述增量数据更新至原始业务库的原始业务表，将所述增量数据同步至目标业务库的业务数据表；其中，所述业务数据表包括对应于任一交易记录数据的初始业务数据；

根据所述业务变更指令，确定与所述增量数据的交易日对应的快照数据表中的初始快照数据；其中，所述快照数据表包括对应于所述初始业务数据的快照数据；

根据所述增量数据对所述初始快照数据进行修改，获取所述目标快照数据。

6.根据权利要求5所述的业务数据的处理方法，其特征在于，所述根据所述业务变更指令，确定与所述增量数据的交易日对应的初始快照数据之前，所述方法还包括：

将所述业务变更指令设置为目标执行任务，并将所述目标执行任务放置于待执行任务列表，以生成执行记录数据，以使得所述CBS系统执行所述根据所述业务变更指令，确定与所述增量数据的交易日对应的初始快照数据的步骤；

所述根据所述增量数据对所述初始快照数据进行修改之后，所述方法还包括：

当所述初始快照数据修改失败，且未超过预设重置次数时，将所述目标执行任务放置于失败任务列表；

设置调用任务，以于预设时间段从所述失败任务列表中调用所述目标执行任务，以使得所述CBS系统执行所述根据所述业务变更指令，确定与所述增量数据的交易日对应的初始快照数据的步骤。

7.根据权利要求5所述的业务数据的处理方法，其特征在于，所述所述根据所述增量数据对所述初始快照数据进行修改之后，所述方法还包括：

当所述初始快照数据修改成功，将所述目标快照数据更新至所述快照数据表。

8.一种业务数据的处理系统，其特征在于，应用于CBS系统，所述系统包括：

获取单元，用于获取目标业务库中的所有初始业务数据；

生成单元，用于生成对应于所述目标业务库中任一初始业务数据的初始快照数据，并将所述初始快照数据保存至所述目标业务库；其中，所述初始快照数据用于描述所述初始业务数据的版本数据；

修改单元，用于当所述CBS系统触发所述初始业务数据的业务变更指令，根据所述业务变更指令调用所述目标业务库中的所述初始快照数据，对所述初始快照数据进行修改，获取目标快照数据。

9.一种业务数据的处理装置，其特征在于，所述装置包括：

中央处理器，存储器，输入输出接口，有线或无线网络接口以及电源；

所述存储器为短暂存储存储器或持久存储存储器；

所述中央处理器配置为与所述存储器通信，并执行所述存储器中的指令操作以执行权利要求1至7中任意一项所述的业务数据的处理方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质包括指令，当所述指令在计算机上运行时，使得计算机执行如权利要求1至7中任意一项所述的业务数据的处理方法。