CN115827678B - 一种获取业务数据的方法、装置、介质及电子设备 - Google Patents

Abstract

本申请实施例提供一种获取业务数据的方法、装置、介质及电子设备，所述方法包括：获取日志数据，其中，所述日志数据是由数据中台提供的，所述数据中台被配置为从目标数据库筛选业务平台所需的数据信息，所述业务平台被配置依据所述数据信息拨打电话；根据所述日志数据获取目标业务数据补救模板；根据所述目标业务数据补救模板获取缺失业务数据；向所述业务平台发送所述缺失业务数据。通过本申请实施例提供的获取业务数据的方法可以自动且准确的向业务平台（例如，用于进行呼叫的业务平台）提供由于各种异常导致的缺失业务数据，进而提升业务平台的业务处理能力（向更加准确的目标用户拨打外呼电话）。

Description

一种获取业务数据的方法、装置、介质及电子设备

技术领域

本申请涉及数据处理领域，具体而言本申请实施例涉及一种获取业务数据的方法、装置、介质及电子设备。

背景技术

相关技术中，在业务平台获取业务数据的过程中存在自动化程度严重不足的技术问题，进而导致业务数据获取效率交差从而影响业务平台的业务处理能力。

可以理解的是，若业务平台在获取业务数据的过程中发生了异常现有的技术方案均是通过人工介入来处理对应的错误这将导致处理效率低，且不同处理人员的业务能力不同因此导致不同的处理人员会得到不同的处理效果，严重依赖人员的经验才能提升业务平台从数据中台获取业务数据的能力。

发明内容

本申请实施例的目的在于提供一种获取业务数据的方法、装置、介质及电子设备，通过本申请实施例提供的获取业务数据的方法可以自动且准确的向业务平台（例如，用于进行呼叫的业务平台）提供由于各种异常导致的缺失业务数据，进而提升业务平台的业务处理能力（向更加准确的目标用户拨打外呼电话）。

第一方面，本申请实施例提供一种获取业务数据的方法，所述方法包括：获取日志数据，其中，所述日志数据是由数据中台提供的，所述数据中台被配置为从目标数据库筛选业务平台所需的数据信息，所述业务平台被配置依据所述数据信息拨打电话；根据所述日志数据获取目标业务数据补救模板；根据所述目标业务数据补救模板获取缺失业务数据；向所述业务平台发送所述缺失业务数据。

本申请的一些实施例通过预先设置与各种异常对应的补救模板（即补救流程），进而可以通过监控日志数据从这些补救模板中得到最合理数据补救模板，并根据该目标业务数据补救模板从而实现更精准的缺失数据补发。

在一些实施例中，在所述根据所述日志数据获取目标业务数据补救模板之前，所述方法还包括：针对多个错误发生阶段分别配置数据补救模板，其中，所述多个错误发生阶段包括：数据查询阶段、数据保存阶段以及数据传输阶段。

本申请的一些实施例设置的补救模板涵盖了数据查询、数据保存以及数据传输阶段所有可能发生的异常补救流程，提升技术方案的通用性，且显著提升识别各类异常并补救各类异常的能力。

在一些实施例中，所述根据所述日志数据获取目标业务数据补救模板，包括：通过解析所述日志数据识别错误日志对应的业务类型，得到待补救业务类型；获取与所述待补救业务类型对应的缺失数据补救流程得到所述目标业务数据补救模板；所述根据所述目标业务数据补救模板获取缺失业务数据，包括：根据所述目标业务数据补救模板的补救流程获取所述缺失业务数据。

本申请的一些实施例通过解析日志数据识别出需要补发业务数据的业务类型，从而提升更加准确的提供业务数据补救流程。

在一些实施例中，所述待补救业务类型属于如下类型中的一种：由于数据同步错误导致的第一待补救业务类型，由于执行数据查询过程发生错误导致的第二待补救业务类型，由于从所述数据中台向所述业务平台推送所述查询数据发生异常导致的第三待补救业务类型或由于所述业务平台接收所述查询数据发生异常导致的第四待补救业务类型。

本申请的一些实施例涵盖了从数据保存（例如，第一待补救业务类型数据数据保存阶段发生的异常）、数据查询（例如，第二待补救业务类型属于数据查询阶段发生的异常）以及数据传输（例如，第三待补救业务类型和第四待补救业务类型属于数据传输阶段发生的异常）整个阶段的各类待补救业务类型，提升技术方案的通用性。

