CN116414810A - 业务数据核对方法、装置、存储介质和计算机程序产品 - Google Patents

Abstract

本申请涉及一种业务数据核对方法、装置、计算机设备、存储介质和计算机程序产品。所述方法包括：响应于触发的针对目标业务方的业务数据核对事件，确定从所述目标业务方接入并缓存的待核对业务数据；按照业务数据提取时间间隔，分批次从所述待核对业务数据中提取符合核对条件的目标业务数据，每一次提取的所述目标业务数据的数量不超过业务数据数量阈值；针对每一次提取的目标业务数据，按照所述目标业务数据对应的数据核对逻辑对进行数据核对，得到业务数据核对结果。通过上述方法，便于及时发现目标业务方的业务数据是否存在问题，能够较为平滑地对业务数据进行数据核对，避免在某个时间段出现大爆发的情况。

Description

业务数据核对方法、装置、存储介质和计算机程序产品

技术领域

本申请涉及计算机技术领域，特别是涉及一种业务数据核对方法、装置、计算机设备、存储介质和计算机程序产品。

背景技术

在业务数据处理过程中，不少业务对数据的准确性比较敏感，由于系统或者人为原因，会存在操作但未能生效或者误操作的业务数据，会导致数据状态并不能达到预期的目标。

然而，这种操作未生效或者误操作的业务数据难以及时排查，传统的处理方式一般都是被动地收到外部的反馈来获取信息进行相应处理，存在无法及时发现数据问题的弊端。

发明内容

基于此，有必要针对上述技术问题，提供一种能够及时发现数据问题的业务数据核对方法、装置、计算机设备、计算机可读存储介质和计算机程序产品。

第一方面，本申请提供了一种业务数据核对方法。所述方法包括：

响应于触发的针对目标业务方的业务数据核对事件，确定从所述目标业务方接入并缓存的待核对业务数据；

按照业务数据提取时间间隔，分批次从所述待核对业务数据中提取符合核对条件的目标业务数据，每一次提取的所述目标业务数据的数量不超过业务数据数量阈值；

针对每一次提取的目标业务数据，按照所述目标业务数据对应的数据核对逻辑对进行数据核对，得到业务数据核对结果。

第二方面，本申请还提供了一种业务数据核对装置。所述装置包括：

数据确定模块，用于响应于针对目标业务方的业务数据核对触发事件，确定从所述目标业务方接入并缓存的待核对业务数据；

数据提取模块，用于按照业务数据提取时间间隔，分批次从所述待核对业务数据中提取符合核对条件的目标业务数据，每一次提取的所述目标业务数据的数量不超过业务数据数量阈值；

数据核对模块，用于针对每一次提取的目标业务数据，按照所述目标业务数据对应的数据核对逻辑对进行数据核对，得到业务数据核对结果。

在其中一个实施例中，所述装置还包括重核模块；

所述重核模块，用于确定所述数据核对结果为核对逻辑错误、且已核对次数未达到核对次数阈值的待重核业务数据；当所述待重核业务数据的核对延迟时长满足核对延时条件时，将所述待重核业务数据重新确定为符合核对条件的目标业务数据。

在其中一个实施例中，所述装置还包括修复模块；

所述修复模块，用于当存在数据核对结果为核对失败的问题业务数据时，获取针对所述问题业务数据的修复逻辑；基于所述修复逻辑对所述问题业务数据进行修复，得到数据修复结果。

在其中一个实施例中，所述修复模块，还用于当所述问题业务数据的数据修复结果为修复失败、且已修复次数未达到修复次数阈值时，记录针对所述问题业务数据的修复延迟时长；当所述修复延迟时长满足修复延时条件时，重新对所述问题数据进行修复。

在其中一个实施例中，所述数据核对模块，还用于将每一次提取的目标业务数据的状态标签标记为可核对；针对所述状态标签为可核对的目标业务数据，按照所述目标业务数据对应的数据核对逻辑对进行数据核对，得到每一目标业务数据各自对应的数据核对结果；

所述数据核对模块，还用于基于所述数据核对结果，更新所述目标业务数据的状态标签；分类统计所述状态标签，得到业务数据核对结果。

在其中一个实施例中，所述数据提取模块，还用于在当前时间满足所述业务数据核对事件的定时触发条件时，触发针对目标业务方的业务数据核对事件；响应于触发的所述业务数据核对事件，启动业务数据核对进程；通过执行所述业务数据核对进程，按照业务数据提取时间间隔，分批次从所述待核对业务数据中提取符合核对条件的目标业务数据。

在其中一个实施例中，启动的业务数据核对进程的数量不少于两个；所述数据核对模块，还用于基于启动的各业务数据核对进程，对各所述业务数据核对进程各自提取的目标业务数据，分别按照所述目标业务数据对应的数据核对逻辑进行数据核对。

在其中一个实施例中，所述数据提取模块，还用于按照业务数据类别所对应的核对需求，将所述待核对业务数据分流至不同的消息队列：采用多个业务数据核对进程，从各所述消息队列中，提取出符合核对条件的目标业务数据。

在其中一个实施例中，所述装置还包括去重模块；

所述去重模块，用于获取从目标业务方接入的初始业务数据流，确定针对所述初始业务数据的数据过滤逻辑；基于所述数据过滤逻辑，对所述初始业务数据流进行数据过滤处理，得到待核对业务数据。

在其中一个实施例中，所述数据过滤逻辑包括去重逻辑和业务数据过滤逻辑；所述去重模块，还用于按照所述去重逻辑和所述业务数据过滤逻辑，对所述初始业务数据流进行双重数据过滤处理，得到待核对业务数据。

在其中一个实施例中，所述装置还包括数据反馈模块；

所述数据反馈模块，用于当所述数据核对结果中存在异常数据时，按照异常数据类型和业务数据维度中的至少一种类别，对所述异常数据进行分类；将分类后的异常数据反馈至所述目标业务方。

第三方面，本申请还提供了一种计算机设备。所述计算机设备包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现以下步骤：

响应于触发的针对目标业务方的业务数据核对事件，确定从所述目标业务方接入并缓存的待核对业务数据；

按照业务数据提取时间间隔，分批次从所述待核对业务数据中提取符合核对条件的目标业务数据，每一次提取的所述目标业务数据的数量不超过业务数据数量阈值；

针对每一次提取的目标业务数据，按照所述目标业务数据对应的数据核对逻辑对进行数据核对，得到业务数据核对结果。

第四方面，本申请还提供了一种计算机可读存储介质。所述计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现以下步骤：

响应于触发的针对目标业务方的业务数据核对事件，确定从所述目标业务方接入并缓存的待核对业务数据；

按照业务数据提取时间间隔，分批次从所述待核对业务数据中提取符合核对条件的目标业务数据，每一次提取的所述目标业务数据的数量不超过业务数据数量阈值；

针对每一次提取的目标业务数据，按照所述目标业务数据对应的数据核对逻辑对进行数据核对，得到业务数据核对结果。

第五方面，本申请还提供了一种计算机程序产品。所述计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现以下步骤：

响应于触发的针对目标业务方的业务数据核对事件，确定从所述目标业务方接入并缓存的待核对业务数据；

按照业务数据提取时间间隔，分批次从所述待核对业务数据中提取符合核对条件的目标业务数据，每一次提取的所述目标业务数据的数量不超过业务数据数量阈值；

针对每一次提取的目标业务数据，按照所述目标业务数据对应的数据核对逻辑对进行数据核对，得到业务数据核对结果。

