CN113051303A

CN113051303A - 业务数据处理方法、装置、电子设备以及存储介质

Info

Publication number: CN113051303A
Application number: CN201911375475.8A
Authority: CN
Inventors: 宋艳丽
Original assignee: Beijing Gridsum Technology Co Ltd
Current assignee: Beijing Gridsum Technology Co Ltd
Priority date: 2019-12-27
Filing date: 2019-12-27
Publication date: 2021-06-29

Abstract

本申请涉及一种业务数据处理方法、装置、电子设备和存储介质，通过获取业务需求请求；查找业务需求请求对应的业务目的信息；确定业务目的信息对应的分类标签，查找业务目的信息对应的历史业务数据，对历史业务数据进行微服务编排，生成初始业务目的数据；对初始业务目的数据进行降重处理，获取业务目的数据。本申请通过预先将历史业务数据分解，并通过标签处理，在获得业务需求请求后，根据请求的目的确定对应的分类标签，而后通过分类标签查找历史业务数据，通过对历史业务数据的微服务编排生成初始业务目的数据，并进行降重处理来获取业务目的数据，通过总结历史数据，进行分类标签形式的松耦合处理，能有效保证业务目的数据的可复用性。

Description

业务数据处理方法、装置、电子设备以及存储介质

技术领域

本申请涉及计算机技术领域，特别是涉及一种业务数据处理方法、装置、电子设备以及存储介质。

背景技术

随着互联网时代的发展，用户逐渐变为商业战场的中心，满足用户需求的重要性不断提升，而企业可以借助平台化的力量来让快速响应用户的需求的工作变得事半功倍。在平台化建设的过程中，出现了前台、中台、后台等概念，其中中台具有对后台的资源进行抽象包装整合，转化为前台友好的可重用共享的核心能力，实现后端资源到前台易用能力的转化。

对于用户提出的业务需求，如果该业务需求需要同时组合多种现有的资料数据才能满足，则需要在后台与中台对业务相关的数字数据进行有效的整理，从而为前台提供有效支持，保证业务实施的效率。然而对于组合后的数据，现有的数据处理方法并不能对这些数据进行有效的复用。

发明内容

基于此，有必要针对现有数据处理方法，对于业务数据并不能进行有效复用的问题，提供一种可以实现业务数据复用的数据处理方法、装置、电子设备以及存储介质。

一种业务数据处理方法，所述方法包括：

获取业务需求请求；

查找所述业务需求请求对应的业务目的信息；

确定所述业务目的信息对应的分类标签，根据所述分类标签查找所述业务目的信息对应的历史业务数据；

对所述历史业务数据进行微服务编排，生成初始业务目的数据；

对所述初始业务目的数据进行降重处理，获取业务目的数据。

在其中一个实施例中，所述述确定所述业务目的信息对应的分类标签，根据所述分类标签查找所述业务目的信息对应的历史业务数据包括：

对所述业务需求请求进行ETL(Extract-Transform-Load，抽取-转换-加载)处理，获取业务子需求信息；

根据所述业务子需求信息查找并调用对应的API(Application ProgrammingInterface，应用程序接口)，通过所述API获取所述业务目的信息对应的历史业务数据，所述API由历史业务数据以API形式进行标签处理获得。

在其中一个实施例中，所述述确定所述业务目的信息对应的分类标签，根据所述分类标签查找所述业务目的信息对应的历史业务数据之前，包括：

获取历史业务数据；

根据所述历史业务数据的业务类型以及业务应用场景，为所述历史业务数据添加对应的分类标签；

根据所述分类标签将所述历史业务数据分类，并建立分类后的历史业务数据与API的关联联系。

在其中一个实施例中，所述对所述历史业务数据进行微服务编排，生成初始业务目的数据包括：

获取各API根据所述业务目的信息反馈的历史业务数据；

根据预设的数据整合模板以及所述历史业务数据对应的分类标签，将所述反馈的历史业务数据整合为初始业务目的数据。

在其中一个实施例中，所述对所述初始业务目的数据进行降重处理，获取业务目的数据包括：

