CN111177232B

CN111177232B - 一种数据处理方法、装置、系统和存储介质

Info

Publication number: CN111177232B
Application number: CN201811331714.5A
Authority: CN
Inventors: 涂敬伟
Original assignee: China Mobile Communications Group Co Ltd; China Mobile Suzhou Software Technology Co Ltd
Current assignee: China Mobile Communications Group Co Ltd; China Mobile Suzhou Software Technology Co Ltd
Priority date: 2018-11-09
Filing date: 2018-11-09
Publication date: 2022-12-13
Anticipated expiration: 2038-11-09
Also published as: CN111177232A

Abstract

本发明公开了一种数据处理方法、装置、系统和存储介质，解决了ETL系统不停服升级的问题，降低数据处理延迟，提高ETL系统的可靠性。所述数据处理方法，包括：在服务启动之后，根据当前系统时间和任务调度表中记录的下次调度时间判断是否存在遗漏调度周期，如果判断出存在遗漏调度周期，则将任务调度表中下次调度时间增加一个调度周期，以及将维护的遗漏周期计数参数加1后，返回执行根据当前系统时间和任务调度表中记录的下次调度时间判断是否存在有漏调度周期的步骤，直至得到的下次调度时间大于当前系统时间为止，根据遗漏周期计数向执行引擎提交执行任务。

Description

一种数据处理方法、装置、系统和存储介质

技术领域

本发明涉及数据处理技术领域，尤其涉及一种数据处理方法、装置、系统和存储介质。

背景技术

ETL(Extract-Transform-Load,数据抽取、转换和装载)是构建数据仓库的重要一环，用户从数据源抽取出所需的数据，经过数据清洗，最终按照预先定义好的数据仓库模型，将数据加载到数据仓库中去。当前ETL工具基本上都内置集成或借助第三方的调度工具实现其调度功能，在正常情况下，可以满足基本的流程作业周期自动调度的需求。但是，ETL系统发生故障或对ETL系统进行升级时，不可避免的会有停止ETL系统服务的操作。这时，就会造成业务周期调度的中断，对业务产生较大的影响。

一般情况下，为了使调度不遗漏调度任务，需要ETL的运维人员在ETL系统恢复正常或升级完成之后，检查ETL系统上布置的所有的业务流程，手动执行遗漏的周期或恢复执行失败的周期实例来确保业务的正常执行，每一次ETL的故障或升级操作，在系统上所有流程定时任务的执行检查和恢复会给运维人员带来很大的工作量，降低了数据处理效率；另一方面，这种人为的手工操作，还会延长服务的不可用时间，可能出现恢复流程执行操作时长大于ETL不可靠(故障或升级)时长，增加数据处理延迟；而且当ETL系统上流程较多的时候，这种纯粹依靠人力的恢复操作，极其容易遗漏流程，导致周期性的流程任务遗漏周期、数据丢失等非常严重的后果，降低了ETL系统的可靠性。

发明内容

本发明实施例提供一种数据处理方法、装置、系统和存储介质，解决了ETL系统不停服升级的问题，降低数据处理延迟，提高ETL系统的可靠性。

第一方面，提供一种数据处理方法，包括：

在服务启动之后，根据当前系统时间和任务调度表中记录的下次调度时间判断是否存在遗漏调度周期；

如果判断出存在遗漏调度周期，则将所述任务调度表中下次调度时间增加一个调度周期，以及将维护的遗漏周期计数参数加1后，返回执行根据当前系统时间和任务调度表中记录的下次调度时间判断是否存在有漏调度周期的步骤，直至得到的下次调度时间大于当前系统时间为止；

根据所述遗漏周期计数向执行引擎提交执行任务。

可选地，根据当前系统时间和任务调度表中记录的下次调度时间判断是否存在有漏调度周期，具体包括：

比较当前系统时间与所述下次调度时间，若所述当前系统时间大于所述下次调度时间，则确定存在遗漏调度周期；

若所述当前系统时间小于所述下次调度时间，则确定不存在遗漏调度周期。

可选地，在根据所述遗漏周期计数向执行引擎提交执行任务之前，还包括：

确定所述执行引擎的状态；以及