上述业务数据核对方法、装置、计算机设备、存储介质和计算机程序产品，通过在针对目标业务方的业务数据核对事件触发之前，实现对从目标业务方接入的待核对业务数据的缓存，便于进行数据核对，通过响应于触发的针对目标业务方的业务数据核对事件，确定从目标业务方接入并缓存的待核对业务数据，通过事件的触发来实现对缓存业务数据的核对，有效控制核对过程的触发时机，在核对过程中，通过按照业务数据提取时间间隔，分批次从待核对业务数据中提取符合核对条件的目标业务数据，每一次提取的目标业务数据的数量不超过业务数据数量阈值，针对每一次提取的目标业务数据，按照目标业务数据对应的数据核对逻辑对进行数据核对，得到业务数据核对结果，能够使业务数据较为平滑地进行数据核对，避免在某个时间段出现大爆发的情况，通过触发对目标业务方的业务数据事件进行核对，便于及时发现目标业务方的业务数据是否存在问题。

附图说明

图1为一个实施例中业务数据核对方法的应用环境图；

图2为一个实施例中业务数据核对方法的流程示意图；

图3为一个实施例中业务数据核对进程和消息队列的连接方式示意图；

图4为一个实施例中反馈给业务方的曲线图的示意图；

图5为一个实施例中异常页数数据的显示界面示意图；

图6为另一个实施例中业务数据核对方法的流程示意图；

图7为一个实施例中业务数据核对流程的示意图；

图8为一个实施例中业务数据核对系统的数据处理流程示意图；

图9为一个实施例中调度模块的数据处理流程示意图；

图10为一个实施例中数据核对模块的数据处理流程示意图；

图11为一个实施例中业务数据核对装置的结构框图；

图12为一个实施例中计算机设备的内部结构图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

本申请实施例提供的业务数据核对方法，可以应用于如图1所示的应用环境中。其中，终端102通过网络与服务器104进行通信。数据存储系统可以存储服务器104需要处理的数据。数据存储系统可以集成在服务器104上，也可以放在云上或其他网络服务器上。其中，数据存储系统可以采用分布式数据存储系统。具体地，业务方可以通过终端102对数据核对策略进行配置，并将配置数据提交至服务器104，在服务器104中搭建有针对不同业务方可适应的数据核对系统，以便接入不同业务方的业务数据并进行数据核对。

在一个具体的应用中，服务器104响应于触发的针对目标业务方的业务数据核对事件，确定从目标业务方接入并缓存的待核对业务数据，按照业务数据提取时间间隔，分批次从待核对业务数据中提取符合核对条件的目标业务数据，每一次提取的目标业务数据的数量不超过业务数据数量阈值，针对每一次提取的目标业务数据，按照目标业务数据对应的数据核对逻辑对进行数据核对，得到业务数据核对结果，并将核对结果反馈至目标业务方所在的终端102。

其中，终端102可以但不限于是各种个人计算机、笔记本电脑、智能手机、平板电脑、物联网设备和便携式可穿戴设备，物联网设备可为智能音箱、智能电视、智能空调、智能车载设备等。便携式可穿戴设备可为智能手表、智能手环、头戴设备等。服务器104可以用独立的服务器或者是多个服务器组成的服务器集群来实现。

在一个实施例中，如图2所示，提供了一种业务数据核对方法，以该方法应用于图1中的服务器为例进行说明，包括以下步骤：

步骤202，响应于触发的针对目标业务方的业务数据核对事件，确定从目标业务方接入并缓存的待核对业务数据。

其中，业务数据核对事件是表征启动业务数据核对处理过程的事件。当服务器检测到业务数据核对事件被触发时，会执行与业务数据核对事件对应的数据处理程序，以实现数据核对处理。业务数据核对事件可以与业务方相匹配，不同的业务方所匹配的业务数据核对事件为不同的事件。目标业务方可以通过触发的业务数据核对事件、以及业务数据核对事件与业务方的关系来确定。例如业务方A所匹配的业务数据核对事件为事件A、业务方B所匹配的业务数据核对事件为事件B、业务方C所匹配的业务数据核对事件为事件C，当触发的业务数据核对事件为事件B时，则触发的是针对业务方B所接入待核对业务数据的核对处理过程。

业务数据核对事件可以基于不同的条件进行触发，以便实现实时或定时的业务数据核对。例如，业务方想要实时对业务数据进行核对时，可以将业务数据核对事件的触发条件配置为侦测到业务方有业务数据的接入时进行触发，再例如，业务方想要定时对业务数据进行核对时，可以将业务数据核对事件的触发条件配置为在某一个具体的时间点进行触发，如每天上午九点、下午五点等。

待核对业务数据是指需要进行数据核对以判断是否存在问题的业务数据，业务数据由目标业务方提供，服务器通过与业务方的业务系统建立连接，接入业务系统中所产生的业务数据。业务数据具体可以是业务方所对应用户的操作数据，通过数据核对判断用户操作是否生效或者操作是否符合属于正常操作，也可以是业务方产生的核对数据，通过数据核对判断账目是否正确等。

缓存是指将从目标业务方接入的待核对业务数据存储到服务器指定的数据库的数据处理过程。具体地，服务器针对不同的业务方，可以将其接入的待核对业务数据存储在相同的数据库，便于统一管理，也可以将不同的业务方的待核对业务数据缓存至不同的数据库，针对不同的业务方实现资源隔离，提高数据的安全性。通过对待核对业务数据进行缓存，能够便于后续在数据核对过程中，实现对数据的平缓核对处理，避免在某个时间段出现数据大爆发的情况造成系统宕机等故障。

具体地，服务器针对每一建立有连接关系的业务方，分别接入各业务方对应的待核对业务数据并缓存至数据库，服务器通过响应于触发的针对目标业务方的业务数据核对事件，基于业务数据核对事件所对应的目标业务方，确定从目标业务方接入并缓存的待核对业务数据，启动针对待核对业务数据的数据核对流程。

在一个具体的应用中，服务器所提供的数据核对系统针对公共逻辑进行了整合封装，使得业务方与数据核对系统的接入过程简单化，业务方在将业务数据导入至服务器时，通过map的形式进行业务数据接入，简化了数据接入过程，且业务数据的接入不会对业务方的业务系统产生影响。其中，业务数据的接入可以通过服务器本地的消息队列来异步接入，使得业务方可以无影响地将待核对业务数据旁路到消息队列中，通过消息队列实现待核对业务数据的平缓接入，避免对系统的稳定性造成影响。服务器通过侦听并响应的业务数据核对事件的触发，基于业务数据核对事件所对应的目标业务方，从数据库中查找从目标业务方接入并缓存的待核对业务数据，启动针对待核对业务数据的数据核对流程。

步骤204，按照业务数据提取时间间隔，分批次从待核对业务数据中提取符合核对条件的目标业务数据，每一次提取的目标业务数据的数量不超过业务数据数量阈值。

其中，业务数据提取时间间隔是指连续两次从待核对业务数据中提取目标业务数据的时间差值。业务数据提取时间间隔的取值可以是系统默认值，也可以是基于实际的应用场景由业务方自行配置的数值。业务数据提取时间间隔可以基于服务器核对一批次的目标业务数据所需的时间来设定，以确保在业务数据提取时间间隔内，可以完成对一批次的目标业务数据的数据核对。在一个具体应用中，业务数据提取时间间隔的取值为1s，即服务器每隔1s从待核对业务数据中提取目标业务数据。

核对条件是待核对业务数据进行数据核对之前所需要满足的条件，例如满足数据状态条件，如数据状态为未核对或是待重核等，再例如满足核对时间条件，如延迟时间达到核对时间条件等。分批次提取是指每一次从待核对业务数据中提取一部分的目标业务数据，且每次提取的目标业务数据不重复的数据处理操作。

