CN112434011A - 一种增量数据的传输方法、装置、设备及存储介质 - Google Patents

Abstract

本申请公开了一种增量数据的传输方法、装置、设备及存储介质，该方法包括：接收用户输入的配置信息，所述配置信息用于描述待拉取的增量数据的数据范围；根据所述配置信息生成数据拉取请求，所述数据拉取请求包括增量应用程序编程接口API和所述配置信息；接收通过增量API传输的所述增量数据。该方法通过增量API的方式拉取增量数据，能够提高增量数据的拉取效率。

Description

一种增量数据的传输方法、装置、设备及存储介质

技术领域

本申请涉及数据处理领域，特别是涉及一种增量数据的传输方法、装置、设备及存储介质。

背景技术

应用系统中存储的数据是以业务数据为基础来展开的结构化数据。当应用系统中存储的结构化数据较少时，能够通过视图查询的方式来拉取增量数据，即拉取应用系统中发生变化的结构化数据。但是，在实际情况中，随着业务数据的增加，应用系统中存储的结构化数据也会越来越多，并且结构化数据也会越复杂。

当结构化数据越多且越复杂时，维护结构化数据所需要付出的工作量越大，并且降低通过视图查询的方式从应用系统中拉取增量数据的效率。

发明内容

为了解决上述技术问题，本申请提供了一种增量数据的传输方法，该方法通过增量应用程序编程接口(application programming interface，API)从源数据库中拉取增量数据，提高了拉取增量数据的效率。

本申请实施例公开了如下技术方案：

第一方面，本申请提供了一种增量数据的传输方法，包括：

接收用户输入的配置信息，所述配置信息用于描述待拉取的增量数据的数据范围；

根据所述配置信息生成数据拉取请求，所述数据拉取请求包括增量应用程序编程接口API和所述配置信息；

接收通过增量API传输的所述增量数据。

可选的，所述数据范围包括表和所述表中的字段。

可选的，所述接收通过增量API传输的所述增量数据，包括：

获取与所述字段相关联的第一版本标识；

当所述第一版本标识指示所述字段的内容发生变化时，接收通过增量API传输的所述增量数据。

可选的，所述获取所述字段相关联的第一版本标识，包括：

接收用户输入的第二配置信息，所述第二配置信息用于描述定时周期；

基于所述定时周期，获取与所述字段相关联的第一版本标识。

可选的，其特征在于，在所述接收通过增量API传输的所述增量数据之后，所述方法还包括：

根据所述增量数据对数据库中的结构化数据进行更新。

可选的，在所述根据所述增量数据对数据库中的结构化数据进行更新之后，所述方法还包括：

确定待推送的增量数据；

发送所述待推送的增量数据到分布式发布订阅消息系统的主题，以便订阅所述主题的客户端消费推送到所述主题中的增量数据。

可选的，其特征在于，所述接收用户输入的配置信息，包括：

向用户呈现辅助信息；

接收用户根据所述辅助信息输入的配置信息。

第二方面，本申请提供了一种增量数据的传输装置，包括：

接收模块，用于接收用户输入的配置信息，所述配置信息用于描述待拉取的增量数据的数据范围；

拉取模块，用于根据所述配置信息生成数据拉取请求，所述数据拉取请求包括增量应用程序编程接口API和所述配置信息；

所述接收模块，还用于接收通过增量API传输的所述增量数据。

第三方面，本申请提供了一种基于RPA模块的回复生成设备，所述设备包括：

存储器，用于存储计算机程序，并将所述计算机程序传输给所述处理器；

处理器，用于根据所述计算机程序中的指令执行权利要求1-7任一项所述的方法。

第四方面，本申请提供了一种计算机可读存储介质，所述计算机可读存储介质用于存储增量数据的传输系统所用的计算机软件指令，当所述计算机可读存储介质在计算机上运行时，使得计算机可以执行上述权利要求1至7中任一项所述的增量数据的传输方法。

由上述技术方案可以看出，本申请具有以下优点：