在一些实施例中，若所述待补救业务类型属于所述第一待补救业务类型，其中，所述根据所述目标业务数据补救模板获取缺失业务数据，包括：若确定所述第一待补救业务类型是由于同步过程中被同步数据发生异常导致的，则从所述日志数据中获取发生异常的第一时刻并将从所述第一时刻直至统计时刻由所述业务平台通过查询得到的查询数据均作为所述缺失业务数据，或者，若确定所述日志数据未记录发生异常的时刻，则将由所述业务平台向所述数据中台发出数据查询请求后直至统计时刻期间由所述数据中台查询得到的所有查询数据作为所述缺失业务数据。

本申请的一些实施例提供了一种在数据保存阶段发生异常的缺失业务数据获取方法，通过该方法可以得到更加完整的缺失业务数据，提升业务平台的业务处理能力。

在一些实施例中，所述根据所述目标业务数据补救模板获取缺失业务数据，还包括：若确定所述第一待补救业务类型是由于所述数据中台向所述业务平台提供的数据与所述业务平台接收的数据不一致导致的，则将所述数据中台向所述业务平台提供的数据作为所述缺失业务数据；所述向所述业务平台发送所述缺失业务数据，包括：向所述业务平台发送预设次数的所述缺失业务数据。

本申请的一些实施例可根据第一待补救业务类型获取缺失业务数据并将缺失业务数据通过多次发送的方式提供给业务平台，以提升业务平台接收到数据的准确性。

在一些实施例中，若所述待补救业务类型属于所述第二待补救业务类型，所述目标数据库中的数据是从各业务模块的业务数据库获取的，其中，所述根据所述目标业务数据补救模板获取缺失业务数据，包括：若确定所述第二待补救业务类型属于查询语句错误导致的，则向处理人员提供错误提示信息，以使所述处理人员根据所述错误提示信息调整所述查询语句得到更新查询语句；根据所述更新查询语句从所述目标数据库得到所述缺失业务数据。

本申请的一些实施例通过识别查询语句存储在的漏洞并通过人工方式即时补充漏洞，进而提升根据新的查询语句得到的缺失业务数据的准确性。

在一些实施例中，所述根据所述目标业务数据补救模板获取缺失业务数据，还包括：若确定所述第二待补救业务类型是由于所述目标数据库资源不足导致的，则根据所述各业务模块的业务数据库中的数据得到所述缺失业务数据；所述向所述业务平台发送所述缺失业务数据，包括：推迟设置时长后，接收所述缺失业务数据并将所述缺失业务数据存储在所述目标数据库；向所述业务平台发送由所述目标数据库存储的所述缺失业务数据。

本申请的一些实施例在确定待补救业务类型是由于数据库资源不足导致的问题时，可以通过间隔一定时间段后重新发送的方式来补救因此导致的数据缺失问题。

在一些实施例中，若所述待补救业务类型属于所述第三待补救业务类型，其中，所述根据所述目标业务数据补救模板获取缺失业务数据，包括：获取推送过程发生异常的第二时刻；将从所述第二时刻直至统计时刻由所述业务平台通过查询得到的查询数据均作为所述缺失业务数据。

本申请的一些实施例针对推送过程（即由数据中台向业务平台发送由其查询得到的数据过程）的异常，可根据异常发生时刻来补充发送缺失业务数据。

在一些实施例中，若所述待补救业务类型属于所述第四待补救业务类型，其中，所述根据所述目标业务数据补救模板获取缺失业务数据，包括：获取由所述业务平台反馈的业务异常日志信息；根据所述业务异常日志信息确定所述缺失数据。

本申请的一些实施例针对数据传输过程中发生的错误也提供了对应的补救流程。

第二方面，本申请的一些实施例提供一种获取业务数据的装置，所述装置包括：日志数据获取模块，被配置为获取日志数据，其中，所述日志数据是由数据中台提供的，所述数据中台被配置为从目标数据库筛选业务平台所需的数据信息，所述业务平台被配置依据所述数据信息拨打电话；数据补救模板获取模块，被配置为根据所述日志数据获取目标业务数据补救模板；缺失数据获取模块，被配置为根据所述目标业务数据补救模板获取缺失业务数据；提供模块，被配置为向所述业务平台发送所述缺失业务数据。