业务数据数量阈值是指每一次从待核对业务数据中所提取目标业务数据的数量最大值。当待核对业务数据中可提取的目标业务数据大于业务数据数量阈值时，服务器会从待核对业务数据中提取数量为业务数据数量阈值的目标业务数据，剩余的目标业务数据在下一批次进行提取，以确保每次提取的目标业务数据的数量不会过多，实现针对业务数据的平缓核对。当待核对业务数据中可提取的目标业务数据小于或等于业务数据数量阈值时，服务器可以提取全部的目标业务数据进行数据核对处理。

具体地，服务器进行目标业务数据提取所采用的是滑动窗口的思想，由于滑动窗口的窗口大小是固定的，通过按照固定的时间间隔对滑动窗口进行滑动，可以实现针对目标业务数据的频控处理，其中，频控是指通过限制单位时间内可访问的次数，达到限流的目的。利用频控可以用来限制访问某些服务接口的流量，防止服务器由于承受太大的访问量而崩溃。在具体应用中，服务器在进行目标业务数据提取之前，可以先获取提取过程对应的提取配置数据，提取配置数据包括业务数据提取时间间隔、业务数据数量阈值以及目标业务数据所需满足的核对条件，服务器按照业务数据提取时间间隔，分批次从待核对业务数据中提取符合核对条件的目标业务数据，每一次提取的目标业务数据的数量不超过业务数据数量阈值，从而防止服务过载。

步骤206，针对每一次提取的目标业务数据，按照目标业务数据对应的数据核对逻辑对进行数据核对，得到业务数据核对结果。

其中，数据核对逻辑是用于对业务数据进行核对的核对原则，数据核对逻辑可以由提供待核对业务数据的目标业务方进行配置，不同的业务方可以基于自身需核对的业务数据，配置不同的数据核对逻辑。数据核对逻辑与业务数据之间存在匹配关系，当同一业务方所需核对的待核对业务数据的种类为多种时，所配置的数据核对逻辑的种类也是多种的，服务器可以基于业务数据与数据核对逻辑之间的匹配关系，确定目标业务数据所对应的数据核对逻辑进行数据核对。业务数据核对结果可以是每一个目标业务数据各自对应的数据核对结果，也可以各个已核对的目标业务数据的统计结果。

具体地，服务器针对每一次提取的目标业务数据，按照目标业务数据对应的提取批次顺序，依次进行数据核对，对于先提取的目标业务数据先进行数据核对，对于后提取的目标业务数据后进行数据核对，具体可以是每提取一批次的目标业务数据进行一次处理。在具体的实现中，业务数据提取时间间隔可以基于服务器核对一批次的目标业务数据所需的时间相对应，以确保提取下一批次的目标业务数据之前，可以完成对上一批次的目标业务数据的数据核对，避免数据的堆积。服务器在获取到每一批次的目标业务数据对应的数据核对结果时，可以实时地将该批次的数据核对结果反馈至目标业务方，以使目标业务方了解到当前已核对数据中是否存在错误数据，便于及时进行相应的处理。服务器也可以在数据核对任务结束时，汇总全部的数据核对结果，并将汇总结果反馈至目标业务方，以便目标业务方了解到已核对数据的总体核对情况。

上述业务数据核对方法，通过在针对目标业务方的业务数据核对事件触发之前，实现对从目标业务方接入的待核对业务数据的缓存，便于进行数据核对，通过响应于触发的针对目标业务方的业务数据核对事件，确定从目标业务方接入并缓存的待核对业务数据，通过事件的触发来实现对缓存业务数据的核对，有效控制核对过程的触发时机，在核对过程中，通过按照业务数据提取时间间隔，分批次从待核对业务数据中提取符合核对条件的目标业务数据，每一次提取的目标业务数据的数量不超过业务数据数量阈值，针对每一次提取的目标业务数据，按照目标业务数据对应的数据核对逻辑对进行数据核对，得到业务数据核对结果，能够使业务数据较为平滑地进行数据核对，避免在某个时间段出现大爆发的情况，通过触发对目标业务方的业务数据事件进行核对，便于及时发现目标业务方的业务数据是否存在问题。

在一个实施例中，方法还包括：确定数据核对结果为核对逻辑错误、且已核对次数未达到核对次数阈值的待重核业务数据；当待重核业务数据的核对延迟时长满足核对延时条件时，将待重核业务数据重新确定为符合核对条件的目标业务数据。

其中，数据核对结果包括三种情况，分别是核对成功、核对失败以及核对逻辑错误。其中，核对成功是指目标业务数据满足数据核对逻辑，核对失败是指目标业务数据不满足数据核对逻辑，核对逻辑错误包括数据核对逻辑本身存在问题，例如数据核对逻辑配置错误、数据核对逻辑与业务数据不匹配等。当数据核对结果为核对成功时，数据核对结果为核对成功的提示信息，当数据核对结果为核对失败时，数据核对结果为核对失败的提示信息，如核对成功为1，核对失败为0，如核对成功为true，核对失败为false。当数据核对结果为核对逻辑错误时，数据核对结果可以为空值或是其他设定的提示信息(如404)等特定的表现形式。服务器可以通过数据核对结果的数据形式，确定数据核对结果具体为核对成功、核对失败还是核对逻辑错误。

核对次数是针对未得到核对成功还是核对失败的核对结果的业务数据进行的次数标识。服务器针对核对逻辑错误的业务数据需要进行重新核对，以避免出现对业务数据的遗漏，但业务数据的核对不能无止境地一直执行，因此需要设定核对次数阈值，对核对逻辑错误的业务数据进行重复核对，直至得到核对成功或核对失败的数据核对结果，或是核对次数达到核对次数阈值。

核对延时时长是指当前时间距离得到上一次核对结果的时间间隔，核对延时条件是指核对延时时长所需满足的条件。核对延时条件的具体时长可以由业务方根据实际的业务需要进行配置，也可以是系统默认值。

具体地，服务器基于数据核对结果的数据形式，识别出数据核对结果为核对逻辑错误的业务数据，并获取该业务数据已核对次数；当已核对次数未达到核对次数阈值时，将该业务数据确定为待重核业务数据，并记录该待重核业务数据的核对延迟时长，当核对延迟时长满足核对延时条件时，将待重核业务数据重新确定为符合核对条件的目标业务数据，重新进行数据核对，当重新进行的数据核对的结果为核对成功或核对失败时，结束针对该业务数据的核对，当重新进行的数据核对的结果还是为核对逻辑错误时，将该业务数据的已核对次数+1，得到更新的已核对次数，并将更新的已核对次数与核对次数阈值进行比较，若更新的已核对次数达到核对次数阈值，则结束针对该业务数据的核对，输出逻辑错误的数据核对结果。

在一个具体的应用中，业务方设定的核对延时条件为10s，核对次数阈值为10次。服务器识别出数据核对结果为核对逻辑错误的业务数据，并获取该业务数据已核对次数；当已核对次数未达到10次时，记录该待重核业务数据的核对延迟时长，当核对延迟时长达到10s时，重新对该业务数据进行数据核对。

在本实施例中，通过对存在核对逻辑错误的情况进行重复核对，避免出现对业务数据核对的遗漏，提高数据核对结果的准确性，针对核对逻辑错误进行延时数据核对，避免抢占其他正常待核对业务数据的核对资源，提高整体的数据核对运行效率。

在一个实施例中，方法还包括：当存在数据核对结果为核对失败的问题业务数据时，获取针对问题业务数据的修复逻辑；基于修复逻辑对问题业务数据进行修复，得到数据修复结果。