根据确定出的执行引擎状态，确定提交执行任务的提交方式；以及

根据所述遗漏周期计数向执行引擎提交执行任务，具体包括：

根据所述遗漏周期计数，使用确定出的提交方式向执行引擎提交执行任务。

可选地，执行引擎的状态包括可靠状态，不可靠状态和半可靠状态；以及

根据确定出的执行引擎状态，确定提交执行任务的提交方式，具体包括：

如果确定出的执行引擎状态为可靠状态或者半可靠状态，则确定提交执行任务的提交方式为接口调用提交方式；

如果确定出的执行引擎状态为不可靠状态，则确定提交执行任务的提交方式为消息队列方式。

可选地，确定所述执行引擎的状态，具体包括：

在可靠状态下接收到所述执行引擎提交任务失败的状态信息时，启动第一计时器并对提交任务失败次数进行计数；

如果在第一预设时长内提交任务失败次数达到第一预设阈值，则确定所述执行引擎的状态为不可靠状态。

可选地，在确定所述执行引擎的状态为不可靠状态之后，还包括：

启动第二计时器；

在所述第二计时器的计时时长超过第二预设时长时，确定所述执行引擎的状态为半可靠状态。

可选地，在确定所述执行引擎的状态为半可靠状态之后，还包括：

启动第三计时器；以及

分别对提交任务成功次数和失败次数进行计数；

如果在第三预设时长内提交任务成功次数达到第二预设阈值，则确定所述执行引擎的状态为可靠状态；

在所述第三计时器计时期间，如果提交任务失败次数达到第三预设阈值，则确定所述执行引擎的状态为不可靠状态。

第二方面，提供另外一种数据处理方法，所述方法包括：

在向执行引擎提交任务之前，确定所述执行引擎的状态；

根据确定出的执行引擎状态，确定提交执行任务的提交方式；

使用确定出的提交方式向执行引擎提交执行任务。

可选地，确定所述执行引擎的状态，具体包括：

启动第二计时器；

启动第三计时器；以及

分别对提交任务成功次数和失败次数进行计数；

第三方面，提供一种数据处理装置，包括：

判断单元，用于在服务启动之后，根据当前系统时间和任务调度表中记录的下次调度时间判断是否存在遗漏调度周期；

处理单元，用于如果判断出存在遗漏调度周期，则将所述任务调度表中下次调度时间增加一个调度周期，以及将维护的遗漏周期计数参数加1后，返回执行根据当前系统时间和任务调度表中记录的下次调度时间判断是否存在有漏调度周期的步骤，直至得到的下次调度时间大于当前系统时间为止；

任务提交单元，用于根据所述遗漏周期计数向执行引擎提交执行任务。

可选地，所述判断单元，具体用于比较当前系统时间与所述下次调度时间，若所述当前系统时间大于所述下次调度时间，则确定存在遗漏调度周期；若所述当前系统时间小于所述下次调度时间，则确定不存在遗漏调度周期。

可选地，本发明实施例提供的数据处理装置还包括第一确定单元和第二确定单元，其中：

所述第一确定单元，用于在所述任务提交单元根据所述遗漏周期计数向执行引擎提交执行任务之前，确定所述执行引擎的状态；

所述第二确定单元，用于根据确定出的执行引擎状态，确定提交执行任务的提交方式；

所述任务提交单元，用于根据所述遗漏周期计数，使用确定出的提交方式向执行引擎提交执行任务。

所述第二确定单元，用于如果所述第一确定单元确定出的执行引擎状态为可靠状态或者半可靠状态，则确定提交执行任务的提交方式为接口调用提交方式；如果所述第一确定单元确定出的执行引擎状态为不可靠状态，则确定提交执行任务的提交方式为消息队列方式。

可选地，所述第一确定单元，用于在可靠状态下接收到所述执行引擎提交任务失败的状态信息时，启动第一计时器并对提交任务失败次数进行计数；如果在第一预设时长内提交任务失败次数达到第一预设阈值，则确定所述执行引擎的状态为不可靠状态。

可选地，所述第一确定单元，还用于在确定所述执行引擎的状态为不可靠状态之后，启动第二计时器；在所述第二计时器的计时时长超过第二预设时长时，确定所述执行引擎的状态为半可靠状态。