本申请提供的一种增量数据的传输方法，该方法通过业务系统实现。一方面，业务系统通过增量API从源数据库中拉取增量数据，用户能够自定义需要拉取的增量数据，而不是拉取全部的增量数据，实现了增量数据拉取的个性化配置，满足用户对增量数据的进行个性化配置的需求。另一方面，通过增量API的方式拉取增量数据，业务系统能够实现自动的接收通过增量API传输的增量数据，降低了维护人员的维护工作量，提高了拉取增量数据的效率。

附图说明

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

图1为本申请实施例提供的一种业务系统的系统架构图；

图2为本申请实施例提供的一种交互子系统的主界面的界面示意图；

图3为本申请实施例提供的又一种交互子系统的主界面的界面示意图；

图4为本申请实施例提供的再一种交互子系统的主界面的界面示意图；

图5为本申请实施例提供的一种增量数据的传输方法的方法流程图；

图6为本申请实施例提供的又一种增量数据的传输方法的方法流程图；

图7为本申请实施例提供的一种增量数据的传输装置的装置示意图；

图8为本申请实施例提供的一种增量数据的传输设备的设备示意图。

具体实施方式

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

为了便于理解，首先对本申请涉及的一些技术术语进行介绍。

数据拉取是指从原数据库中拉取数据到目标数据库中，数据拉取分为两种：全量数据的拉取和增量数据的拉取。全量数据的拉取是指将源数据库中的数据(例如：表、视图等结构化数据)直接拉取到目标数据库中，即将源数据库中的全部数据均复制到目标数据库中。进而目标数据库中新增加的数据为源数据库中的全部数据。而增量数据的拉取则是将源数据库中发生变化的数据拉取到目标数据库中，而不是将源数据库中的全部数据均拉去到目标数据库中。发生变化的数据可以是数据的增加、数据的删除、数据的修改等。增量数据的拉取与全量数据的拉取相比，增量数据的拉取仅将源数据库中发生变化的数据拉取到目标数据库中，而不是将全部数据拉取到目标数据库中更适用于对目标数据库中的数据进行更新。

目前，维护人员通过视图查询的方式来拉取增量数据，当源数据库中的数据较少时，维护人员能够准确的查询到哪些数据发生了变化，进而对发生变化的数据进行拉取。而当源数据库中的数据较多时，对维护人员来说，将会增加大量的工作量。举例说明，应用系统中存储的数据是结构化数据，并且随着业务数据的增加，应用系统中存储的结构化数据也会越来越多并且越复杂，维护人员难以通过视图查询的方式来确定哪些数据发生了变化，进而会降低拉取增量数据的效率。

为了解决上述问题，本申请实施例提供了一种增量数据的传输方法，该方法通过业务系统实现。具体地，业务系统接收用户输入的配置信息，该配置信息中描述了待拉取的增量数据的数据范围。业务系统根据包括待拉取的增量数据的数据范围生成数据拉取请求，数据拉取请求中包括增量应用程序编程接口(application programming interface，API)和配置信息。业务系统接收通过增量API传输增量数据，以供业务系统对增量数据的使用或进行后续的处理。

一方面，业务系统通过增量API从源数据库中拉取增量数据，用户能够自定义需要拉取的增量数据，而不是拉取全部的增量数据，实现了增量数据拉取的个性化配置，满足用户对增量数据的进行个性化配置的需求。另一方面，通过增量API的方式拉取增量数据，业务系统能够实现自动的接收通过增量API传输的增量数据，降低了维护人员的维护工作量，提高了拉取增量数据的效率。

本申请实施例提供的传输系统可以用于对源数据库中发生变化的结构化数据拉取到目标数据库中。源数据库可以为应用系统的数据库，应用系统的数据库中存储有大量的以客户为中心的结构化数据。目标数据库可以为业务系统的独立数据库，例如：A软件的数据库。其中，A软件仅是举例说明，并不构成对本申请的限定。A软件需要应用系统的数据库中存储的部分结构化数据，业务系统接收通过增量API传输应用系统中的增量数据。如此，不仅提高了拉取增量数据的效率，而且实现了自动化和个性化地拉取增量数据。