将所述初始业务目的数据输入预设降重处理模型，获取业务目的数据。

在其中一个实施例中，所述对所述初始业务目的数据进行降重处理，获取业务目的数据之后，还包括：

反馈所述业务目的数据；

接收所述业务目的数据的使用报告信息；

根据所述使用报告信息更新所述业务目的数据，并存储更新后的所述业务目的数据。

一种业务数据处理装置，包括：

请求获取模块，用于获取业务需求请求；

目的提取模块，用于查找所述业务需求请求对应的业务目的信息；

数据调用模块，用于根据所述业务目的信息查找对应分类标签，获取所述业务目的信息对应的历史业务数据；

数据重组模块，用于对所述历史业务数据进行微服务编排，生成初始业务目的数据；

数据降重模块，用于对所述初始业务目的数据进行降重处理，获取业务目的数据。

在其中一个实施例中，所述数据调用模块用于：

对所述业务需求请求进行ETL处理，获取业务子需求信息；

根据所述业务子需求信息查找并调用对应的API，获取所述业务目的信息对应的历史业务数据，所述API由历史业务数据以API形式进行标签处理获得。

一种电子设备，所述电子设备包括至少一个处理器、以及与处理器连接的至少一个存储器、总线；其中，所述处理器、所述存储器通过所述总线完成相互间的通信；所述处理器用于调用所述存储器中的程序指令，所述程序指令被处理器执行时实现以下步骤：

获取业务需求请求；

查找所述业务需求请求对应的业务目的信息；

一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现以下步骤：

获取业务需求请求；

查找所述业务需求请求对应的业务目的信息；

上述业务数据处理方法、装置、电子设备和存储介质，通过获取业务需求请求；查找业务需求请求对应的业务目的信息；确定业务目的信息对应的分类标签，根据分类标签查找业务目的信息对应的历史业务数据，对历史业务数据进行微服务编排，生成初始业务目的数据；对初始业务目的数据进行降重处理，获取业务目的数据。本申请的数据处理方法，通过预先将历史业务数据分解，并通过标签处理，在获得业务需求请求后，根据业务需求请求的目的确定对应的分类标签，而后通过分类标签查找历史业务数据，通过对历史业务数据的微服务编排生成初始业务目的数据，并对初始业务目的数据进行降重处理来获取业务目的数据，通过总结历史数据，进行分类标签形式的松耦合处理，能有效保证业务目的数据的可复用性。

附图说明

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

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

图3为一个实施例中图2的步骤S500的子流程示意图；

图4为一个实施例中业务数据处理装置的结构框图；

图5为一个实施例中电子设备的内部结构图。

具体实施方式

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

本申请提供的数据查询方法，可以应用于如图1所示的应用环境中。其中，终端102通过网络与服务器104通过进行通信，首先终端102提交对应的业务需求请求至服务器104，服务器104获取业务需求请求；查找业务需求请求对应的业务目的信息；确定业务目的信息对应的分类标签，根据分类标签查找业务目的信息对应的历史业务数据；对历史业务数据进行微服务编排，生成初始业务目的数据；对初始业务目的数据进行降重处理，获取业务目的数据。而后将其返回到终端。其中，终端102可以但不限于是各种个人计算机、笔记本电脑、智能手机、平板电脑和便携式可穿戴设备，服务器104可以用独立的服务器或者是多个服务器组成的服务器集群来实现。

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

S100，获取业务需求请求。

其中，业务需求请求是指用户从终端发送至服务器的请求，其请求的目的是获取请求对应的目的信息对应的业务数据，这些业务数据可以从现有的其他的业务数据整理分类来得到。在其中一个实施例中，本申请的服务器为一个中台服务器，其通过对应的前台服务器接收终端的业务需求请求。在其中一个实施例中，终端提交的业务需求请求目的是生成一种新的企业制度，实际的应用场景中，对制度的渠道来源、种类、用途有很多，尤其是很多企业有自己的一些制度，随着企业的不断发展进步会在原版本上更新或改进，但是这些制度，并不是公司所有员工都能看到或直接复用的，有的时候一些部门或团队会根据自己部门或团队的实际情况制定属于自己团队的制度，这个时候是无法复用以及自由组合。此时可以通过本申请的业务数据处理方法总结历史的制度数据来生成新的制度。该业务需求请求包含了制度的类型、制度的应用场景以及制度细节要求等等信息，服务器可以根据业务需求请求以及历史中其他的制度数据总结获取。