可选地，所述第一确定单元，还用于在确定所述执行引擎的状态为半可靠状态之后，启动第三计时器；分别对提交任务成功次数和失败次数进行计数；如果在第三预设时长内提交任务成功次数达到第二预设阈值，则确定所述执行引擎的状态为可靠状态；在所述第三计时器计时期间，如果提交任务失败次数达到第三预设阈值，则确定所述执行引擎的状态为不可靠状态。

第四方面，提供另外一种数据处理装置，包括：

第一确定单元，用于在向执行引擎提交任务之前，确定所述执行引擎的状态；

第二确定单元，用于根据确定出的执行引擎状态，确定提交执行任务的提交方式；

任务提交单元，用于使用确定出的提交方式向执行引擎提交执行任务。

所述第二确定单元，具体用于如果确定出的执行引擎状态为可靠状态或者半可靠状态，则确定提交执行任务的提交方式为接口调用提交方式；如果确定出的执行引擎状态为不可靠状态，则确定提交执行任务的提交方式为消息队列方式。

可选地，所述一种数据处理系统，包括调度服务装置和执行引擎，其中所述调度服务装置设置有上述任一数据处理装置。

本发明实施例提供的数据处理方法、装置、系统和存储介质，针对调度服务系统，在服务启动之后，根据当前系统时间和任务调度表中记录的下次调度时间判断是否存在遗漏调度周期，在遗漏周期的情况下将任务调度表中下次调度时间增加一个调度周期，以及将维护的遗漏周期计数参数加1，循环此过程，直至得到的下次调度时间大于当前系统时间为止，根据所述遗漏周期计数向执行引擎提交执行任务，实现自动补周期，相比于通过人工补周期，降低了数据处理延迟，提高了ETL系统的可靠性。

针对执行引擎，将执行引擎的状态分为可靠状态、不可靠状态、半可靠状态，调度服务在向执行引擎系统提交任务之前，首先判断执行引擎的状态，根据判断出的状态来确定向执行引擎提交任务的方式，避免了因为执行引擎不可靠而导致提交的任务没有响应或提交失败。

本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本发明的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1为根据本发明实施方式的ETL系统结构示意图；

图2为根据本发明实施方式的业务、调度服务、执行引擎的关系示意图；

图3为根据本发明实施方式的数据处理方法的实施流程示意图；

图4为根据本发明实施方式的自动补周期流程示意图；

图5为根据本发明实施方式的执行引擎状态转换示意图；

图6为根据本发明实施方式的基于执行引擎升级时的实施流程示意图；

图7为根据本发明实施方式的第一种数据处理装置的结构示意图；

图8为根据本发明实施方式的第二种数据处理装置的结构示意图；

图9为根据本发明实施方式的计算装置图；

图10为本发明实施例提供的数据处理系统的结构示意图。

具体实施方式

为了解决ETL系统不停服升级的问题，降低数据处理延迟，提高ETL系统的可靠性，本发明实施例提供了一种数据处理方法、装置、系统和存储介质。

需要说明的是，本发明实施例中不停服升级不是指在升级操作时，不停止ETL系统的运行。而是指在升级期间不影响已经发布的流程的周期性调度执行。

以下结合说明书附图对本发明的优选实施例进行说明，应当理解，此处所描述的优选实施例仅用于说明和解释本发明，并不用于限定本发明，并且在不冲突的情况下，本发明中的实施例及实施例中的特征可以相互组合。

如图1所示，其为ETL系统结构示意图，该系统是一个实现了前后端分离的，趋向于微服务框架的ETL系统。ETL系统由五个子系统组成，分别Web Service(网络服务)、Component Service(组件服务)、Rest Service(中间件)、Scheduler Service(调度服务)、YAFE(执行引擎)，五个服务之间分别通过接口调用方式(Rest API)或消息队列方式进行交互。其中：

Web Service：提供数据流和控制流开发的IDE(集成开发环境)环境，用户可通过托拉拽的方式完成工作流的设计及基本管理。

Component Service：组件资源池，为Web Service服务提供数据流和控制流开发组件。

Rest服务：ETL系统的中间件。为Web Service提供接口服务。