其中，核对失败是指目标业务数据不满足数据核对逻辑时对应的数据核对结果。当数据核对结果为核对失败时，表征该业务数据为存在问题的问题业务数据。服务器针对问题业务数据，可以进行修复处理。修复逻辑是指针对业务数据配置的修复处理方式，修复逻辑可以由业务方进行配置。

具体地，服务器基于数据核对结果的数据形式，识别出数据核对结果为核对失败的问题业务数据，查找是否存在针对该问题业务数据的修复逻辑，若不存在，则反馈核对失败的消息至目标业务方，若存在，则调用针对该问题业务数据的修复逻辑所对应的业务接口，由该业务接口对该问题业务数据进行修复，并反馈针对该问题业务数据的数据修复结果至服务器。服务器将该问题业务数据对应的数据核对结果即核对失败，以及数据修复结果反馈至目标业务方。因此，目标业务方针对问题业务数据，所接收到的反馈数据包括三种情况，第一种是核对失败，第二种是核对失败且修复成功，第三种是核对失败且修复失败，以便业务方准确地了解在针对该问题业务数据已经进行的处理以及处理结果，便于业务方进行下一步的数据处理。

在本实施例中，服务器通过对核对失败的问题业务数据按照修复逻辑进行修复处理，能够提高针对业务数据的错误修改能力，提高业务系统的可靠性。

在一个实施例中，方法还包括：当问题业务数据的数据修复结果为修复失败、且已修复次数未达到修复次数阈值时，记录针对问题业务数据的修复延迟时长；当修复延迟时长满足修复延时条件时，重新对问题数据进行修复。

其中，修复失败是指修复后的结果仍存在问题的修复结果，修复次数是针对修复失败的问题业务数据进行的次数标识。服务器针对修复失败的问题业务数据需要进行重新修复，以尽可能使得对问题业务数据能够修复成功，但针对问题业务数据的修复也不能无止境地一直执行，因此需要设定修复次数阈值，对修复失败的问题业务数据进行重新修复，直至得到修复成功的数据修复结果，或是修复次数达到修复次数阈值。

修复延时时长是指当前时间距离得到上一次修复结果的时间间隔，修复延时条件是指修复延时时长所需满足的条件。修复延时条件的具体时长可以由业务方根据实际的业务需要进行配置，也可以是系统默认值。

具体地，服务器基于识别出数据核对结果为核对失败的问题业务数据，对该问题业务数据进行修复处理，当修复结果为修复失败时，将该问题业务数据已修复次数标记为1；当已修复次数未达到修复次数阈值时，记录该问题业务数据的修复延迟时长，当修复延迟时长满足修复延时条件时，重新进行数据修复，当重新进行的数据修复的结果为修复成功时，结束针对该问题业务数据的修复，当重新进行的数据修复的结果还是为修复失败时，将该问题业务数据的已修复次数+1，得到更新的已修复次数，并将更新的已修复次数与修复次数阈值进行比较，若更新的已修复次数达到修复次数阈值，则结束针对该问题业务数据的修复，输出修复失败的数据修复结果。

在一个具体的应用中，业务方设定的修复延时条件为8s，修复次数阈值为8次。服务器识别出核对结果为核对失败的问题业务数据，对该问题业务数据进行修复处理，当修复结果为修复失败时，将该问题业务数据已修复次数标记为1，记录该问题业务数据的修复延迟时长，当修复延迟时长达到8s时，重新对该问题业务数据进行数据修复，直至已修复次数达到8次或修复结果为修复成功。

在本实施例中，通过对存在核对错误的问题业务数据进行修复，能够提高对业务数据的自动修复能力，提高业务系统的可靠性，针对修复失败的问题业务数据进行延时修复，实现数据的平缓处理，避免数据处理量的突增。

在一个实施例中，针对每一次提取的目标业务数据，按照目标业务数据对应的数据核对逻辑对进行数据核对，得到业务数据核对结果，包括：将每一次提取的目标业务数据的状态标签标记为可核对；针对状态标签为可核对的目标业务数据，按照目标业务数据对应的数据核对逻辑对进行数据核对，得到每一目标业务数据各自对应的数据核对结果；基于数据核对结果，更新目标业务数据的状态标签；分类统计状态标签，得到业务数据核对结果。

其中，状态标签用于表征业务数据的数据处理状态，状态标签可以包括待核对、可核对、核对成功、核对失败、待重核、修复成功以及修复失败等内容中的一种，在不同的数据处理阶段对应不同的状态标签。服务器通过将业务数据提取出来，会将提取的目标业务数据的状态标签由待核对修改为可核对，或是将未携带任何状态标签的目标业务数据打上可核对的状态标签。

具体地，服务器将提取的目标业务数据的状态标签标记为可核对，在核对开始之前，服务器可以先读取数据核对的配置来判断是否启停针对该目标业务数据的数据核对，是否延迟对该目标业务数据的数据核对，从而通过配置灵活地对数据核对任务进行调度。服务器对状态标签为可核对的目标业务数据，按照目标业务数据对应的数据核对逻辑对进行数据核对，得到每一目标业务数据各自对应的数据核对结果，基于数据核对结果如核对成功、核对失败、核对逻辑错误，对目标业务数据的状态标签进行更新。

当数据核对结果为核对成功时，将目标业务数据的状态标签更新为核对成功，当数据核对结果为核对失败时，将目标业务数据的状态标签更新为核对失败，当数据核对结果为核对逻辑错误时，将目标业务数据的状态标签更新为待重核。通过分类统计已核对目标业务数据的状态标签，得到业务数据核对结果，并将核对结果反馈至目标业务方。

在本实施例中，通过给业务数据打上状态标签，并根据每一阶段的数据处理结果对状态标签进行更新，能够针对业务数据准确的执行下一步的处理，避免针对同一数据的重复操作，提高数据处理结果的准确性和数据处理效率。

在一个实施例中，按照业务数据提取时间间隔，分批次从待核对业务数据中提取符合核对条件的目标业务数据，包括：在当前时间满足业务数据核对事件的定时触发条件时，触发针对目标业务方的业务数据核对事件；响应于触发的针对目标业务方的业务数据核对事件，启动业务数据核对进程；通过执行业务数据核对进程，按照业务数据提取时间间隔，分批次从待核对业务数据中提取符合核对条件的目标业务数据。

其中，定时触发条件是指预先配置的定时触发业务数据核对事件的时间条件。定时触发条件可以是系统默认的时间，也可以是由业务方根据实际场景需要进行设定的时间。定时触发时间包括触发周期和触发时间点，例如每天上午九点和下午五点，再例如每周一上午九点等。

业务数据核对进程是指用于执行业务数据核对处理过程的数据处理流程，一个业务数据核对进程可以对应提取的一批次或多批次的目标业务数据的处理。例如当一个业务数据核对进程处理完当前批次的目标业务数据的核对，继续执行下一批次的目标业务数据的核对。再例如，不同批次的目标业务数据可以通过不同的数据处理进程来实现，使得不同批次的目标业务数据的处理互不干扰，从而降低对进程数据处理能力的依赖程度。

具体地，服务器在侦测到当前时间满足定时触发条件时，触发针对目标业务方的业务数据核对事件，通过响应于触发的业务数据核对事件，启动业务数据核对进程，服务器通过执行业务数据核对进程，基于滑动窗口的思想，按照业务数据提取时间间隔，依次从待核对业务数据中提取符合核对条件的目标业务数据进行数据核对处理。