第三方面，本申请的一些实施例提供一种计算机存储介质，其上存储有计算机程序，所述程序被处理器执行时可实现如第一方面任意实施例所述的方法。

第四方面，本申请的一些实施例提供一种电子设备，包括存储器、处理器以及存储在所述存储器上并可在所述处理器上运行的计算机程序，其中，所述处理器执行所述程序时可实现如第一方面任意实施例所述的方法。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请实施例提供的获取业务数据的系统架构图；

图2为本申请实施例提供的获取业务数据的方法的流程图；

图3为本申请实施例提供的数据中台和业务平台的组成示意图；

图4为本申请实施例提供的业务数据查询筛选模块的组成框图；

图5为本申请实施例提供的获取业务数据的装置的组成框图；

图6为本申请实施例提供的电子设备的组成示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。同时，在本申请的描述中，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

本申请的一些实施例为了解决针对业务平台从数据中台可能获取不到或获取不全所需数据的问题（即本申请的一些实施例为了保证业务平台从数据中台得到的查询数据的准确和完整性），需要根据待补救业务类型确定补救流程得到对应的目标业务数据补救模板。例如，本申请的一些实施例解析业务流程，提前准备多种业务数据补救流程得到多种数据补救模版，并根据特定报错日志识别待补救业务类型，为该业务类型精准匹配其所述的业务数据补救流程，以通过该业务数据补救流程保证业务平台接收的查询数据的完整性，这种方式可自动获取补救数据，避免了像相关技术那样通过人力搜索错误日志并手动补救带来的补救不及时，补救错误等诸多技术问题。

请参看图1，图1为获取业务数据的系统，该系统包括：各业务模块的业务数据库、目标数据库102、数据中台104、业务平台103以及缺失业务数据补救端。

各业务模块示例性包括：外呼作业服务模块、拨打策略服务模块、语音识别转文本服务模块以及打标签服务模块，其中，外呼作业服务模块用于执行外呼操作，负责给用户拨打电话；拨打策略服务模块用于维护拨打策略，外呼作业服务模块根据策略进行对应的外呼；语音识别转文本服务模块用于在电话接通后识别语音流，转换成文本使用并存储；打标签服务模块用于根据语音文本识别意图并根据识别的意图打标签。

与各业务模块对应的业务数据库示例性包括：

与外呼作业服务模块对应的业务数据库包括：mysql 的业务数据库、redis的业务数据库以及mongodb的业务数据库。mysql 的业务数据库用于存储业务所需基本数据（例如，用户信息、通话记录等信息），redis的业务数据库用于存储作业临时数据（例如，参加作业的坐席，机器人相关信息），mongodb的业务数据库用于存储外呼队列相关数据。

与拨打策略服务模块对应的mysql 的业务数据库用于存储对应的拨打策略信息。

与语音识别转文本服务模块对应的 mysqlelasticsearch 的业务数据库用于存储语音转换文本。

与打标签服务模块对应的mysqlelasticsearch的业务数据库用于存储语音为本对应的标签。

目标数据库102用于存储从各业务模块的业务数据库101获取的所有数据。

业务平台103被配置为在需要拨打电话时，首先向数据中台104发送用于业务数据查询请求，并在后续接收由数据中台104查询得到的业务数据。可以理解的是，由于相关技术并不能保证业务平台103每次均能从数据中台104得到所需的业务数据，而相关技术为了解决这类问题都是通过人工方式实时排查发生的错误，并根据错误临时查找缺失数据，因此造成业务平台经常不能得到准确度满足要求的业务数据。

与相关技术不同的是，本申请的实施例通过监控日志数据自动识别待补救的业务类型，并为待补救的业务类型从多个预置的数据补救模板中选择相匹配的目标业务数据补救模板，通过该模块可以得到缺失业务数据并将业务数据提供给业务平台，显著提升了业务平台得到的业务数据的准确性和完成新。

数据中台104至少被配置为可解析来自于业务平台103的业务数据查询请求，并根据解析结果得到查询语句，再根据查询语句从目标数据库查询业务数据并将查询得到的业务数据。