Scheduler Service：ETL系统的调度服务，为ETL提供调度策略。支持单次调度和按月、周、日、时、分为周期的周期调度。

YAFE：ETL系统的执行引擎，调度触发的执行实例将传给执行引擎，由执行引擎完成参数的封装，然后提交任务到集群，开启作业执行。

ETL系统拆分之后，相比于单体的ETL系统，可以选择对系统进行整体升级或根据需求针对某一个服务进行局部升级。但是不管是整体升级还是局部升级。Scheduler服务和YAFE引擎的停止，都会对线上业务产生比较大的影响。

所以要实现逻辑上的不停服升级，要解决两个问题：

(1)流程调度的触发应该不受Scheduler服务的影响，不遗漏数据周期。

(2)提交任务应该不受YAFE的影响，不会因为YAFE引擎的起停而出现批量的任务执提交无响应或失败。

如图2所示，其为业务流程、调度和引擎之间的关系示意图，由业务流程创建调度任务，并将调度任务提交至调度服务，调度服务系统启动、触发调度时间表(Schedule)，将任务提交给执行引擎，由执行引擎执行任务。

本发明实施例中，在ETL系统不可靠(如故障或升级)时，为了保证ETL系统上搭建的流程按照预先设定的调度规则进行周期性的调度执行，针对调度服务配置自动补周期，在向执行引擎提交任务时，调度服务判断执行引擎的状态，选择与之状态相对应的任务提交方式，一方面，解决了流程调度的触发不受调度服务的影响，不因系统不可靠遗漏数据，另一方面，在提交任务时不受执行引擎的影响，不因为执行引擎系统的起停而出现任务提交无响应或者提交任务失败。

如图3所示，其为本发明实施例提供的数据处理方法的实施流程示意图，该方法可以应用于调度服务，包括以下步骤：

S31、在服务启动之后，根据当前系统时间和任务调度表中记录的下次调度时间判断是否存在遗漏调度周期，如果是，执行步骤S32，如果否，流程结束。

为了更好地理解本发明实施例，以下对ETL调度过程进行简单介绍。在ETL系统中，用户创建的每一个业务流程flow都会与一个调度schedule(任务调度表)一一对应。调度可以简单的理解为ETL用户为流程flow创建的定时执行计划。比如为流程A创建调度schedule_A(初始值)如表1所示。

表1

ETL上流程的调度多为周期性的调度。比如schedule_A，定义了period、nextScheduleTime、nextDataTime等参数。每当任务触发一次，下次调度时间和下次数据时间也随着发生改变。比如2017-10-01 00:00这次的任务已经被触发执行，则schedule_A被重置为表2所示。

表2

本发明实施例中，调度服务在每次启动时，对于每一个流程需要判断是否有遗漏周期，遗漏了多少个周期以及将遗漏的周期自动恢复执行。

具体实施时，调度服务可以比较当前系统时间与所述下次调度时间，若当前系统时间大于下次调度时间，则确定存在遗漏调度周期；若当前系统时间小于下次调度时间，则确定不存在遗漏调度周期。

S32、将任务调度表中下次调度时间增加一个调度周期，以及将维护的遗漏周期计数参数加1。

具体实施时，调度服务可以维护一个遗漏周期计数，每判断出一个遗漏周期，将任务调度表中下次调度时间增加一个调度周期，并将遗漏周期计数增加1。

具体地，调度服务可以维持一个初始值为0的变量missFire。在调度服务启动时，根据当前系统时间与任务调度表中记录的下次调度时间nextScheduleTime进行比较，如果系统时间大于下次调度时间，则对调度的nextSchedulerTime值加上一个周期period，并将missFired的值也进行同步加一操作。循环上述过程，直到nextSchedulerTime的值大于当前时间为止。然后根据missFire值和调度方式(并行和串行)，向YAFE提交任务，补充执行遗漏的周期。自动补周期流程图如图4所示。图4所示的根据所述遗漏周期计数向执行引擎提交执行任务的流程如下：若遗漏周期计数参数等于0，则等待提交任务，若遗漏周期计数参数大于0，则对补充的周期任务判断是否是并行的，若并行则将所有遗漏周期同时执行任务提交，若是串行，则按顺序执行任务提交。