S300，服务器查找业务需求请求对应的业务目的信息。

业务目的信息是指终端需求的业务数据需要满足的条件。用户发送的业务需求请求包含了用户所需要的业务目的数据的具体信息，比如业务数据的类型以及业务数据的适用领域等等。为了获取业务目的数据，服务器可以先提取终端发送的业务需求请求内包含的各个业务目的信息。在其中一个实施例中，终端提交的业务需求请求目的是生成一种新的企业制度，服务器可以将该业务需求请求分解，获取终端需要的企业制度需要达到那些目的，以及需要用到哪些历史业务数据。

S500，确定业务目的信息对应的分类标签，根据分类标签查找业务目的信息对应的历史业务数据。

每个业务目的信息都有其对应的数据标签，在分解用户的业务需求请求，获得满足需求所需要的所有业务目的信息后，可以根据确定个业务目的信息对应的分类标签，根据分类标签查找业务目的信息对应的历史业务数据。在其中一个实施例中，分类标签可以通过API实现，确定业务目的信息对应的分类标签的过程可以通过查找预设API库，来获得各个业务目的信息对应的API。而这些API与现有的分解后的历史业务数据对应。在其中一个实施例中，终端提交的业务需求请求目的是生成一种新的企业制度，服务器则预先将收集的历史制度数据分解，并以API的形式进行了标签处理，根据制度形式、制度种类类型、制度节点、制度应用场景等等，将历史的制度数据分解成不同的小的API。而服务器在提取出请求对应的所有业务目的信息之后，可以根据这些业务目的信息来调用对应的预先生成的API。

S700，对历史业务数据进行微服务编排，生成初始业务目的数据。

微服务编排是指通过一个请求来依次调用多个微服务，并对每个服务的返回结果做数据处理，最终整合为一个结果返回至前端方。在其中一个实施例中，分类标签可以通过API实现，当查找到API之后，可以获取API对应的历史业务数据，通过对这些历史业务数据进行微服务编排，生成初始的业务目的数据，这些初始业务目的数据包含了查找到的API中所有历史业务数据。在其中一个实施例中，终端提交的业务需求请求目的是生成一种新的企业制度，服务器可以对调用的各API对应的历史制度数据进行微服务编排，生成一个新的制度，该制度即终端需求的新的企业制度。

S900，对初始业务目的数据进行降重处理，获取业务目的数据。

由于初始的业务目的数据包含了各个来源以及各个类型的历史业务数据，其中可能存在某些重合或者是意思相近的部分，所以可以通过对该初始业务数据进行降重处理，来获取最终的业务目的数据。其中一个实施例中，终端提交的业务需求请求目的是生成一种新的企业制度，在对查找到的历史制度数据重组，生成新制度之后，可以对该新制度进行降重处理，去除制度中重复的部分，生成一份完善的制度。

上述业务数据处理方法，通过获取业务需求请求；查找业务需求请求对应的业务目的信息；确定业务目的信息对应的分类标签，根据分类标签查找业务目的信息对应的历史业务数据，对历史业务数据进行微服务编排，生成初始业务目的数据；对初始业务目的数据进行降重处理，获取业务目的数据。本申请的数据处理方法，通过预先将历史业务数据分解，并通过标签处理，在获得业务需求请求后，根据业务需求请求的目的确定对应的分类标签，而后通过分类标签查找历史业务数据，通过对历史业务数据的微服务编排生成初始业务目的数据，并对初始业务目的数据进行降重处理来获取业务目的数据，通过总结历史数据，进行分类标签形式的松耦合处理，能有效保证业务目的数据的可复用性。

如图3所示，在其中一个实施例中，步骤S500包括：

S520，对业务需求请求进行ETL处理，获取业务子需求信息。