与相关技术不同的是，本申请一些实施例还设置缺失业务数据补救端，该缺失业务数据补救端通过实时或周期性的获取日志数据（例如，图1该缺失业务数据补救端用于获取数据中台生成的日志数据，在本申请的一些实施例中该缺失业务数据补救端还可以获取业务平台生成的日志数据），并根据获取的日志数据确定待补救业务类型，并根据待补救业务类型确定业务数据补救流程，最后通过业务数据补救流程对应的数据补救模板向业务平台提供缺失业务数据，很好的解决了业务平台获取的业务数据不完整等技术问题。

需要说明的，上述业务平台、数据中台可以是由多台电子设备组成的具备相应功能的系统，上述缺失业务数据补救端为一台服务器或者由网络连接的多台服务器，本申请的实施例不限定业务平台、数据中台以及缺失业务数据补救端所依据的硬件系统的架构。在本申请的一些实施例中，目标数据库102也可以是设置在数据中台104中的数据库。

下面结合图2示例性阐述由图1的缺失业务数据补救端105执行的获取业务数据的方法。可以理解的是，在本申请的一些实施例中，缺失业务数据补救端105也可以设置在数据中台104中。

如图2所示，本申请实施例提供一种获取业务数据的方法，该方法包括：

S101，获取日志数据。

需要说明的是，所述日志数据是由数据中台提供的，所述数据中台被配置为从目标数据库筛选业务平台所需的数据信息，所述业务平台被配置依据所述数据信息拨打电话。

下面结合图3示例性阐述获取日志数据的过程。

本申请的一些实施例的业务平台被配置执行的业务包括向目标用户拨打电话，例如，如图3该业务平台用于执行第一外呼任务直至第n外呼任务，每个外部任务即自动通过线路给用户拨打电话。为了使得要求平台可以准确拨打这些电话需要各个外呼任务首先向数据中台104发送平台第i 外呼任务（即图3的第一外呼任务直至第n外呼任务所需的数据信息）所需的数据信息（即发送业务数据查询请求，该请求可以携带查询参数，例如，该参数可以包括目标拨打电话的用户的性别、年龄等信息），并接收由数据中台中的业务数据查询筛选模块112通过查询目标数据库111得到的推送数据，并向对应的外呼任务反馈查询得到的业务数据（即对应图3的根据第一外呼任务数据信息查询指定数据推送业务平台以及根据第n外呼任务数据信息查询指定数据推送业务平台）。

本申请的一些实施例通过监控方式从图3的数据中台获取由其生成的日志数据，在本申请的一些实施例中可以通过监控方式从图3的数据中台和业务平台获取由各自生成的日志数据，可以理解的是，收集的日志数据越多则可识别的错误日志越多，则对应根据错误日志识别下文的待补救业务类型也越多，能够更好提升业务平台得到的业务数据的完整性和准确性。

需要说明的是，图3的业务数据查询筛选模块112示例性包括图4所示的查询语句获取模块113以及业务数据获取模块114，其中，查询语句获取模块113可根据业务数据查询请求所携带的参数构造查询语句，业务数据获取模块114根据构造的查询语句从目标数据库筛选对应任务所需的业务数据。

S102，根据所述日志数据获取目标业务数据补救模板。

需要说明的是，在本申请的一些实施例中，在执行S102之前，所述方法还包括：针对多个错误发生阶段分别配置数据补救模板，其中，所述多个错误发生阶段包括：数据查询阶段、数据保存阶段以及数据传输阶段。

也就是说，本申请的一些实施例通过预先设置涵盖了数据查询、数据保存以及数据传输阶段的数据补救模板，并从这些数据补救模板中选择本次获取业务数据过程中发生的异常，并根据异常从这些数据补救模板选择匹配的一个作为目标业务数据补救模板，提升技术方案的通用性，且显著提升识别各类异常并补救各类异常的能力。

S103，根据所述目标业务数据补救模板获取缺失业务数据。

S104，向所述业务平台发送所述缺失业务数据。

本申请的一些实施例通过预先设置与各种异常对应的补救模板（即补救流程），进而可以通过监控日志数据从这些补救模板中得到最合理数据补救模板，并根据该目标业务数据补救模板从而实现更精准的缺失数据补发。