在本实施例中，服务器通过设定的定时触发条件，定时触发针对目标业务方的业务数据核对事件，能够实现在指定时间启动对目标业务方的数据核对处理过程，对于业务数据产生时间较为集中的业务方，如白天业务数据较多，夜晚业务数据较少，则只在白天启动业务数据核对进程，能够更合理有效地实现对业务数据的核对，且服务器通过对接入的待核对业务数据进行缓存处理，不会造成数据核对的遗漏，能够确保数据核对的全面完整性，同时实现数据处理资源的合理利用。

在其中一个实施例中，启动的业务数据核对进程的数量不少于两个。针对每一次提取的目标业务数据，按照目标业务数据对应的数据核对逻辑对进行数据核对，包括：基于启动的各业务数据核对进程，对各业务数据核对进程各自提取的目标业务数据，分别按照目标业务数据对应的数据核对逻辑进行数据核对。

其中，启动的业务数据核对进程的数量可以基于配置数据来确定，配置数据可以是系统默认的配置数据，也可以是业务方根据实际场景需要进行配置的数据。一般来说，当业务方所涉及的场景或子场景的数量越多，所需核对的业务数据的量级越大，则可以配置越多的业务数据核对进程数量来提高数据核对效率。不同的数据处理进程可以分别提取不同批次的目标业务数据，实现多进程的同步处理。

进一步地，可以是不同数据处理进程需要遵循业务数据提取时间间隔，以确保整个处理过程的数据处理资源的合理分配，也可以是同一数据处理进程需要遵循业务数据提取时间间隔，不同数据处理进程可以同时获取目标业务数据，提高数据处理效率。

具体地，服务器在侦测到当前时间满足定时触发条件时，触发针对目标业务方的业务数据核对事件，通过响应于触发的业务数据核对事件，启动至少两个业务数据核对进程，基于启动的各业务数据核对进程，对各业务数据核对进程各自提取的目标业务数据，分别按照目标业务数据对应的数据核对逻辑进行数据核对，提高数据核对效率。

在本实施例中，服务器通过启动多个业务数据核对进程，不同的数据处理进程可以分别提取不同批次的目标业务数据，实现多进程的同步处理，有效提高数据核对效率。

在一个实施例中，从待核对业务数据中提取符合核对条件的目标业务数据，包括：按照业务数据类别所对应的核对需求，将待核对业务数据分流至不同的消息队列：从各消息队列中，提取出符合核对条件的目标业务数据。

其中，消息队列是用于对待核对业务数据进行传输的载体，通过多个消息队列，能够实现对待核对业务数据的分流。在具体的应用中，由于不同的业务场景可能会存在不同量级的数据，为了避免大流量业务数据的积压影响小流量业务数据的数据核对无法触发，通过预备多个消息队列进行数据的传输，从而兼顾不同量级的业务数据的核对处理。针对消息队列的数量配置，可以通过写入线上配置的形式，使业务放能够自定义消息队列的数量以及消息队列与不同业务场景下业务数据的对应关系，将业务数据接入对应地消息队列中，例如将大流量的业务场景下的业务数据写入单独的一个消息队列，将多个小流量的业务场景下的业务数据写入一个消息队列，减少大量任务堆积的情况发生。

进一步地，从各消息队列中，提取出符合核对条件的目标业务数据，包括：采用多个业务数据核对进程，从各消息队列中，提取出符合核对条件的目标业务数据。

为了能尽可能利用业务数据核对进程的性能，避免消息队列中目标业务数据的积压，这里使用了分离式消息队列，即业务数据核对进程和消息队列是独立的两个模块，如图3所示，业务数据核对进程和消息队列采用的是多对多的连接方式，业务数据核对进程可以去任意一个消息队列中拉取目标业务数据，相较于业务数据核对进程和消息队列一对一的好处就是能尽量使用业务数据核对进程的资源，防止消息队列出现积压的情况。

具体地，服务器基于业务方按照业务数据类别所配置的核对需求，确定业务数据与消息队列的对应关系，将待核对业务数据按所属的场景和量级分流至不同的消息队列，采用多个业务数据核对进程，基于多对多的连接方式，从各消息队列中提取出符合核对条件的目标业务数据进行数据核对处理。

在本实施例中，通过采用多对多的连接方式，连接业务数据核对进程和消息队列，使得业务数据核对进程可以去任意一个消息队列中拉取目标业务数据，能够有效提高使用业务数据核对进程的资源利用率，防止消息队列出现目标业务数据积压的情况出现。

在一个实施例中，方法还包括：获取从目标业务方接入的初始业务数据流，确定针对初始业务数据的数据过滤逻辑；基于数据过滤逻辑，对初始业务数据流进行数据过滤处理，得到待核对业务数据。

其中，初始业务数据流是指由目标业务方的业务系统产生并直接接入的未经任何处理的业务数据。数据过滤逻辑是对初始业务数据流中的业务数据进行数据过滤的数据处理方式，数据过滤逻辑可以是系统配置的默认处理逻辑，也可以是业务方根据实际场景需要配置的处理逻辑。服务器基于数据过滤逻辑，对初始业务数据流进行数据过滤处理，能够有效去除掉不需要进行数据核对的数据，提高数据核对过程的针对性和高效性。

具体地，服务器在获取从目标业务方接入的初始业务数据流时，确定针对初始业务数据的数据过滤逻辑，当数据过滤逻辑为一项时，可以直接基于该数据过滤逻辑进行数据过滤处理，丢弃不符合条件的业务数据，当数据过滤逻辑为多项时，确定多项数据过滤逻辑是否有限定过滤顺序，若有，则按照过滤顺序依次对业务数据进行数据过滤，若无，则按照任意顺序对业务数据进行数据过滤，从而得到待核对业务数据。

在本实施例中，服务器通过从目标业务方接入初始业务数据流，确定针对初始业务数据的数据过滤逻辑，对初始业务数据流进行数据过滤处理，能够有效去除掉不需要进行数据核对的数据，得到待核对业务数据，提高数据核对过程的针对性和高效性。

在一个实施例中，确定针对初始业务数据的数据过滤逻辑，包括：基于初始业务数据流所属的目标业务方，获取由目标业务方配置的业务数据过滤逻辑。基于数据过滤逻辑，对初始业务数据流进行数据过滤处理，得到待核对业务数据，包括：按照业务数据过滤逻辑和去重逻辑，对初始业务数据流进行双重数据过滤处理，得到待核对业务数据。

其中，业务数据过滤逻辑是指与业务数据相匹配的数据过滤逻辑，不同的业务对应的不同业务数据过滤逻辑。业务数据过滤逻辑具体可以由初始业务数据流所属的目标业务方来配置。具体地，同一目标业务方可以在不同时期可以配置不同的业务数据过滤逻辑，例如，在业务方在业务发行的不同阶段具有不同的重点关注对象，因此，可以基于需要关注的业务数据的重要程度，对业务数据过滤逻辑进行相应的配置。

去重逻辑是系统默认的数据过滤逻辑，保证业务数据的索引唯一性，针对具有相同索引标识的业务数据，即相同的业务数据进行去重，避免对业务数据的重复处理。

具体地，当服务器在获取从目标业务方接入的初始业务数据流时，确定针对初始业务数据的业务数据过滤逻辑和去重逻辑，基于业务数据过滤逻辑和去重逻辑进行双重数据过滤处理，具体可以是先按照去重逻辑进行数据过滤处理，在按照业务数据过滤逻辑对去重后的业务数据进行数据过滤处理，在其他应用中，也可以按照任意顺序对业务数据进行双重数据过滤处理，得到更为准确的待核对业务数据。

在本实施例中，服务器通过从目标业务方接入初始业务数据流，确定针对初始业务数据的业务数据过滤逻辑和去重逻辑，对初始业务数据流进行双重数据过滤处理，能够兼顾业务场景需要，有效去除掉不需要进行数据核对的数据，提高待核对业务数据的针对性和准确性。