S540，根据业务子需求信息查找并调用对应的API，通过API获取业务目的信息对应的历史业务数据，API由历史业务数据以API形式进行标签处理获得。

ETL，是英文Extract-Transform-Load的缩写，用来描述将数据从来源端经过抽取(extract)、转换(transform)、加载(load)至目的端的过程。服务器可以先将历史业务数据进行处理，具体可以以API形式进行标签处理。在本申请中，服务器通过对业务需求进行ETL处理，将其转换分解为各个具体的业务子需求，而这些业务子需求与预设的API对应，服务器可以通过业务子需求查找并调用对应的API，通过API获取业务目的信息对应的历史业务数据，以便进行后续的操作，提高方法实施的效率。

在其中一个实施例中，步骤S500之前，还包括：获取历史业务数据；根据历史业务数据的业务类型以及业务应用场景，为历史业务数据添加对应的分类标签；根据分类标签将历史业务数据分类，并建立分类后的历史业务数据与API的关联联系。

在调用API之前，服务器还需要对历史数据的总结归纳过程，该过程主要通过API实现，可以直接获取历史的业务数据，而后为这些历史业务数据添加对应的分类标签，这些分类标签可以根据历史业务数据的业务类型以及业务应用场景获取。在其他的实施例中，这些分类标签可以根据具体的业务类型进行划设，如在其中一个实施例中，历史业务数据为规则数据，则可以根据制度形式、制度种类类型、制度节点以及制度使用场景等等对这些规则数据进行分类，并添加对应的分类标签。而后根据这些分类标签，以API的形式对其进行标签处理。建立API与历史业务数据的联系。在其中一个实施例中，历史业务数据可以通过网络爬虫爬取网站上相关的业务数据；也可以与企业的业务数据库集成；以及一些行业或企业专属的一些业务数据等等，这些都可以通过不同的技术手段获得，获得的这些制度数据就是本申请的业务数据处理方法中的基础数据。

在一个实施例中，步骤S700包括：获取各API根据业务目的信息反馈的历史业务数据；根据预设的数据整合模板以及历史业务数据对应的分类标签，将反馈的历史业务数据整合为初始业务目的数据。

其中，预设的集成模板是指将分解后的历史业务数据重新集成为一个新的整体的模板，该模板可以根据具体的业务类型进行设置。服务器可以直接获取查找到的API对应的历史业务数据，并根据历史业务数据对应的分类标签，将这些分类后的历史业务数据添加到预设集成模板的对应位置，重组生成初始业务目的数据。在其中一个实施例中，本申请的业务数据处理方法用于生成一种新的制度，则该预设的集成模板则为制度的框架以及基础设置，服务器可以将查找到的历史制度数据填充到制度框架内，形成一个新的制度。通过预设的集成模板，可以高效的生成初始业务目的数据。

在一个实施例中，步骤S900包括：将初始业务目的数据输入预设降重处理模型，获取业务目的数据。

其中预设降重处理模型的用途是去除初始业务目的数据中重复的数据内容，通过上一步的调用重组生成的初始业务目的数据并不是最完善的数据，包含了较多重合的部分，可以通过预设降重处理模型来对这些数据进行降重处理，去除初始业务目的数据中的重复数据，提高数据的可用性，具体的，预设降重处理模型可以根据业务数据的类型进行设置，如业务数据为文本类数据是，则可以预设降重处理模型可以为自然语言处理方面的模型，比如类比学习、演绎学习、自然语言学习等等类型的模型，这些模型可以通过对初始业务目的数据中的重复语义进行检测并去除重复的数据，来获取最终的业务目的数据。通过降重处理，可以有效提高最终的业务目的数据的可用性。

在一个实施例中，步骤S900之后，还包括：反馈业务目的数据；接收业务目的数据的使用报告信息；根据使用报告信息更新业务目的数据，并存储更新后的业务目的数据。