业务系统可以是软件系统，具体地，业务系统可以以计算机软件的形式部署在计算机设备中，以实现增量数据的拉取。在一些实施例中，业务系统也可以是硬件系统，该硬件系统包括具有拉取增量数据功能的物理设备。

如图1所示，业务系统100包括交互子系统120和业务子系统140。交互子系统120用于向用户提供图形用户界面(graphical user interface，GUI)，根据用户通过GUI触摸的操作，接收用户输入的配置信息。业务子系统140用于根据用户输入的配置信息生成数据拉取请求，数据拉取请求包括增量API和配置信息，接收通过增量API传输的增量数据。

交互子系统120包括通信单元122，通信单元124用于接收用户输入的配置信息，例如通过GUI接收配置信息。具体参见图2所示的交互子系统120的主界面的界面示意图，如图2所示，主界面200承载有模数选择组件220、输入组件240和拉取控件260。模式选择组件220用于选择数据拉取的模式。在一些实施例中，模式选择组件220包括增量数据模式控件222和全量数据模式控件224，用户可以通过点击增量数据模式控件222和全量数据模式控件224中的一个控件，来选择拉取数据的模式。本申请实施例以用户选择增量数据模式为例来介绍本申请实施例提供的业务系统100。

输入组件240用于用户输入配置信息，即用户输入待拉取的增量数据的数据范围。在一些实施例中，输入组件240包括提示信息242和输入控件244。用户可以根据提示信息242在输入控件244处输入待拉取的增量数据的数据范围。例如，当用户选择增量数据模式时，则应当在输入控件244处输入待拉取的增量数据的数据范围。

数据范围可以是待拉取的增量数据的表以及表中的字段。由于该数据范围可以由用户自行定义，因此，表中的字段可以为表中的部分字段，也可以为表中的全部字段。举例说明，源数据库中包括任务表、信息表等，任务表中包括优先级字段、时限字段、进度字段等，信息表中包括合同字段、项目字段、房间字段、建筑字段等。当用户需要拉取用户指定的增量数据时，用户可以在输入控件244处输入信息表以及信息表中的项目字段和房间字段，由此，用户可以实现对待拉取的增量数据的个性化配置。

拉取控件260用于触发生成数据拉取请求的指示信息，该数据拉取请求的指示信息用于指示生成数据拉取请求。

通信单元122还用于将数据拉取请求的指示信息传输至业务子系统140，以便业务子系统140进行后续的数据处理。具体地，业务子系统140包括通信单元142和请求单元144。通信单元142用于接收交互子系统120传输的数据拉取请求的指示信息，还用于接收通过增量API从源数据库中拉取的增量数据。请求单元144用于接收到数据拉取请求的指示信息后，根据配置信息生成数据拉取请求，数据拉取请求包括增量API和配置信息。其中，配置信息是由用户输入的、由用户个性化配置的待拉取的增量数据的数据范围。

通信单元142具体用于获取信息中的与项目字段和房间字段相关联的第一版本标识，项目字段或房间字段的内容发生变化时，接收通过增量API传输的增量数据。

在一些实施例中，如图3所示的交互子系统120的主界面的界面示意图，该主界面200还承载有获取周期控件280，获取周期控件280用于设置获取与项目字段和房间字段相关联的第一版本标识的获取周期指示信息，获取周期指示信息用于描述定时周期。当用户触发拉取控件260后，获取周期指示信息和数据拉取请求的指示信息将会一并通过交互子系统120的通信单元122传输给业务子系统140。业务子系统140的通信单元142具体用于基于定时周期获取第一版本标识，周期性判断第一版本标识指示的字段内容是否发生变化，进而实现周期性对增量数据的拉取。

在另外一些实施例中，如图4所示的交互子系统120的主界面的界面示意图，该主界面200还承载有拉取周期控件290用于设置拉取数据的周期。具体地，用户可以在拉取周期控件290处设置拉取数据的周期，生成拉取数据的周期指示信息，拉取数据的周期指示信息用于指示数据拉起的周期。当用户触发拉取控件260后，拉取数据的周期指示信息和数据拉取请求的指示信息将会一并通过通信单元122传输给业务子系统140。进而业务子系统140的通信单元144接收到拉取数据的周期指示信息，以便业务子系统根据拉取数据的周期指示信息所指示的拉取数据的周期，来周期性的从源数据库中拉取增量数据。