在一个实施例中，方法还包括：当数据核对结果中存在异常数据时，按照异常数据类型和业务数据维度中的至少一种类别，对异常数据进行分类；将分类后的异常数据反馈至目标业务方。

其中，异常数据是指除核对结果为核对成功以外的情况对应的业务数据，异常数据类型具体包括核对逻辑失败的业务数据，核对失败的业务数据，核对失败且修复失败的业务数据，以及核对失败且修复成功的业务数据。业务数据维度是指业务数据所对应的各个数据维度。例如，业务数据维度可以包括业务标识、场景、子场景、以及其他的自定义字段，如操作人、来源场景等。其中，通过自定义字段，能够方便业务方聚类统计问题，针对自定义字段的数量，还可以设定数量上限，避免出现过多的数据维度导致反馈的结果过于分散，无法突出重点。

具体地，服务器可以基于异常数据类型对异常数据进行分类，将分类后的异常数据及其对应的统计结果反馈至目标业务方，也可以基于业务数据维度对异常数据进行分类，将分类后的异常数据及其对应的统计结果反馈至目标业务方，还可以同时基于异常数据类型和业务数据维度对异常数据进行分类，将分类后的异常数据及其对应的统计结果反馈至目标业务方。在一个具体的应用中，服务器可以对每个数据核对流转的环节进行数据检测，可以由业务方自由配置针对异常数据的提示触发条件，方便业务方及时感知出现的异常数据。

在一个具体的应用中，如图4所示，服务器针对每一个已核对的目标业务数据的数据核对结果进行统计，并将统计结果通过曲线图的方式实时反馈至业务方，例如，服务器反馈给业务方的曲线图可以包括核对结果失败、核对结果成功、核对失败且已修复。此外，服务器反馈给业务方的曲线图还可以包括业务数据提取开始、业务数据提取失败、核对任务创建等。

服务器会将核对失败的问题业务数据反馈至业务方，便于业务方进一步查询相应的原因进行相应的处理。如图5所示，在业务方的显示界面中，可以显示每一条核对失败的业务数据消息，每一条核对失败的业务数据消息具体包括问题业务数据对应的链接、业务标识、业务类型等，业务方可以通过点击触发问题业务数据对应的链接，查看具体的问题业务数据。其中，针对每一条核对失败的业务数据消息，还可以通过触发该条业务数据消息对应的展开按钮，展开显示具体的业务信息。

在一个具体的应用中，如图6所示，还提供了一种业务数据核对方法，包括以下步骤：

步骤602，获取从目标业务方接入的初始业务数据流，确定针对初始业务数据的去重逻辑以及业务数据过滤逻辑。

步骤604，按照去重逻辑和业务数据过滤逻辑，对初始业务数据流进行双重数据过滤处理，得到待核对业务数据。

步骤606，响应于触发的针对目标业务方的业务数据核对事件，确定从目标业务方接入并缓存的待核对业务数据。

步骤608，在当前时间满足业务数据核对事件的定时触发条件时，触发针对目标业务方的业务数据核对事件。

步骤610，响应于触发的业务数据核对事件，启动至少两个业务数据核对进程。

步骤612，按照业务数据类别所对应的核对需求，将待核对业务数据分流至不同的消息队列。

步骤614，采用多个业务数据核对进程，从各消息队列中，提取出数量不超过业务数据数量阈值的符合核对条件的目标业务数据。

步骤616，对各业务数据核对进程各自提取的目标业务数据，分别按照目标业务数据对应的数据核对逻辑进行数据核对。

步骤618，将每一次提取的目标业务数据的状态标签标记为可核对。

步骤620，针对状态标签为可核对的目标业务数据，按照目标业务数据对应的数据核对逻辑对进行数据核对，得到每一目标业务数据各自对应的数据核对结果。

步骤622，基于数据核对结果，更新目标业务数据的状态标签。

步骤624，确定数据核对结果为核对逻辑错误、且已核对次数未达到核对次数阈值的待重核业务数据。

步骤626，当待重核业务数据的核对延迟时长满足核对延时条件时，将待重核业务数据重新确定为符合核对条件的目标业务数据添加至消息队列，返回步骤614。

步骤628，当存在数据核对结果为核对失败的问题业务数据时，获取针对问题业务数据的修复逻辑。

步骤630，基于修复逻辑对问题业务数据进行修复，得到数据修复结果。

步骤632，当问题业务数据的数据修复结果为修复失败、且已修复次数未达到修复次数阈值时，记录针对问题业务数据的修复延迟时长。

步骤634，当修复延迟时长满足修复延时条件时，重新对问题数据进行修复。

步骤636，按照数据处理流程和业务数据维度中的至少一种类别，对业务数据进行分类，将分类后的业务数据统计结果反馈至目标业务方。

本申请还提供一种应用场景，该应用场景应用上述的业务数据核对方法。

具体地，该业务数据核对方法在该应用场景的应用如下：

随着小程序和公众号的被越来越多的用户使用推广，小程序和公众号相关运营业务责任日益重大，准确性和合理性日益重要。在日常的工作中，不少业务对数据的准确性比较敏感，由于系统或者人为原因，会存在操作但未能生效或者误操作的数据，会导致数据状态并不能达到我们预期的目标，这种情况又比较难以及时排查，总是被动地收到外部的反馈才知道，会导致平台面临信任度下降的尴尬风险，因此需要一个实时或者延时数据核对系统来及时发现数据问题并进行修复。而现有技术中，每次一个需要数据核对的业务，都需要根据业务的具体需求定制化一个数据核对系统，包含大量的重复实现逻辑，开发效率较低，而且不容易统一维护管理，且每个业务都需要搭建自己的数据核对和提示触发体系，运营成本较高。

本申请所提供的业务数据核对方法，可以对公共逻辑进行整合封装，针对不同的业务方，由业务方对其待核对的业务数据所需参数进行个性化的配置。如图7所示，通过业务数据核对系统提供由配置页面，当接入一个新业务，只需要在针对该新业务的配置页面上进行简单的配置操作，如数据核对策略、数据核对逻辑、数据修复逻辑以及反馈数据统计方式等。其中，数据核对策略包括触发定时、重试延时以及数据过滤逻辑等。反馈数据统计方式包括显示报表、详情等相关统计方式的配置。通过配置页面的配置操作，能够快速地配置出一个业务需要的数据核对工具，如自动进行数据核对、进行数据上报以及向业务方发送提示信息等配置。

在具体的实现过程中，通过建立业务数据核对系统与业务方对应的业务系统的连接，在数据导入阶段，只需要业务系统以map的形式把业务系统的操作流水旁路一份到业务数据核对系统即可。业务数据核对系统的数据核对模块，通过数据收集对从业务系统接入的业务数据缓存至数据库，在数据库中同时还存储有业务方的离线出库数据，例如前一天缓存的未核对的业务数据，在数据库中包括常用数据池，用于存储如全量公众号和小程序等进行数据核对所需的常用数据，便于针对不同的业务方进行相应的业务数据核对处理。其中，全量公众号和小程序的相关数据是静态存储的，一般不会发生变化，而从业务系统实时接入的待核对业务数据是动态存储的，当核对结束时，数据库可以释放存储的业务数据，为其他待核对业务数据的缓存提供数据存储空间。

数据核对模块基于业务方配置的数据核对策略，触发对存储的待核对业务数据的数据核对进程，并基于系统设定的频控参数，即业务数据数量阈值，每一次提取不超过业务数据数量阈值的目标业务数据，按照业务方配置的数据核对逻辑和数据修复逻辑进行数据核对和修复，当数据核对结果为核对逻辑错误或修复结果为修复失败时，基于配置的重试延时时间，自动延时重试，直至数据核对结果不为核对逻辑错误或达到重核次数阈值，数据修复结果为修复成功或达到重修复次数阈值。