在业务目的数据之后，还可以向终端反馈这些业务目的数据，并接收终端反馈这些业务目的数据对应的数据使用报告。并根据使用报告信息对获取业务目的数据进行调整，更新这些业务目的数据，并将其保存至数据库内。在其中一个实施例中，业务目的数据为新生成的制度，服务器可以获取这些制度的试用报告，并根据报告对生成制度不断更新，提高其通用性。服务器可以通过不断地总结学习，提高这些生成的业务目的数据的通用性。

在其中一个实施例中，本申请的业务数据处理方法用于生成一种新的制度，可以通过中台服务器实现，首先通过前台服务器接收用户提交的业务需求请求，该业务需求请求用于请求生成新的制度，中台服务器对业务需求请求进行ETL处理，获取业务子需求信息，这些业务子需求信息即制度的细节要求；而后根据业务子需求信息查找并调用对应的API。获取API对应的分类后的历史业务数据；根据预设的集成模板以及分类标签，将分类后的历史规则数据重组为新的规则。而后将生成的制度输入预设降重处理模型，去除制度内的重复部分，直接获取可用的新制度。预设降重处理模型为语义处理模型，用于去除重复语义。此外，API的生成过程包括：获取历史规则数据；并根据历史规则数据的规则类型以及规则应用场景，来为其添加对应的分类标签；而后根据分类标签将历史规则数据分类，并建立分类后的历史规则数据与API的关联联系。此外，在生成可用的新制度之后，还包括通过前台服务器反馈新规则给客户；并接收规则的使用报告信息；而后根据这些使用报告信息更新规则，提高规则的可复用性。

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

在一个实施例中，如图4所示，提供了一种业务数据处理装置，装置包括：

请求获取模块100，用于获取业务需求请求；

目的提取模块300，用于查找业务需求请求对应的业务目的信息；

数据调用模块500，用于根据业务目的信息查找对应分类标签，获取业务目的信息对应的历史业务数据；

数据重组模块700，用于对历史业务数据进行微服务编排，生成初始业务目的数据；

数据降重模块900，用于对初始业务目的数据进行降重处理，获取业务目的数据。

在其中一个实施例中，数据调用模块500用于：对业务需求请求进行ETL处理，获取业务子需求信息；根据业务子需求信息查找并调用对应的API，获取业务目的信息对应的历史业务数据，API由历史业务数据以API形式进行标签处理获得。

在其中一个实施例中，还包括数据分解模块，用于：获取历史业务数据；根据历史业务数据的业务类型以及业务应用场景，为历史业务数据添加对应的分类标签；根据分类标签将历史业务数据分类，并建立分类后的历史业务数据与API的关联联系。

在其中一个实施例中，API重组模块700用于：获取各API根据业务目的信息反馈的历史业务数据；根据预设的数据整合模板以及历史业务数据对应的分类标签，将反馈的历史业务数据整合为初始业务目的数据。

在其中一个实施例中，数据降重模块900用于：将初始业务目的数据输入预设降重处理模型，获取业务目的数据。

在其中一个实施例中，还包括反馈更新模块，用于：反馈业务目的数据；获取业务目的数据的使用报告信息；根据使用报告信息更新业务目的数据，并存储更新后的业务目的数据。

关于业务数据处理装置的具体限定可以参见上文中对于业务数据处理方法的限定，在此不再赘述。上述业务数据处理装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于电子设备中的处理器中，也可以以软件形式存储于电子设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

所述业务数据处理装置包括处理器和存储器，上述请求获取模块、目的提取模块、数据调用模块、数据重组模块和数据降重模块等均作为程序单元模块存储在存储器中，由处理器执行存储在存储器中的上述程序单元来实现相应的功能。

处理器中包含内核，由内核去存储器中调取相应的程序单元。内核可以设置一个或以上，通过调整内核参数来实现利用业务数据来处理问题的效果。

本发明实施例提供了一种存储介质，其上存储有程序，该程序被处理器执行时实现所述业务数据处理方法。

本发明实施例提供了一种处理器，所述处理器用于运行程序，其中，所述程序运行时执行所述业务数据处理方法。

如图5所示，本发明实施例提供了一种设备70，设备70包括至少一个处理器701、以及与处理器701连接的至少一个存储器702、总线703；其中，处理器701、存储器702通过总线703完成相互间的通信；处理器用于调用存储器中的程序指令，以执行上述的业务数据处理方法。本文中的设备70可以是服务器、PC、PAD、手机等。