在另外一些实施例中，当业务子系统140自身有定时计时功能时，用户无需手动输入拉取数据的周期，业务子系统140可以根据自身的定时计时信息来周期性的拉取增量数据。

业务子系统140还包括更新单元146和推送单元148。更新单元146用于在通信单元142接收通过增量API传输的增量数据后，利用接收到的增量数据对业务系统本地的数据库中的结构化数据进行更新，具体可以为替换本地数据库中的结构化数据或对本地数据库中的结构化数据进行修正等。考虑到其他外围的应用客户端可能会用到相同的增量数据，此时，业务系统100可以作为消费者将增量数据推送到分布式订阅消息系统的主题。具体地，推送单元148可以在更新单元146对本地数据库中的结构化数据更新后，确定待推送的增量数据，将待推送的增量数据发送到分布式订阅消息系统的主题，以便订阅该主题的客户端消费被推送到主题中的增量数据。

为了使得本申请的技术方案更加清楚、易于理解，下面将从业务系统100的角度对本申请实施例提供的增量数据的传输方法进行详细说明。

参见图5所示的增量数据的传输方法的流程图，该方法包括：

S502：业务系统100接收用户输入的配置信息。

业务系统100可以通过用户界面如GUI接收用户输入的配置信息，其中，配置信息用于描述待拉取的增量数据的数据范围。例如，数据范围可以为待拉取的增量数据的表以及表中用户指定字段。由此，用户可以自定义要关注哪些数据，即对哪些数据的增量数据进行拉取，而不是拉取全部的增量数据。

在一些实施例中，用户可以仅仅拉取指定表中的指定字段的增量数据。在另一些实施例中，用户可以根据不同的场景输入不同的配置信息。具体地，业务系统100向用户呈现辅助信息，辅助信息用于辅助用户输入配置信息，业务系统100接收用户根据辅助信息输入的配置信息。例如，辅助信息具体可以是体现当前应用系统具体是游戏应用系统，还是音乐应用系统，或者是单据应用系统，业务系统100向用户呈现辅助信息后，用户能够根据辅助信息确定被拉取的应用系统具体为什么应用系统，进而输入配置信息。

S504：业务系统100根据配置信息生成数据拉取请求。

数据拉取请求中包括增量API和配置信息。其中，配置信息用于用户自定义增量API要拉取的增量数据的配置信息。业务系统100根据配置信息生成数据拉取请求，数据拉取请求用于从源数据库中拉取增量数据，例如源数据库可以为应用系统的数据库，该数据库中存储有大量结构化数据。

考虑到源数据库中存储有大量的结构化数据且复杂，本申请实施例中业务系统100通过源数据库提供的增量API来拉取增量数据，由此能够降低维护人员对大量结构化数据的维护工作量，同时，进一步提高了拉取增量数据的效率。由于业务系统100根据配置信息生成数据拉取请求，而配置信息由用户自定义，由此进一步提高了拉取增量数据的灵活性。

S506：业务系统100接收通过增量API传输的增量数据。

业务系统100生成数据拉取请求后，通过源数据库上的增量API来拉取配置信息所指示的增量数据，进而接收通过增量API传输的增量数据。

在一些可能的实现方式中，业务系统100确定配置信息中描述的待拉取数据的数据范围，例如数据范围为信息表以及信息表中的房间字段和建筑字段。业务系统100获取与房间字段和建筑字段相关联的第一版本标识。该第一版本标识的内容可以是字符串，也可以是其他形式的内容。该第一版本标识用于表示房间字段和建筑字段的内容变化情况。例如，当第一版本标识发生变化时，则即可确定房间字段或建筑字段的内容发生变化。此时，业务系统100可以接收通过增量API传输的增量数据，即房间字段或建筑字段的内容发生变换的数据。