S33、判断任务调度表中记录的下次调度时间是否大于当前系统时间，如果是，则执行步骤S34，否则，执行步骤S31。

S34、根据遗漏周期计数向执行引擎提交执行任务。

具体实施时，为了避免由于执行引擎不可靠导致的任务提交无响应或者失败，本发明实施例中，根据所述遗漏周期计数向执行引擎提交执行任务之前，还要对所述执行引擎的状态进行确认，根据确定出的执行引擎的状态，确定提交执行任务的提交方式，再根据所述遗漏周期计数，使用确定出的提交方式向执行引擎提交执行任务。调度服务可以通过两种方式向YAFE引擎提交任务，一种是接口调用(Rest API)方式，一种是基于消息队列(Kafka)的方式。

本发明实施例中，将执行引擎的状态分为可靠状态，不可靠状态和半可靠状态。如果确定出的执行引擎状态为可靠状态或者半可靠状态，则调度服务确定提交执行任务的提交方式为接口调用提交方式；如果确定出的执行引擎状态为不可靠状态，则确定提交执行任务的提交方式为消息队列方式。

如图5所示，其为本发明实施例提供的执行引擎状态转换示意图，正常情况下，认为YAFE引擎处于健康运行的可靠状态。能够及时的对调度服务提交的任务进行处理，并返回成功的状态信息。此时，选择API的方式提交任务。如图5所示，Scheduler端通过设定并维持3个变量failCount(失败次数)、timeUpper(第一计时器)、failUpperLimit(失败次数上限)来记录任务提交结果，并以此来判定YAFE引擎的后续状态。

如图5所示，失败次数计数器failCount记录调度服务任务提交失败次数，time1为第一预设时长，failUpperLimit为失败次数上限。在时间time1内，如果任务提交失败次数failCount>＝failUpperLimit。则确定调度服务YAFE引擎为不可靠状态。这时如果再通过API的方式向YAFE引擎提交任务，就会有很大的几率得不到响应或返回一个失败的结果，导致任务执行失败。

在YAFE处于不可靠状态时，Scheduler服务会维持一个时长阈值time2。在time2时间段内，Scheduler可以选择通过基于消息队列的Kafka来提交任务。而提交的任务会存储在Kafka Topic队列中。当YAFE引擎启动或恢复正常时，YAFE消费Kafka消息，来触发执行任务。

当超出时间time2之后，Scheduler服务默认为YAFE处于半可靠状态。YAFE处于半可靠状态时，Scheduler设定并维持3个变量successCount、timeUppere和successLowerLimit来记录与YAFE响应结果和判定YAFE的后续状态。

在YAFE引擎半可靠状态时，Scheduler开始尝试通过API的方式提交任务，通过successCount来记录任务提交成功次数。在time3时间段内，当任务提交成功次数successCount>＝successLowerLimit时，认为YAFE引擎已经恢复，判定YAFE为可靠状态，Scheduler服务开始使用API方式向YAFE提交任务。否则，只要有一次任务提交失败，就认为YAFE仍处于不可靠状态。重新通过采用消息队列的方式向YAFE提交任务。

基于此，本发明实施例中，调度服务在可靠状态下接收到执行引擎提交任务失败的状态信息时，启动第一计时器并对提交任务失败次数进行计数，如果在第一预设时长内提交任务失败次数达到第一预设阈值，则确定执行引擎的状态为不可靠状态。在确定执行引擎的状态为不可靠状态之后，启动第二计时器，在第二计时器的计时时长超过第二预设时长时，确定执行引擎的状态为半可靠状。在确定执行引擎的状态为半可靠状态之后，启动第三计时器，分别对提交任务成功次数和失败次数进行计数，如果在第三预设时长内提交任务成功次数达到第二预设阈值，则确定执行引擎的状态为可靠状态，在第三计时器计时期间，如果提交任务失败次数达到第三预设阈值，则确定所述执行引擎的状态为不可靠状态。

在ETL系统服务分离的基础上，从调度服务和执行引擎两端，分别对不可靠的服务进行策略控制，来完成ETL业务逻辑上的不停服。