本申请还提供了一种计算机程序产品，当在数据处理设备上执行时，适于执行初始化有如下方法步骤的程序：。

获取业务需求请求；

查找业务需求请求对应的业务目的信息；

确定业务目的信息对应的分类标签，根据分类标签查找业务目的信息对应的历史业务数据；

对历史业务数据进行微服务编排，生成初始业务目的数据；

对初始业务目的数据进行降重处理，获取业务目的数据。

在一个实施例中，计算机程序在数据处理设备上执行时还实现以下步骤：对业务需求请求进行ETL处理，获取业务子需求信息；根据业务子需求信息查找并调用对应的API，通过API获取业务目的信息对应的历史业务数据，API由历史业务数据以API形式进行标签处理获得。

在一个实施例中，计算机程序在数据处理设备上执行时还实现以下步骤：获取历史业务数据；根据历史业务数据的业务类型以及业务应用场景，为历史业务数据添加对应的分类标签；根据分类标签将历史业务数据分类，并建立分类后的历史业务数据与API的关联联系。

在一个实施例中，计算机程序在数据处理设备上执行时还实现以下步骤：获取各API根据业务目的信息反馈的历史业务数据；根据预设的数据整合模板以及历史业务数据对应的分类标签，将反馈的历史业务数据整合为初始业务目的数据。

在一个实施例中，计算机程序在数据处理设备上执行时还实现以下步骤：将初始业务目的数据输入预设降重处理模型，获取业务目的数据。

在一个实施例中，计算机程序在数据处理设备上执行时还实现以下步骤：反馈业务目的数据；获取业务目的数据的使用报告信息；根据使用报告信息更新业务目的数据，并存储更新后的业务目的数据。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

在一个典型的配置中，设备包括一个或多个处理器(CPU)、存储器和总线。设备还可以包括输入/输出接口、网络接口等。

存储器可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)，存储器包括至少一个存储芯片。存储器是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

以上仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims

1.一种业务数据处理方法，所述方法包括：

获取业务需求请求；

查找所述业务需求请求对应的业务目的信息；

2.根据权利要求1所述的方法，其特征在于，所述确定所述业务目的信息对应的分类标签，根据所述分类标签查找所述业务目的信息对应的历史业务数据包括：

对所述业务需求请求进行ETL处理，获取业务子需求信息；

根据所述业务子需求信息查找并调用对应的API，通过所述API获取所述业务目的信息对应的历史业务数据，所述API由历史业务数据以API形式进行标签处理获得。

3.根据权利要求2所述的方法，其特征在于，所述确定所述业务目的信息对应的分类标签，根据所述分类标签查找所述业务目的信息对应的历史业务数据之前，包括：

获取历史业务数据；

4.根据权利要求3所述的方法，其特征在于，所述对所述历史业务数据进行微服务编排，生成初始业务目的数据包括：

获取各API根据所述业务目的信息反馈的历史业务数据；

5.根据权利要求1所述的方法，其特征在于，所述对所述初始业务目的数据进行降重处理，获取业务目的数据包括：

6.根据权利要求1所述的方法，其特征在于，所述对所述初始业务目的数据进行降重处理，获取业务目的数据之后，还包括：

反馈所述业务目的数据；

接收所述业务目的数据的使用报告信息；

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

请求获取模块，用于获取业务需求请求；

数据调用模块，用于确定所述业务目的信息对应的分类标签，根据所述分类标签查找所述业务目的信息对应的历史业务数据；

8.根据权利要求1所述的装置，其特征在于，所述数据调用模块用于：

对所述业务需求请求进行ETL处理，获取业务子需求信息；

9.一种电子设备，所述电子设备包括至少一个处理器、以及与处理器连接的至少一个存储器、总线；其中，所述处理器、所述存储器通过所述总线完成相互间的通信；所述处理器用于调用所述存储器中的程序指令，以执行如权利要求1至6中任意一项所述方法的步骤。

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