数据核对模块基于数据核对和数据修复的结果，按照配置的反馈数据统计方式进行数据统计，将统计结果反馈至业务方。

进一步地，如图8所示，业务数据核对系统分为调度、数据核对和存储三大模块。其中，调度模块的主要工作流程如图9所示，主要包括负责数据核对任务的启动，资源分配和业务数据流水导入。

其中，业务数据的接入过程为：接入业务系统的实时业务数据流水，从缓存中拉取业务数据过滤逻辑，进行数据过滤，针对系统配置的去重逻辑，按照位移关键字进行数据去重，然后将双重过滤处理后的待核对业务数据通过消息队列传输至数据核对模块进行数据核对处理，并将处理结果反馈至业务方。

数据核对触发过程为：通过定时器每个预设时间如一分钟进行一次数据核对触发，启动业务数据核对进程，业务数据核对进程通过拉取数据核对策略，从缓存的待核对业务数据中拉取预设数量的目标业务数据，目标业务数据需满足的条件包括未核对或待重核、流水时间≤当前时间-数据核对配置时间，且目标业务数据的数量≤系统设定的频控参数，即业务数据数量阈值。针对拉取的目标业务数据，生成数据核对任务标识并将拉取的目标业务数据的数据状态更新为可核对，并将数据核对任务标识更新到每条可核对的目标业务数据中，从而创建数据核对任务，数据核对模块基于数据核对任务标识对目标业务数据进行数据核对处理，并将处理结果反馈至业务方。

数据核对模块负责正常的数据核对，数据核对逻辑由业务方自定义设计，数据核对逻辑可以通过rpc(Remote Procedure Call，远程过程调用)接口，函数库等形式接入进来。其中，由于不同的业务可能会存在不同量级的数据，为了避免大流量业务的积压影响小流量业务的数据核对无法触发，这里预备了多个消息队列，并通过写入线上配置的形式，使业务能够自定义接入对应消息队列中，大流量地业务可以写入单独的一个队列种，减少大量任务堆积的影响，为了能尽可能利用业务数据核对进程的性能，避免消息队列中目标业务数据的积压，这里使用了分离式消息队列，即业务数据核对进程和消息队列是独立的两个模块，业务数据核对进程和消息队列采用的是多对多的连接方式，业务数据核对进程可以去任意一个消息队列中拉取目标业务数据，相较于业务数据核对进程和消息队列一对一的好处就是能尽量使用业务数据核对进程的资源，防止消息队列出现积压的情况

数据核对模块的数据处理过程如图10所示，拉取数据核对策略，基于数据核对任务标识获取需要进行数据核对的业务数据，将业务数据分流至消息队列，将目标业务数据的状态标签更新为数据核对中，基于数据核对逻辑对目标业务数据进行核对，得到数据核对结果，并基于数据核对结果再次更新目标业务数据的状态标签，并将数据核对结果反馈至业务方，同时，针对数据核对结果为核对失败的问题业务数据，通过发送提示消息提示业务方，并判断是否配置有针对该问题业务数据的修复逻辑，若存在，则基于修复逻辑对问题业务数据进行数据修复，当修复成功时，通知业务方修复成功，并将业务数据的状态标签更新为已修复。

在数据存储模块中，存储有每一条业务数据对应流水的流水表、数据核对任务表以及策略配置表。其中，数据存储模块可以采用分布式的存储方式，支持海量数据的读写，可延展性较强。针对不同的业务方，还可以独立部署对应的存储集群，并通过线上配置把数据存储模块链接到业务方的存储集群中，对于一些重要业务，实现资源隔离提高数据的安全性。

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

基于同样的发明构思，本申请实施例还提供了一种用于实现上述所涉及的业务数据核对方法的业务数据核对装置。该装置所提供的解决问题的实现方案与上述方法中所记载的实现方案相似，故下面所提供的一个或多个业务数据核对装置实施例中的具体限定可以参见上文中对于业务数据核对方法的限定，在此不再赘述。

在一个实施例中，如图11所示，提供了一种业务数据核对装置1100，包括：数据确定模块1102、数据提取模块1104和数据核对模块1106，其中：

数据确定模块1102，用于响应于针对目标业务方的业务数据核对触发事件，确定从所述目标业务方接入并缓存的待核对业务数据；

数据提取模块1104，用于按照业务数据提取时间间隔，分批次从所述待核对业务数据中提取符合核对条件的目标业务数据，每一次提取的所述目标业务数据的数量不超过业务数据数量阈值；

数据核对模块1106，用于针对每一次提取的目标业务数据，按照所述目标业务数据对应的数据核对逻辑对进行数据核对，得到业务数据核对结果。

在其中一个实施例中，所述装置还包括重核模块；

所述重核模块，用于确定所述数据核对结果为核对逻辑错误、且已核对次数未达到核对次数阈值的待重核业务数据；当所述待重核业务数据的核对延迟时长满足核对延时条件时，将所述待重核业务数据重新确定为符合核对条件的目标业务数据。

在其中一个实施例中，所述装置还包括修复模块；

所述修复模块，用于当存在数据核对结果为核对失败的问题业务数据时，获取针对所述问题业务数据的修复逻辑；基于所述修复逻辑对所述问题业务数据进行修复，得到数据修复结果。

在其中一个实施例中，所述修复模块，还用于当所述问题业务数据的数据修复结果为修复失败、且已修复次数未达到修复次数阈值时，记录针对所述问题业务数据的修复延迟时长；当所述修复延迟时长满足修复延时条件时，重新对所述问题数据进行修复。

在其中一个实施例中，所述数据核对模块，还用于将每一次提取的目标业务数据的状态标签标记为可核对；针对所述状态标签为可核对的目标业务数据，按照所述目标业务数据对应的数据核对逻辑对进行数据核对，得到每一目标业务数据各自对应的数据核对结果；

所述数据核对模块，还用于基于所述数据核对结果，更新所述目标业务数据的状态标签；分类统计所述状态标签，得到业务数据核对结果。

在其中一个实施例中，所述数据提取模块，还用于在当前时间满足所述业务数据核对事件的定时触发条件时，触发针对目标业务方的业务数据核对事件；响应于触发的所述业务数据核对事件，启动业务数据核对进程；通过执行所述业务数据核对进程，按照业务数据提取时间间隔，分批次从所述待核对业务数据中提取符合核对条件的目标业务数据。

在其中一个实施例中，启动的业务数据核对进程的数量不少于两个；所述数据核对模块，还用于基于启动的各业务数据核对进程，对各所述业务数据核对进程各自提取的目标业务数据，分别按照所述目标业务数据对应的数据核对逻辑进行数据核对。

在其中一个实施例中，所述数据提取模块，还用于按照业务数据类别所对应的核对需求，将所述待核对业务数据分流至不同的消息队列：采用多个业务数据核对进程，从各所述消息队列中，提取出符合核对条件的目标业务数据。

在其中一个实施例中，所述装置还包括去重模块；

所述去重模块，用于获取从目标业务方接入的初始业务数据流，确定针对所述初始业务数据的数据过滤逻辑；基于所述数据过滤逻辑，对所述初始业务数据流进行数据过滤处理，得到待核对业务数据。

在其中一个实施例中，所述数据过滤逻辑包括去重逻辑和业务数据过滤逻辑；所述去重模块，还用于按照所述去重逻辑和所述业务数据过滤逻辑，对所述初始业务数据流进行双重数据过滤处理，得到待核对业务数据。