下面示例性阐述S103以及S104的实现过程。

在本申请的一些实施例中，S103示例性包括如下第一步和第二步：

第一步，通过解析所述日志数据识别错误日志对应的业务类型，得到待补救业务类型。

需要说明的是，在本申请的一些实施例中，所述待补救业务类型属于如下类型中的一种：由于数据同步错误导致的第一待补救业务类型，由于执行数据查询过程发生错误导致的第二待补救业务类型，由于从所述数据中台向所述业务平台推送所述查询数据发生异常导致的第三待补救业务类型或由于所述业务平台接收所述查询数据发生异常导致的第四待补救业务类型。

也就是说，本申请的一些实施例涵盖了从数据保存（例如，第一待补救业务类型数据数据保存阶段发生的异常）、数据查询（例如，第二待补救业务类型属于数据查询阶段发生的异常）以及数据传输（例如，第三待补救业务类型和第四待补救业务类型属于数据传输阶段发生的异常）整个阶段的各类待补救业务类型，并未各种待补救业务类型确定对应的缺失业务数据补救流程，提升技术方案的通用性。

第二步，获取与所述待补救业务类型对应的缺失数据补救流程得到所述目标业务数据补救模板。例如，将所述待补救业务类型与预置的多种业务数据补救模板分别匹配，并将匹配成功的业务数据补救模板作为目标业务数据补救模板。需要说明的是，本申请一些实施例的业务数据补救模板定义了确定缺失业务数据并向业务平台发送业务数据的方法。

可以理解的是，上述根据所述目标业务数据补救模板获取缺失业务数据示例性包括：根据所述目标业务数据补救模板的补救流程获取所述缺失业务数据。

也就是说，本申请的一些实施例通过解析日志数据识别出需要补发业务数据的业务类型，从而提升更加准确的提供业务数据补救流程。

下面结合多个示例阐述各种待补救业务类型以及对应的业务数据补救模板的实现过程。

示例1

在下述示例中以第一待补救业务类型为例阐述S103的实现过程。

例如，在本申请的一些实施例中，若上述第一步所述待补救业务类型属于所述第一待补救业务类型，相应的S103示例性包括：若确定所述第一待补救业务类型是由于同步过程中被同步数据发生异常导致的，则从所述日志数据中获取发生异常的第一时刻并将从所述第一时刻直至统计时刻由所述业务平台通过查询得到的查询数据均作为所述缺失业务数据，或者，若确定所述日志数据未记录发生异常的时刻，则将由所述业务平台向所述数据中台发出数据查询请求后直至统计时刻期间由所述数据中台查询得到的所有查询数据作为所述缺失业务数据。也就是说，本申请的一些实施例提供了一种在数据保存阶段发生异常的缺失业务数据获取方法，通过该方法可以得到更加完整的缺失业务数据，提升业务平台的业务处理能力。

例如，在本申请的一些实施例中，若上述第一步所述待补救业务类型属于所述第一待补救业务类型，相应的S103还示例性包括：若确定所述第一待补救业务类型是由于所述数据中台向所述业务平台提供的数据与所述业务平台接收的数据不一致导致的，则将所述数据中台向所述业务平台提供的数据作为所述缺失业务数据；所述向所述业务平台发送所述缺失业务数据，包括：向所述业务平台发送预设次数的所述缺失业务数据。也就是说，本申请的一些实施例可根据第一待补救业务类型获取缺失业务数据并将缺失业务数据通过多次发送的方式提供给业务平台，以提升业务平台接收到数据的准确性。

示例2

在下述示例中以第二待补救业务类型为例示例性阐述S103或者S104的实现过程。

例如，在本申请的一些实施例中，若上述第一步所述待补救业务类型属于所述第二待补救业务类型，所述目标数据库中的数据是从各业务模块的业务数据库获取的，则S103示例性包括：若确定所述第二待补救业务类型属于查询语句错误导致的，则向处理人员提供错误提示信息，以使所述处理人员根据所述错误提示信息调整所述查询语句得到更新查询语句；根据所述更新查询语句从所述目标数据库得到所述缺失业务数据。也就是说，本申请的一些实施例通过识别查询语句存储在的漏洞并通过人工方式即时补充漏洞，进而提升根据新的查询语句得到的缺失业务数据的准确性。