首先，在升级调度服务期间，已经提交的任务在执行引擎端继续执行。调度服务保存作业下次调度时间nextScheduleTime，当调度服务恢复的时候，会自动比较系统当前时间与nextScheduleTime，按照图3所示的流程，判断是否需要存在遗漏调度周期，如果存在，会自动触发补周期流程，避免人为检查调度并执行缺失调度。其次，在升级或重启执行引擎YAFE期间，调度服务根据和YAFE交互结果，来判断YAFE状态，分别采取不同的方式进行任务提交。避免了因为YAFE引擎不可靠而导致的任务批量的没有响应或失败。从而避免了运维人员在系统升级结束之后，大规模的恢复执行失败作业的操作。

在基于微服务框架下，可以对某一个服务进行升级，因此，单独对执行引擎进行升级时，本发明实施例可以按照图6所示的流程实施，包括以下步骤：

S61、在向执行引擎提交任务之前，确定所述执行引擎的状态。

S62、根据确定出的执行引擎状态，确定提交执行任务的提交方式。

S63、使用确定出的提交方式向执行引擎提交执行任务。

其中，执行引擎状态包括可靠状态、不可靠状态、半可靠状态三种状态的确认转换。

本发明实施例中，执行引擎状态转换原理如下：通过对不同预设时长内的提交任务成功或失败的次数统计，确认执行引擎所处的状态，根据确定出的执行引擎状态，确定提交执行任务的提交方式，使用确定出的提交方式向执行引擎提交执行任务。如果确定出的执行引擎状态为可靠状态或者半可靠状态，则确定提交执行任务的提交方式为接口调用提交方式；如果确定出的执行引擎状态为不可靠状态，则确定提交执行任务的提交方式为消息队列方式。

具体实施时，可根据在可靠状态下接收到所述执行引擎提交任务失败的状态信息时，启动第一计时器并对提交任务失败次数进行计数，如果在第一预设时长内提交任务失败次数达到第一预设阈值，则确定所述执行引擎的状态为不可靠状态，此时使用消息队列的方式提交任务。

在确定所述执行引擎的状态为不可靠状态之后，启动第二计时器在所述第二计时器，维持一个时长，即第二预设时长，在第二预设时长内选择通过基于消息队列的方式来提交任务，提交的任务会存储在消息队列中，等到执行引擎启动恢复正常时，执行引擎通过消费消息队列，来触发任务。

在第二计时器的计时时长超过第二预设时长时，确定所述执行引擎的状态为半可靠状态，在确定所述执行引擎的状态为半可靠状态之后，此时采用接口调用的方式提交任务。启动第三计时器，分别对提交任务成功次数和失败次数进行计数，如果在第三预设时长内提交任务成功次数达到第二预设阈值，则确定所述执行引擎的状态恢复为可靠状态，继续采用接口调用的方式提交任务；若在所述第三计时器计时期间，如果提交任务失败次数达到第三预设阈值，则确定所述执行引擎的状态仍为不可靠状态。

基于同一发明构思，本发明实施例中还提供了一种数据处理装置，由于上述装置解决问题的原理与数据处理方法相似，因此上述装置的实施可以参见方法的实施，重复之处不再赘述。

如图7所示，其为本发明实施例提供的第一种数据处理装置的结构示意图，包括：

判断单元71，用于在服务启动之后，根据当前系统时间和任务调度表中记录的下次调度时间判断是否存在遗漏调度周期；

处理单元72，用于如果判断出存在遗漏调度周期，则将所述任务调度表中下次调度时间增加一个调度周期，以及将维护的遗漏周期计数参数加1后，返回执行根据当前系统时间和任务调度表中记录的下次调度时间判断是否存在有漏调度周期的步骤，直至得到的下次调度时间大于当前系统时间为止；

任务提交单元73，用于根据所述遗漏周期计数向执行引擎提交执行任务。

可选地，所述判断单元71，具体用于比较当前系统时间与所述下次调度时间，若所述当前系统时间大于所述下次调度时间，则确定存在遗漏调度周期；若所述当前系统时间小于所述下次调度时间，则确定不存在遗漏调度周期。

如图8所示，其为本发明实施例提供的第二种数据处理装置的结构示意图，包括：