在其中一个实施例中，所述装置还包括数据反馈模块；

所述数据反馈模块，用于当所述数据核对结果中存在异常数据时，按照异常数据类型和业务数据维度中的至少一种类别，对所述异常数据进行分类；将分类后的异常数据反馈至所述目标业务方。

上述业务数据核对装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

在一个实施例中，提供了一种计算机设备，该计算机设备可以是服务器，其内部结构图可以如图12所示。该计算机设备包括通过系统总线连接的处理器、存储器和网络接口。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质和内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的数据库用于存储业务数据等。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种业务数据核对方法。

本领域技术人员可以理解，图12中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个实施例中，还提供了一种计算机设备，包括存储器和处理器，存储器中存储有计算机程序，该处理器执行计算机程序时实现上述各方法实施例中的步骤。

在一个实施例中，提供了一种计算机可读存储介质，存储有计算机程序，该计算机程序被处理器执行时实现上述各方法实施例中的步骤。

在一个实施例中，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述各方法实施例中的步骤。

需要说明的是，本申请所涉及的用户信息(包括但不限于用户设备信息、用户个人信息等)和数据(包括但不限于用于分析的数据、存储的数据、展示的数据等)，均为经用户授权或者经过各方充分授权的信息和数据。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、数据库或其它介质的任何引用，均可包括非易失性和易失性存储器中的至少一种。非易失性存储器可包括只读存储器(Read-OnlyMemory，ROM)、磁带、软盘、闪存、光存储器、高密度嵌入式非易失性存储器、阻变存储器(ReRAM)、磁变存储器(Magnetoresistive Random Access Memory，MRAM)、铁电存储器(Ferroelectric Random Access Memory，FRAM)、相变存储器(Phase Change Memory，PCM)、石墨烯存储器等。易失性存储器可包括随机存取存储器(Random Access Memory，RAM)或外部高速缓冲存储器等。作为说明而非局限，RAM可以是多种形式，比如静态随机存取存储器(Static Random Access Memory，SRAM)或动态随机存取存储器(Dynamic RandomAccess Memory，DRAM)等。本申请所提供的各实施例中所涉及的数据库可包括关系型数据库和非关系型数据库中至少一种。非关系型数据库可包括基于区块链的分布式数据库等，不限于此。本申请所提供的各实施例中所涉及的处理器可为通用处理器、中央处理器、图形处理器、数字信号处理器、可编程逻辑器、基于量子计算的数据处理逻辑器等，不限于此。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对本申请专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请的保护范围应以所附权利要求为准。

Claims (15)

1.一种业务数据核对方法，其特征在于，所述方法包括：

响应于触发的针对目标业务方的业务数据核对事件，确定从所述目标业务方接入并缓存的待核对业务数据；

按照业务数据提取时间间隔，分批次从所述待核对业务数据中提取符合核对条件的目标业务数据，每一次提取的所述目标业务数据的数量不超过业务数据数量阈值；

针对每一次提取的目标业务数据，按照所述目标业务数据对应的数据核对逻辑对进行数据核对，得到业务数据核对结果。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

确定所述数据核对结果为核对逻辑错误、且已核对次数未达到核对次数阈值的待重核业务数据；

当所述待重核业务数据的核对延迟时长满足核对延时条件时，将所述待重核业务数据重新确定为符合核对条件的目标业务数据。

3.根据权利要求1所述的方法，其特征在于，所述方法还包括：

当存在数据核对结果为核对失败的问题业务数据时，获取针对所述问题业务数据的修复逻辑；

基于所述修复逻辑，对所述问题业务数据进行修复处理，得到数据修复结果。

4.根据权利要求3所述的方法，其特征在于，所述方法还包括：

当所述问题业务数据的数据修复结果为修复失败、且已修复次数未达到修复次数阈值时，记录针对所述问题业务数据的修复延迟时长；

当所述修复延迟时长满足修复延时条件时，重新对所述问题业务数据进行修复。

5.根据权利要求1所述的方法，其特征在于，所述针对每一次提取的目标业务数据，按照所述目标业务数据对应的数据核对逻辑对进行数据核对，得到业务数据核对结果，包括：

将每一次提取的目标业务数据的状态标签标记为可核对；

针对所述状态标签为可核对的目标业务数据，按照所述目标业务数据对应的数据核对逻辑对进行数据核对，得到每一目标业务数据各自对应的数据核对结果；

所述方法还包括：

基于所述每一目标业务数据各自对应的数据核对结果，更新所述目标业务数据的状态标签。

6.根据权利要求1所述的方法，其特征在于，所述按照业务数据提取时间间隔，分批次从所述待核对业务数据中提取符合核对条件的目标业务数据，包括：

在当前时间满足所述业务数据核对事件的定时触发条件时，触发针对目标业务方的业务数据核对事件；

响应于触发的所述业务数据核对事件，启动业务数据核对进程；

通过执行所述业务数据核对进程，按照业务数据提取时间间隔，分批次从所述待核对业务数据中提取符合核对条件的目标业务数据。

7.根据权利要求6所述的方法，其特征在于，启动的业务数据核对进程的数量不少于两个；

所述针对每一次提取的目标业务数据，按照所述目标业务数据对应的数据核对逻辑对进行数据核对，包括：

基于启动的各业务数据核对进程，对各所述业务数据核对进程各自提取的目标业务数据，分别按照所述目标业务数据对应的数据核对逻辑进行数据核对。

8.根据权利要求1至7中任一项所述的方法，其特征在于，所述从所述待核对业务数据中提取符合核对条件的目标业务数据，包括：

按照业务数据类别所对应的核对需求，将所述待核对业务数据分流至不同的消息队列；

采用多个业务数据核对进程，从各所述消息队列中，提取出符合核对条件的目标业务数据。

9.根据权利要求1至7中任一项所述的方法，其特征在于，所述方法还包括：

获取从目标业务方接入的初始业务数据流，确定针对所述初始业务数据的数据过滤逻辑；

基于所述数据过滤逻辑，对所述初始业务数据流进行数据过滤处理，得到待核对业务数据。

10.根据权利要求9所述的方法，其特征在于，所述数据过滤逻辑包括去重逻辑以及业务数据过滤逻辑；

所述基于所述数据过滤逻辑，对所述初始业务数据流进行数据过滤处理，得到待核对业务数据，包括：

按照所述去重逻辑和所述业务数据过滤逻辑，对所述初始业务数据流进行双重数据过滤处理，得到待核对业务数据。

11.根据权利要求1至7中任一项所述的方法，其特征在于，所述方法还包括：

当所述数据核对结果中存在异常数据时，按照异常数据类型和业务数据维度中的至少一种类别，对所述异常数据进行分类；

将分类后的异常数据反馈至所述目标业务方。

12.一种业务数据核对装置，其特征在于，所述装置包括：

数据确定模块，用于响应于针对目标业务方的业务数据核对触发事件，确定从所述目标业务方接入并缓存的待核对业务数据；

数据提取模块，用于按照业务数据提取时间间隔，分批次从所述待核对业务数据中提取符合核对条件的目标业务数据，每一次提取的所述目标业务数据的数量不超过业务数据数量阈值；

数据核对模块，用于针对每一次提取的目标业务数据，按照所述目标业务数据对应的数据核对逻辑对进行数据核对，得到业务数据核对结果。

13.一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至11中任一项所述的方法的步骤。

14.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至11中任一项所述的方法的步骤。

15.一种计算机程序产品，包括计算机程序，其特征在于，该计算机程序被处理器执行时实现权利要求1至11中任一项所述的方法的步骤。

Images