例如，在本申请的一些实施例中，S103还包括：若确定所述第二待补救业务类型是由于所述目标数据库资源不足导致的，则根据所述各业务模块的业务数据库中的数据得到所述缺失业务数据；S104所述向所述业务平台发送所述缺失业务数据的过程示例性包括：推迟设置时长后，接收所述缺失业务数据并将所述缺失业务数据存储在所述目标数据库；向所述业务平台发送由所述目标数据库存储的所述缺失业务数据。也就是说，本申请的一些实施例在确定待补救业务类型是由于数据库资源不足导致的问题时，可以通过间隔一定时间段后重新发送的方式来补救因此导致的数据缺失问题。

示例3

在下述示例中以第三待补救业务类型示例性阐述S103的实现过程。

例如，在本申请的一些实施例中，若上述第一步所述待补救业务类型属于所述第三待补救业务类型，则S103示例性包括：获取推送过程发生异常的第二时刻；将从所述第二时刻直至统计时刻由所述业务平台通过查询得到的查询数据均作为所述缺失业务数据。也就是说，本申请的一些实施例针对推送过程（即由数据中台向业务平台发送由其查询得到的数据过程）的异常，可根据异常发生时刻来补充发送缺失业务数据。

示例4

在下述示例中以第四待补救业务类型示例性阐述S103的实现过程。

例如在本申请的一些实施例中，若所述待补救业务类型属于所述第四待补救业务类型，其中，所述根据所述目标业务数据补救模板获取缺失业务数据，包括：获取由所述业务平台反馈的业务异常日志信息；根据所述业务异常日志信息确定所述缺失数据。本申请的一些实施例针对数据传输过程中发生的错误也提供了对应的补救流程。

需要说明的是，在本申请的一些实施例通过java代码实现上述S102以及S103，具体地，数据中台与业务平台的接口对接，接收业务数据查询请求该请求包括请求参数，根据制定规则解析参数生成对应查询语句sql，连接关系型数据库执行查询语句sql，将查询得到的业务数据写入目标表，分批查询数据，并通过接口传输给业务平台的数据需求方，期间通过java代码实现的缺失业务数据补救端捕获各个节点（例如，各个节点包括取数脚本准备节点、查询节点以及数据推送节点，其中，取数脚本准备节点用于根据业务条件拼接查询数据脚本，查询节点用于根据脚本筛选查询所需数据，数据推送节点用于将查询到的数据按照特定格式推送给对应的业务需求模块）可能出现的错误日志信息，通过自定义贴合业务流程的错误信息记录（例如，取数脚本准备节点的错误信息包括：业务条件错误或脚本组合错误等；查询节点的错误信息包含：数据库引擎因为内存不足等自身问题报错，脚本与数据库引擎不匹配报错等；数据推送节点的错误信息包含：数据推送中断错误，数据推送过程中数据丢失错误等），例：数据通过接口返回数据需求方出错，记录推送记录的唯一标识id（唯一标识指的是用户在整个业务体系中的唯一标记，各个模块可以根据该标记获取到对应的用户信息），根据业务规则判断对应数据包未传输数据，自动查询未传输数据明细得到缺失业务数据，重新给业务平台传输对应数据。需要说明的是，业务规则其实就是传输的数据会有对应的传输任务标识，有标识的数据代表对应任务传输过并且服务端接收到了，没有标识的数据，说明在传输过程中出现问题，服务端没有获取到，需要重新传输。

可以理解的是，在本申请的一些实施例会同时监控是否发生了上述第一待补救业务类型、第二待补救业务类型、第三待补救业务类型以及第四待补救业务类型中的所有待补救业务类型，并执行对应的获取缺失业务数据的过程，以最大程度的提升向业务平台提供的业务数据的完整性和准确性。

请参考图5，图5示出了本申请实施例提供一种获取业务数据的装置，应理解，该装置与上述图2方法实施例对应，能够执行上述方法实施例涉及的各个步骤，该装置的具体功能可以参见上文中的描述，为避免重复，此处适当省略详细描述。装置包括至少一个能以软件或固件的形式存储于存储器中或固化在装置的操作系统中的软件功能模块，该获取业务数据的装置，包括：日志数据获取模块501、数据补救模板获取模块502、缺失数据获取模块503以及提供模块504。