举例说明，以第一版本标识的内容为字符串为例，例如，与房间字段相关联的第一版本标识为A1，第一版本标识的内容为“0000”。当房间字段的内容发生变化时，A1的内容“0000”在原有数值的基础上增加一个计数单位，即A1由于“0000”变化为“0001”。业务系统100确定A1发生变化后，即可确定源数据库中的房间字段的内容发生变化。业务系统100可以接收通过增量API传输的增量数据。

在另一种可能的实现方式中，考虑到业务系统100可能会同时接受两种配置信息所指示的数据范围的对应的增量数据。举例说明，业务系统100接收的用户输入的配置信息中的数据范围包括多个表且每个表包括多个指定字段时，例如，数据范围包括Q表和W表，其中，Q表包括Q1字段和Q2字段，W表包括W1字段。业务系统100基于配置信息，生成数据拉取请求，以指示拉取源数据库中与Q表的Q1字段和Q2字段相关的增量数据，以及W表的W1字段相关的增量数据。由此，通过多个增量API来实现多线程的方式拉取增量数据，例如，通过第一增量API拉取Q表中Q1字段和Q2字段相关的增量数据，通过第二增量API拉取W表中W1字段相关的增量数据。由此实现业务系统接收通过多个增量API拉取的增量数据，进一步提高了拉取增量数据的效率。

由上可知，本申请实施例提供了一种增量数据的传输方法。该方法中，业务系统100接收用户输入的配置信息，配置信息用于描述待拉取的增量数据的数据范围。然后业务系统100根据该数据范围生成数据拉取请求，数据拉取请求包括增量API和配置信息，该数据拉取请求用于请求通过增量API根据配置信息拉取增量数据。进而业务系统100接收通过增量API拉取的增量数据。

一方面，业务系统100通过增量API从源数据库中拉取增量数据，用户能够自定义需要拉取的增量数据，而不是拉取全部的增量数据，实现了增量数据拉取的个性化配置，满足用户对增量数据的进行个性化配置的需求。另一方面，业务系统100通过增量API的方式拉取增量数据，能够实现自动的拉取增量数据，降低了维护人员的维护工作量，提高了拉取增量数据的效率。

以上介绍了业务系统100接收通过增量API传输的增量数据，下面介绍业务系统100在接收增量数据后，对增量数据的处理。参见图6所示的增量数据的传输方法的流程图，该方法在S502-S506的基础上还包括：

S508：业务系统100根据增量数据对数据库中的结构化数据进行更新。

业务系统100接收通过增量API传输的增量数据后，业务系统100可以更加该增量数据对业务系统100自身的数据库中的结构化数据进行更新。例如，业务系统100对根据待拉取的增量数据的数据范围所指示的表和表中的字段的内容，利用增量数据对业务系统100自身的数据库中的结构化数据进行更新(例如修改或替换等)。

S510：业务系统100确定待推送的增量数据。

考虑到其他应用客户端可能会用到业务系统100接收到的增量数据，当业务系统100确定自身的数据库中的结构化数据更新完成后，业务系统100还可以将自身的数据库中进行更新的数据确定为待推送的增量数据。具体地，业务系统100可以通过获取业务系统100自身数据库中的表以及表中的字段对应的第二版本标识号，当第二版本标识号发生变化时，即可确定业务系统100完成对自身的数据库的更新。

其中，业务系统100通过第二版本标识号发生变化来确定业务系统100完成对自身的数据库的更新的原理与业务系统根据第一版本标识号确定与所述第一版本标识号对应的字段的内容发生变化相类似，此处不再赘述。

业务系统100可以根据其他应用客户端的需求，确定待推送的增量数据的权重，根据该待推送的增量数据的权重确定待推送的增量数据，待推送的增量数据可以是权重第一的增量数据，也可以是权重前二的增量数据，本申请实施例对此不限定。进而，其他应用客户端无需二次拉取增量数据。

S512：业务系统100发送待推送的增量数据到分布式发布订阅消息系统的主题。