第一确定单元81，用于在向执行引擎提交任务之前，确定所述执行引擎的状态；

第二确定单元82，用于根据确定出的执行引擎状态，确定提交执行任务的提交方式；

任务提交单元83，用于使用确定出的提交方式向执行引擎提交执行任务。

其中，执行引擎的状态包括可靠状态，不可靠状态和半可靠状态；

所述第二确定单元82，具体用于如果确定出的执行引擎状态为可靠状态或者半可靠状态，则确定提交执行任务的提交方式为接口调用提交方式；如果确定出的执行引擎状态为不可靠状态，则确定提交执行任务的提交方式为消息队列方式。

为了描述的方便，以上各部分按照功能划分为各模块(或单元)分别描述。当然，在实施本发明时可以把各模块(或单元)的功能在同一个或多个软件或硬件中实现。

在介绍了本发明示例性实施方式的数据处理方法和装置之后，接下来，介绍根据本发明的另一示例性实施方式的计算装置。

所属技术领域的技术人员能够理解，本发明的各个方面可以实现为系统、方法或程序产品。因此，本发明的各个方面可以具体实现为以下形式，即：完全的硬件实施方式、完全的软件实施方式(包括固件、微代码等)，或硬件和软件方面结合的实施方式，这里可以统称为“电路”、“模块”或“系统”。

在一些可能的实施方式中，根据本发明的计算装置可以至少包括至少一个处理器、以及至少一个存储器。其中，所述存储器存储有程序代码，当所述程序代码被所述处理器执行时，使得所述处理器执行本说明书上述描述的根据本发明各种示例性实施方式的数据处理方法中的步骤。例如，所述处理器可以执行如图3中所示的步骤S31、在服务启动之后，根据当前系统时间和任务调度表中记录的下次调度时间判断是否存在遗漏调度周期，如果是，执行步骤S32，如果否，流程结束，和步骤S32、将任务调度表中下次调度时间增加一个调度周期，以及将维护的遗漏周期计数参数加1；以及步骤S33、判断任务调度表中记录的下次调度时间是否大于当前系统时间，如果是，则执行步骤S34，否则，执行步骤S31；步骤S34、根据遗漏周期计数向执行引擎提交执行任务。

下面参照图9来描述根据本发明的这种实施方式的计算装置90。图9显示的计算装置90仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

如图9所示，计算装置90以通用计算设备的形式表现。计算装置90的组件可以包括但不限于：上述至少一个处理器91、上述至少一个存储器92、连接不同系统组件(包括存储器92和处理器91)的总线93。

总线93表示几类总线结构中的一种或多种，包括存储器总线或者存储器控制器、外围总线、处理器或者使用多种总线结构中的任意总线结构的局域总线。

存储器92可以包括易失性存储器形式的可读介质，例如随机存取存储器(RAM)921和/或高速缓存存储器922，还可以进一步包括只读存储器(ROM)923。

存储器92还可以包括具有一组(至少一个)程序模块924的程序/实用工具925，这样的程序模块924包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

计算装置90也可以与一个或多个外部设备94(例如键盘、指向设备等)通信，还可与一个或者多个使得用户能与计算装置90交互的设备通信，和/或与使得该计算装置90能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口95进行。并且，计算装置90还可以通过网络适配器96与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图所示，网络适配器96通过总线93与用于计算装置90的其它模块通信。应当理解，尽管图中未示出，可以结合计算装置90使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理器、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。

在一些可能的实施方式中，本发明提供的数据处理方法的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当所述程序产品在计算机设备上运行时，所述程序代码用于使所述计算机设备执行本说明书上述描述的根据本发明各种示例性实施方式的数据处理方法中的步骤，例如，所述计算机设备可以执行如图3中所示的步骤S31、在服务启动之后，根据当前系统时间和任务调度表中记录的下次调度时间判断是否存在遗漏调度周期，如果是，执行步骤S32，如果否，流程结束，和步骤S32、将任务调度表中下次调度时间增加一个调度周期，以及将维护的遗漏周期计数参数加1；以及步骤S33、判断任务调度表中记录的下次调度时间是否大于当前系统时间，如果是，则执行步骤S34，否则，执行步骤S31；步骤S34、根据遗漏周期计数向执行引擎提交执行任务。