日志数据获取模块，被配置为获取日志数据，其中，所述日志数据是由数据中台提供的，所述数据中台被配置为从目标数据库筛选业务平台所需的数据信息，所述业务平台被配置依据所述数据信息拨打电话。

数据补救模板获取模块，被配置为根据所述日志数据获取目标业务数据补救模板。

缺失数据获取模块，被配置为根据所述目标业务数据补救模板获取缺失业务数据。

提供模块，被配置为向所述业务平台发送所述缺失业务数据。

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

本申请的一些实施例提供一种计算机存储介质，其上存储有计算机程序，所述程序被处理器执行时可实现如上述获取业务数据的方法所包括的任意实施例所述的方法。

如图6所示，本申请的一些实施例提供一种电子设备600，包括存储器610、处理器620以及存储在所述存储器610上并可在所述处理器620上运行的计算机程序，其中，所述处理器620通过总线630读取程序并执行所述程序时可实现如上述获取业务数据的方法所包括的任意实施例所述的方法。

处理器620可以处理数字信号，可以包括各种计算结构。例如复杂指令集计算机结构、结构精简指令集计算机结构或者一种实行多种指令集组合的结构。在一些示例中，处理器620可以是微处理器。

存储器610可以用于存储由处理器620执行的指令或指令执行过程中相关的数据。这些指令和/或数据可以包括代码，用于实现本申请实施例描述的一个或多个模块的一些功能或者全部功能。本公开实施例的处理器620可以用于执行存储器610中的指令以实现图2中所示的方法。存储器610包括动态随机存取存储器、静态随机存取存储器、闪存、光存储器或其它本领域技术人员所熟知的存储器。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本申请的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

另外，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

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

以上所述仅为本申请的实施例而已，并不用于限制本申请的保护范围，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应所述以权利要求的保护范围为准。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

Claims (10)

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

获取数据中台和业务平台生成的日志数据，其中，所述数据中台至少被配置为可解析来自于业务平台的业务数据查询请求，并根据解析结果得到查询语句，再根据查询语句从目标数据库查询业务数据，所述业务平台接收由数据中台中的业务数据查询筛选模块通过查询目标数据库得到的推送数据，并向对应的外呼任务反馈查询得到的业务数据；

针对多个错误发生阶段分别配置数据补救模板，其中，所述多个错误发生阶段包括：数据查询阶段、数据保存阶段以及数据传输阶段；

根据所述日志数据获取目标业务数据补救模板，其中，所述目标业务数据补救模板属于所述数据补救模板中的模板；

根据所述目标业务数据补救模板获取缺失业务数据；

向所述业务平台发送所述缺失业务数据；

所述根据所述日志数据获取目标业务数据补救模板，包括：

通过解析所述日志数据识别错误日志对应的业务类型，得到待补救业务类型；

获取与所述待补救业务类型对应的缺失数据补救流程得到所述目标业务数据补救模板；

所述根据所述目标业务数据补救模板获取缺失业务数据，包括：

根据所述目标业务数据补救模板的补救流程获取所述缺失业务数据；

其中，所述待补救业务类型属于如下类型中的一种：由于数据同步错误导致的第一待补救业务类型，由于执行数据查询过程发生错误导致的第二待补救业务类型，由于从所述数据中台向所述业务平台推送查询数据发生异常导致的第三待补救业务类型或由于所述业务平台接收所述查询数据发生异常导致的第四待补救业务类型。

2.如权利要求1所述的方法，其特征在于，若所述待补救业务类型属于所述第一待补救业务类型，其中，

所述根据所述目标业务数据补救模板获取缺失业务数据，包括：

若确定所述第一待补救业务类型是由于同步过程中被同步数据发生异常导致的，则从所述日志数据中获取发生异常的第一时刻并将从所述第一时刻直至统计时刻由所述业务平台通过查询得到的查询数据均作为所述缺失业务数据，或者，若确定所述日志数据未记录发生异常的时刻，则将由所述业务平台向所述数据中台发出数据查询请求后直至统计时刻期间由所述数据中台查询得到的所有查询数据作为所述缺失业务数据。