业务系统100确定待推送的增量数据后，业务系统100可以作为生产者的身份，将待推送的增量数据发送到分布式发布订阅消息系统的主题。具体地，业务系统根据待推送的增量数据生成json字符串，将该json字符串推送到分布式发布订阅消息系统的主题中，分布式发布订阅消息系统可以是kafka。进而其他应用客户端可以以消费者的身份消费主题中的增量数据，对于其他应用客户端而言，无需进行二次拉取增量数据，仅由业务系统100拉取一次增量数据即可，降低系统运行开销。

在一些实施例中，业务系统100可以根据第一类应用客户端的需求确定待推送的第一增量数据，根据第二类客户端的需求确定待推送的第二增量数据。其中，考虑到第一类应用客户端和第二类应用客户端的需求不同，由此业务系统100可以将第一增量数据推送到分布式发布订阅消息系统的第一主题中，将第二增量数据推送到分布式发布订阅消息系统的第二主题中，即分别将第一增量数据和第二增量数据推送到分布式发布订阅消息系统的不同主题中。进而订阅了第一主题的第一类应用客户端可以在第一主题中消费第一增量数据，订阅了第二主题的第二类应用客户端可以在第二主题中消费第二增量数据。由此，业务系统100可以实现将增量数据发推送到分布式发布订阅消息系统的不同主题中，满足不同的应用客户端对增量数据的拉取需求。对于其他应用客户端而言，无需二次开发，即消费自身订阅的主题中的增量数据。

需要说明的是，是本申请实施例中采取springboot框架，利用远程字典服务(remote dictionary server，redis)、kafka、mysql技术，基于增量API的方式从源数据库中拉取增量数据，对待拉取的增量数据支持用户个性化的配置。进一步，业务系统100将增量数据推送到分布式发布订阅消息系统的主题中，以便订阅该主题的其他应用客户端消费该主题中的增量数据。

以上结合图1至图6对本申请实施例提供的增量数据的传输方法进行介绍，接下来结合附图对本申请实施例提供的增量数据的传输装置以及用于实现增量数据的传输装置功能的计算设备进行介绍。

如图7所示，本申请实施例还提供一种增量数据的传输装置700，该装置700用于执行前述增量数据的传输方法。本申请实施例对该装置700中的功能模块的划分不做限定，下面示例性地提供一种功能模块的划分：

增量数据的传输装置700包括接收模块702和拉取模块704。

接收模块702，用于接收用户输入的配置信息，所述配置信息用于描述待拉取的增量数据的数据范围。拉取模块704，用于根据所述配置信息生成数据拉取请求，所述数据拉取请求包括增量应用程序编程接口API和所述配置信息。接收模块702，还用于接收通过增量API传输的所述增量数据。

上述增量数据的传输装置700可以通过计算设备实现。图8提供了一种计算设备，如图8所示，计算设备800具体可以用于实现上述图7所示实施例中增量数据的传输装置700的功能。

计算设备800包括总线801、处理器802、显示器803和存储器804。处理器802、存储器804和显示器803之间通过总线801通信。

处理器802可以为中央处理器(central processing unit，CPU)、图形处理器(graphics processing unit，GPU)、微处理器(micro processor，MP)或者数字信号处理器(digital signal processor，DSP)等处理器中的任意一种或多种。

显示器803是一种输入输出(input/output，I/O)设备。该设备可以将电子文件如图像、文字显示到屏幕上，以供用户查看。根据制造材料不同，显示器803可以分为液晶显示器(liquid crystal display，LCD)、有机电激光(organic light emitting diode，OLED)显示器等。具体地，显示器803可以通过GUI接收配置信息。

存储器804可以包括易失性存储器(volatile memory)，例如随机存取存储器(random access memory，RAM)。存储器804还可以包括非易失性存储器(non-volatilememory)，例如只读存储器(read-only memory，ROM)，快闪存储器，机械硬盘(hard drivedrive，HDD)或固态硬盘(solid state drive，SSD)。

存储器804中存储有可执行的程序代码，处理器802执行该可执行的程序代码以执行前述增量数据的传输方法。具体地，处理器802执行上述程序代码，以控制显示器803通过GUI接收配置信息，所述配置信息包括用于描述待拉取的增量数据的数据范围，显示器803还用于接收通过增量API传输的增量数据，然后处理器802根据所述配置信息生成拉取请求所述数据拉取请求包括增量应用程序编程接口API和所述配置信息。