所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

本发明的实施方式的用于数据处理的程序产品可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在计算设备上运行。然而，本发明的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括——但不限于——电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的程序代码可以用任何适当的介质传输，包括——但不限于——无线、有线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本发明操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

应当注意，尽管在上文详细描述中提及了装置的若干单元或子单元，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本发明的实施方式，上文描述的两个或更多单元的特征和功能可以在一个单元中具体化。反之，上文描述的一个单元的特征和功能可以进一步划分为由多个单元来具体化。

此外，尽管在附图中以特定顺序描述了本发明方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

如图10所示，其为本发明实施例提供的数据处理系统的结构示意图，包括调度服务装置101和执行引擎102，其中调度服务装置设置有上述任一数据处理装置。

本发明实施例涉仅为本发明较佳的具体实施例，而不是对本发明技术方案的限定，任何熟悉该技术的本领域普通技术人员在本发明所提示的技术范围内，可以轻易想到的变化和替换，都应该涵盖在本发明的保护范围之内。

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

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

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims

1.一种数据处理方法，其特征在于，包括：

根据所述遗漏周期计数向执行引擎提交执行任务；

在根据所述遗漏周期计数向执行引擎提交执行任务之前，还包括：

确定所述执行引擎的状态；所述执行引擎的状态包括可靠状态，不可靠状态和半可靠状态；

根据所述遗漏周期计数，使用确定出的提交方式向执行引擎提交执行任务；

2.如权利要求1所述的方法，其特征在于，根据当前系统时间和任务调度表中记录的下次调度时间判断是否存在有漏调度周期，具体包括：

3.如权利要求1所述的方法，其特征在于，确定所述执行引擎的状态，具体包括：

4.如权利要求3所述的方法，其特征在于，在确定所述执行引擎的状态为不可靠状态之后，还包括：

启动第二计时器；

5.如权利要求4所述的方法，其特征在于，在确定所述执行引擎的状态为半可靠状态之后，还包括：

启动第三计时器；以及

分别对提交任务成功次数和失败次数进行计数；

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

任务提交单元，用于根据所述遗漏周期计数向执行引擎提交执行任务；

所述装置，还包括第一确定单元和第二确定单元，其中：

所述第一确定单元，用于在所述任务提交单元根据所述遗漏周期计数向执行引擎提交执行任务之前，确定所述执行引擎的状态；所述执行引擎的状态包括可靠状态，不可靠状态和半可靠状态；

所述任务提交单元，用于根据所述遗漏周期计数，使用确定出的提交方式向执行引擎提交执行任务；

7.如权利要求6所述的装置，其特征在于，

所述判断单元，具体用于比较当前系统时间与所述下次调度时间，若所述当前系统时间大于所述下次调度时间，则确定存在遗漏调度周期；若所述当前系统时间小于所述下次调度时间，则确定不存在遗漏调度周期。

8.如权利要求6所述的装置，其特征在于，

所述第一确定单元，用于在可靠状态下接收到所述执行引擎提交任务失败的状态信息时，启动第一计时器并对提交任务失败次数进行计数；如果在第一预设时长内提交任务失败次数达到第一预设阈值，则确定所述执行引擎的状态为不可靠状态。

9.如权利要求8所述的装置，其特征在于，

所述第一确定单元，还用于在确定所述执行引擎的状态为不可靠状态之后，启动第二计时器；在所述第二计时器的计时时长超过第二预设时长时，确定所述执行引擎的状态为半可靠状态。

10.如权利要求9所述的装置，其特征在于，

所述第一确定单元，还用于在确定所述执行引擎的状态为半可靠状态之后，启动第三计时器；分别对提交任务成功次数和失败次数进行计数；如果在第三预设时长内提交任务成功次数达到第二预设阈值，则确定所述执行引擎的状态为可靠状态；在所述第三计时器计时期间，如果提交任务失败次数达到第三预设阈值，则确定所述执行引擎的状态为不可靠状态。

11.一种数据处理系统，其特征在于，包括调度服务装置和执行引擎，其中所述调度服务装置设置有权利要求6~10任一权利要求所述的数据处理装置。