3.如权利要求2所述的方法，其特征在于，所述根据所述目标业务数据补救模板获取缺失业务数据，还包括：

若确定所述第一待补救业务类型是由于所述数据中台向所述业务平台提供的数据与所述业务平台接收的数据不一致导致的，则将所述数据中台向所述业务平台提供的数据作为所述缺失业务数据；

所述向所述业务平台发送所述缺失业务数据，包括：

向所述业务平台发送预设次数的所述缺失业务数据。

4.如权利要求1所述的方法，其特征在于，若所述待补救业务类型属于所述第二待补救业务类型，其中，

所述根据所述目标业务数据补救模板获取缺失业务数据，包括：

若确定所述第二待补救业务类型属于查询语句错误导致的，则向处理人员提供错误提示信息，以使所述处理人员根据所述错误提示信息调整所述查询语句得到更新查询语句；

根据所述更新查询语句从所述目标数据库得到所述缺失业务数据。

5.如权利要求4所述的方法，其特征在于，所述目标数据库中的数据是从各业务模块的业务数据库获取的，其中，

所述根据所述目标业务数据补救模板获取缺失业务数据，还包括：

若确定所述第二待补救业务类型是由于所述目标数据库的资源不足导致的，则根据所述各业务模块的业务数据库中的数据得到所述缺失业务数据；

所述向所述业务平台发送所述缺失业务数据，包括：

推迟设置时长后，接收所述缺失业务数据并将所述缺失业务数据存储在所述目标数据库；

向所述业务平台发送由所述目标数据库存储的所述缺失业务数据。

6.如权利要求1所述的方法，其特征在于，若所述待补救业务类型属于所述第三待补救业务类型，其中，

所述根据所述目标业务数据补救模板获取缺失业务数据，包括：

获取推送过程发生异常的第二时刻；

将从所述第二时刻直至统计时刻由所述业务平台通过查询得到的查询数据均作为所述缺失业务数据。

7.如权利要求1所述的方法，其特征在于，若所述待补救业务类型属于所述第四待补救业务类型，其中，

所述根据所述目标业务数据补救模板获取缺失业务数据，包括：

获取由所述业务平台反馈的业务异常日志信息；

根据所述业务异常日志信息确定所述缺失数据。

8.一种获取业务数据的装置，其特征在于，所述装置包括：

日志数据获取模块，被配置为获取数据中台和业务平台生成的日志数据，其中，所述数据中台至少被配置为可解析来自于业务平台的业务数据查询请求，并根据解析结果得到查询语句，再根据查询语句从目标数据库查询业务数据，所述业务平台接收由数据中台中的业务数据查询筛选模块通过查询目标数据库得到的推送数据，并向对应的外呼任务反馈查询得到的业务数据；

数据补救模板配置模块，被配置为针对多个错误发生阶段分别配置数据补救模板，其中，所述多个错误发生阶段包括：数据查询阶段、数据保存阶段以及数据传输阶段；

数据补救模板获取模块，被配置为根据所述日志数据获取目标业务数据补救模板，其中，所述目标业务数据补救模板属于所述数据补救模板中的模板；

缺失数据获取模块，被配置为根据所述目标业务数据补救模板获取缺失业务数据；

提供模块，被配置为向所述业务平台发送所述缺失业务数据；

其中，

所述数据补救模板获取模块还被配置为：

通过解析所述日志数据识别错误日志对应的业务类型，得到待补救业务类型；

获取与所述待补救业务类型对应的缺失数据补救流程得到所述目标业务数据补救模板；

所述根据所述目标业务数据补救模板获取缺失业务数据，包括：

根据所述目标业务数据补救模板的补救流程获取所述缺失业务数据；

其中，所述待补救业务类型属于如下类型中的一种：由于数据同步错误导致的第一待补救业务类型，由于执行数据查询过程发生错误导致的第二待补救业务类型，由于从所述数据中台向所述业务平台推送查询数据发生异常导致的第三待补救业务类型或由于所述业务平台接收所述查询数据发生异常导致的第四待补救业务类型。

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

10.一种电子设备，包括存储器、处理器以及存储在所述存储器上并可在所述处理器上运行的计算机程序，其中，所述处理器执行所述程序时可实现如权利要求1-7中任意一项权利要求所述的方法。

Images