本申请实施例还提供了一种计算机可读存储介质。所述计算机可读存储介质可以是计算设备能够存储的任何可用介质或者是包含一个或多个可用介质的数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘)等。该计算机可读存储介质包括指令，所述指令指示计算设备执行上述应用于业务系统的增量数据的传输方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元及模块可以是或者也可以不是物理上分开的。另外，还可以根据实际的需要选择其中的部分或者全部单元和模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

应当理解，在本申请中，“至少一个(项)”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，用于描述关联对象的关联关系，表示可以存在三种关系，例如，“A和/或B”可以表示：只存在A，只存在B以及同时存在A和B三种情况，其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b或c中的至少一项(个)，可以表示：a，b，c，“a和b”，“a和c”，“b和c”，或“a和b和c”，其中a，b，c可以是单个，也可以是多个。

以上，仅是本申请的较佳实施例而已，并非对本申请作任何形式上的限制。虽然本申请已以较佳实施例揭露如上，然而并非用以限定本申请。任何熟悉本领域的技术人员，在不脱离本申请技术方案范围情况下，都可利用上述揭示的方法和技术内容对本申请技术方案做出许多可能的变动和修饰，或修改为等同变化的等效实施例。因此，凡是未脱离本申请技术方案的内容，依据本申请的技术实质对以上实施例所做的任何简单修改、等同变化及修饰，均仍属于本申请技术方案保护的范围内。

Claims (10)

1.一种增量数据的传输方法，其特征在于，包括：

接收用户输入的配置信息，所述配置信息用于描述待拉取的增量数据的数据范围；

根据所述配置信息生成数据拉取请求，所述数据拉取请求包括增量应用程序编程接口API和所述配置信息；

接收通过增量API传输的所述增量数据。

2.根据权利要求1所述的方法，其特征在于，所述数据范围包括表和所述表中的字段。

3.根据权利要求2所述的方法，其特征在于，所述接收通过增量API传输的所述增量数据，包括：

获取与所述字段相关联的第一版本标识；

当所述第一版本标识指示所述字段的内容发生变化时，接收通过增量API传输的所述增量数据。

4.根据权利要求3所述的方法，其特征在于，所述获取所述字段相关联的第一版本标识，包括：

接收用户输入的第二配置信息，所述第二配置信息用于描述定时周期；

基于所述定时周期，获取与所述字段相关联的第一版本标识。

5.根据权利要求1-4任一项所述的方法，其特征在于，在所述接收通过增量API传输的所述增量数据之后，所述方法还包括：

根据所述增量数据对数据库中的结构化数据进行更新。

6.根据权利要求5所述的方法，其特征在于，在所述根据所述增量数据对数据库中的结构化数据进行更新之后，所述方法还包括：

确定待推送的增量数据；

发送所述待推送的增量数据到分布式发布订阅消息系统的主题，以便订阅所述主题的客户端消费推送到所述主题中的增量数据。

7.根据权利要求1-6任一项所述的方法，其特征在于，所述接收用户输入的配置信息，包括：

向用户呈现辅助信息；

接收用户根据所述辅助信息输入的配置信息。

8.一种增量数据的传输装置，其特征在于，包括：

接收模块，用于接收用户输入的配置信息，所述配置信息用于描述待拉取的增量数据的数据范围；

拉取模块，用于根据所述配置信息生成数据拉取请求，所述数据拉取请求包括增量应用程序编程接口API和所述配置信息；

所述接收模块，还用于接收通过增量API传输的所述增量数据。

9.一种增量数据的传输设备，其特征在于，所述设备包括：

存储器，用于存储计算机程序，并将所述计算机程序传输给所述处理器；

处理器，用于根据所述计算机程序中的指令执行权利要求1-7任一项所述的方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质用于存储增量数据的传输系统所用的计算机软件指令，当所述计算机可读存储介质在计算机上运行时，使得计算机可以执行上述权利要求1至7中任一项所述的增量数据的传输方法。

Images