CN107784400A - 一种业务模型的执行方法和装置 - Google Patents

Abstract

本发明提供一种业务模型的执行方法和装置，能够自动维护模型依赖关系并生成对应的批次号，方便业务模型的管理和维护，节约线下维护依赖关系的时间及人员成本，实现模型自动创建及多种维度地定时执行任务，根据当前执行的模型数量控制并发量，合理利用空闲时间执行模型，提高工作效率。本发明的业务模型的执行方法包括：接收并保存输入的业务模型的信息，并确定业务模型的依赖关系；接收业务模型的任务配置信息，并根据可执行模块选择规则确定可执行的业务模型，可执行模块选择规则包括业务模型的依赖关系和任务配置信息；根据预定的业务模型排序规则对可执行的业务模型进行排序并按序执行可执行的业务模型；根据执行的结果更新业务模型的信息。

Description

一种业务模型的执行方法和装置

技术领域

本发明涉及计算机及其软件技术领域，特别地涉及一种业务模型的执行方法和装置。

背景技术

在现有的系统中，模型管理方案使用Hadoop(分布式系统基础架构)存储数据，基于web应用客户端，执行hive脚本创建模型，并用hive建立业务模型表，创建查询任务。

现有系统存在诸多缺陷，首先，需要用户确认要执行的模型的所有依赖的模型是否都执行成功，只有都执行成功了才能手动执行该模型，否则，要把依赖的模型都逐一执行一遍才能执行该模型；其次，目前的模型依赖关系都是线下由用户自己管理，由用户录入数据时手动设定批次号，维护和沟通成本都比较大，并且只能通过批次号一个个手动执行，执行效率也比较低；再次，不能定时执行模型创建，也就是说，模型在创建时，不能指定模型创建的开始时间，没到时间不准创建；最后，不能限制并行执行的模型数量。

在此情况下，亟需建立一个业务模型自动执行的管理系统以克服现有系统中的各方面缺陷。

发明内容

有鉴于此，本发明提供一种业务模型的执行方法和装置，能够在业务模型信息录入或变更时自动维护模型依赖关系并生成对应的批次号，方便用户对业务模型的管理和维护，并节约了线下维护依赖关系的时间及人员成本，保证了数据的正确性；允许用户按照需要创建和管理模型执行的定时任务，可自动按照设定的任务时间启动任务并按序执行任务中包含的所有模型，实现模型的自动创建以及多种维度地定时执行任务，节约了用户的手动执行时间，保证了依赖执行的正确性；可根据模型执行模块的执行压力配置任务的执行时间区间以避开高峰期，并根据当前执行的模型数量控制并发量，可以随时手动暂停或开始任务，合理利用空闲时间执行模型，提高工作效率。

为实现上述目的，根据本发明的一个方面，提供了一种业务模型的执行方法。

一种业务模型的执行方法，包括：接收并保存输入的业务模型的信息，并根据所述信息确定所述业务模型的依赖关系；接收所述业务模型的任务配置信息，并根据可执行模块选择规则确定可执行的业务模型，所述可执行模块选择规则包括所述业务模型的依赖关系和所述任务配置信息；根据预定的业务模型排序规则对所述可执行的业务模型进行排序并按序执行所述可执行的业务模型；根据所述执行的结果更新所述业务模型的信息。

可选地，确定所述业务模型的依赖关系的步骤包括：读取输入的所述业务模型的信息以及基础业务模型的信息，并利用正则表达式确定每个所述输入的业务模型所依赖的业务模型；将所依赖的业务模型不属于所述输入的业务模型的所述业务模型的节点级别和批次号设为1；利用业务模型之间的依赖关系进行递归处理，得到每个所述输入的业务模型的节点级别、批次号和被依赖数，其中，每个所述输入的业务模型具有至少一个节点级别，且取所述至少一个节点级别中的最大值作为所述业务模型的批次号。

可选地，所述可执行模块选择规则还包括：所述业务模型所依赖的业务模型的执行状态、所述业务模型的默认执行时间、所述业务模型所依赖的业务模型上次执行完成的时间。

可选地，预定的业务模型排序规则包括：根据所述业务模型的批次号升序、被依赖数降序以及所述业务模型所属任务的执行状态，对所述可执行的业务模型进行排序。

可选地，所述可执行的业务模型以队列的形式提交给模型执行模块以便所述模型执行模块按序执行所述可执行的业务模型，并且，在将所述可执行的业务模型提交前，再次验证所述可执行的业务模型的可执行性，并将不能执行的业务模型移除队列。

可选地，根据所述模型执行模块返回的队列标识码，调用结果查询接口来轮询所述模型执行模块的各个队列，以获得所述业务模型的执行结果。

可选地，所述业务模型的信息包括：所述业务模型的名称、执行脚本、模型执行模块、默认执行时间和所述业务模型的字段；以及，所述任务配置信息包括：任务名称、任务的开始时间和结束时间、任务周期、任务中的模型。

根据本发明的另一方面，提供了一种业务模型的执行装置。

一种业务模型的执行装置，包括：依赖关系确定模块，用于接收并保存输入的业务模型的信息，并根据所述信息确定所述业务模型的依赖关系；业务模型选择模块，用于接收所述业务模型的任务配置信息，并根据可执行模块选择规则确定可执行的业务模型，所述可执行模块选择规则包括所述业务模型的依赖关系和所述任务配置信息；业务模型排序模块，用于根据预定的业务模型排序规则对所述可执行的业务模型进行排序并按序执行所述可执行的业务模型；模型信息更新模块，用于根据所述执行的结果更新所述业务模型的信息。

可选地，所述依赖关系确定模块还用于：读取输入的所述业务模型的信息以及基础业务模型的信息，并利用正则表达式确定每个所述输入的业务模型所依赖的业务模型；将所依赖的业务模型不属于所述输入的业务模型的所述业务模型的节点级别和批次号设为1；利用业务模型之间的依赖关系进行递归处理，得到每个所述输入的业务模型的节点级别、批次号和被依赖数，其中，每个所述输入的业务模型具有至少一个节点级别，且取所述至少一个节点级别中的最大值作为所述业务模型的批次号。

可选地，所述可执行模块选择规则还包括：所述业务模型所依赖的业务模型的执行状态、所述业务模型的默认执行时间、所述业务模型所依赖的业务模型上次执行完成的时间。

可选地，预定的业务模型排序规则包括：根据所述业务模型的批次号升序、被依赖数降序以及所述业务模型所属任务的执行状态，对所述可执行的业务模型进行排序。

可选地，所述业务模型排序模块还用于：将所述可执行的业务模型以队列的形式提交给模型执行模块以便所述模型执行模块按序执行所述可执行的业务模型，并且，在将所述可执行的业务模型提交前，再次验证所述可执行的业务模型的可执行性，并将不能执行的业务模型移除队列。

可选地，所述模型信息更新模块还用于：根据所述模型执行模块返回的队列标识码，调用结果查询接口来轮询所述模型执行模块的各个队列，以获得所述业务模型的执行结果。

可选地，所述业务模型的信息包括：所述业务模型的名称、执行脚本、模型执行模块、默认执行时间和所述业务模型的字段；以及，所述任务配置信息包括：任务名称、任务的开始时间和结束时间、任务周期、任务中的模型。

本发明的再一方面，提供了一种业务模型的执行装置，包括：存储器和处理器，其中，所述存储器存储指令；所述处理器执行所述指令用于：接收并保存输入的业务模型的信息，并根据所述信息确定所述业务模型的依赖关系；接收所述业务模型的任务配置信息，并根据可执行模块选择规则确定可执行的业务模型，所述可执行模块选择规则包括所述业务模型的依赖关系和所述任务配置信息；根据预定的业务模型排序规则对所述可执行的业务模型进行排序并按序执行所述可执行的业务模型；根据所述执行的结果更新所述业务模型的信息。

根据本发明的技术方案，接收并保存输入的业务模型的信息，并确定业务模型的依赖关系，接收业务模型的任务配置信息，并根据可执行模块选择规则确定可执行的业务模型，可执行模块选择规则包括业务模型的依赖关系和任务配置信息，根据预定的业务模型排序规则对可执行的业务模型进行排序并按序执行可执行的业务模型，根据执行的结果更新业务模型的信息。使用本发明的技术方案，能够在业务模型信息录入或变更时自动维护模型依赖关系并生成对应的批次号，规避了手工管理带来的风险，方便用户对业务模型的管理和维护，并节约了线下维护依赖关系的时间及人员成本，保证了数据的正确性；允许用户按照需要，在用户界面创建和管理模型执行的定时任务，可自动按照设定的任务时间启动任务并按序执行任务中包含的所有模型，实现模型的自动创建以及多种维度地定时执行任务，节约了用户的手动执行时间，保证了依赖执行的正确性；在模型提交执行时，可根据模型执行模块的执行压力配置任务的执行时间区间以避开高峰期，并根据当前执行的模型数量控制并发量，可以随时手动暂停或开始任务，合理利用空闲时间执行模型，提高工作效率。

附图说明

附图用于更好地理解本发明，不构成对本发明的不当限定。其中：

图1是根据本发明实施例的业务模型的执行方法的主要步骤示意图；

图2是根据本发明实施例的业务模型的执行方法的流程示意图；

图3是根据本发明实施例的业务模型的执行方法的数据流向示意图；

图4是根据本发明实施例的业务模型的执行装置的主要模块示意图。

具体实施方式

以下结合附图对本发明的示范性实施例做出说明，其中包括本发明实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本发明的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

图1是根据本发明实施例的业务模型的执行方法的主要步骤示意图。

根据本发明实施例的业务模型的执行方法主要包括如下的步骤S11至步骤S14。

步骤S11：接收并保存输入的业务模型的信息，并根据该信息确定业务模型的依赖关系。

业务模型的信息包括：业务模型的名称、执行脚本、模型执行模块、默认执行时间和业务模型的字段。具体地，业务模型名称(如业务模型的中文名)、执行脚本(即用于模型创建的脚本)、模型执行模块(可具体到执行模型创建所在的数据库)、默认执行时间(例如默认时间为两点，表示到两点才开始执行)和业务模型的字段。其中，模型执行模块可以为BI平台(大数据平台)，BI平台上可以有多个数据库，业务模型的执行需在具体的数据库中执行模型创建，模型的字段可以包括模型编码(如X1，X2等)，还可以包括模型类型，如主表、临时表、台账、流水、备份、是否是报表等。

确定业务模型的依赖关系主要通过如下方法：

读取输入的业务模型的信息以及基础业务模型的信息，并利用正则表达式确定每个输入的业务模型所依赖的业务模型；

将所依赖的业务模型不属于输入的业务模型的业务模型的节点级别和批次号设为1；

利用业务模型之间的依赖关系进行递归处理，得到每个输入的业务模型的节点级别、批次号和被依赖数，其中，每个输入的业务模型具有至少一个节点级别，且取至少一个节点级别中的最大值作为业务模型的批次号。

其中，可将输入的业务模型的信息保存为模型记录，基础业务模型为不属于该模型记录中的业务模型，其为执行过的业务模型，并且保存在模型执行模块(如BI平台)的数据库中，对于依赖的模型为基础模型的业务模型，由于基础模型已经执行完毕，那么该业务模型可以直接执行。

步骤S12：接收业务模型的任务配置信息，并根据可执行模块选择规则确定可执行的业务模型，可执行模块选择规则包括业务模型的依赖关系和任务配置信息。

任务配置信息包括：任务名称、任务的开始时间和结束时间、任务周期、任务中的模型。

可执行模块选择规则还包括：业务模型所依赖的业务模型的执行状态、业务模型的默认执行时间、业务模型所依赖的业务模型上次执行完成的时间。

步骤S13：根据预定的业务模型排序规则对可执行的业务模型进行排序并按序执行可执行的业务模型。

预定的业务模型排序规则包括：根据业务模型的批次号升序、被依赖数降序以及业务模型所属任务的执行状态，对可执行的业务模型进行排序。

可执行的业务模型以队列的形式提交给模型执行模块以便模型执行模块按序执行所述可执行的业务模型，并且，在将可执行的业务模型提交前，再次验证可执行的业务模型的可执行性，并将不能执行的业务模型移除队列。

步骤S14：根据执行的结果更新业务模型的信息。

其中，根据模型执行模块返回的队列标识码，调用结果查询接口来轮询模型执行模块的各个队列，以获得业务模型的执行结果。

下面结合具体例子来详细说明本发明实施例的业务模型的执行方法。根据本发明实施例的业务模型的执行方法，可输入多个的业务模型的信息，如业务模型X1～X5。将输入的业务模型的信息保存为模型记录，可自动触发遍历所有的模型记录，利用正则表达式从模型创建的脚本中得到依赖的所有模型，并确定输入的业务模型中每个业务模型的批次号。其中，可通过模型创建的脚本来确定依赖的模型，模型创建脚本中包括模型的基本属性、依赖的模型、模型创建的条件等内容。

确定业务模型的批次号的具体过程如下：先遍历模型记录以得到记录的所有模型，然后从模型创建的脚本中获取所依赖的模型的编码，将该依赖的模型的编码与记录的所有模型的编码进行匹配，从而确定依赖的模型中属于输入的业务模型的依赖模型，以及不属于输入的业务模型的依赖模型，将其中不属于输入的业务模型的依赖模型剔除掉，例如，输入的业务模型X1～X5，其中，以模型X1、X2的依赖模型为例，假设X1依赖于模型X2，X5和A，并且X2只依赖于A，那么A不是输入的业务模型的信息，即A不在保存的模型记录中，则将该依赖模型A剔除掉，得到剩下的依赖模型。然后，按照模型依赖关系将模型记录中的所有模型保存到依赖关系列表中，可以按照树形结构或者存储表的形式来实现该依赖关系列表的记录结构，记录的主要结构可以是该业务模型为子节点，依赖的模型为父节点，对于依赖模型个数为0的业务模型的父节点设定一个固定标识值，并设置该业务模型的节点级别和批次号为1。例如，上述模型X1依赖于模型X2，X5和A，并且X2只依赖于A，由于A不在保存的模型记录中，则将该依赖模型A剔除掉，则剩余的依赖模型为X1依赖于模型X2，X5，且X2的依赖模型个数为0，则X1的父节点为X2，X5，X2的节点级别和批次号直接设置为1。将所有批次号为1的业务模型存放在一个模型集合中，利用保存了模型依赖关系的依赖关系列表记录和保存了批次号为1的业务模型的模型集合进行递归处理，得到依赖关系记录中每条记录的节点级别。最后遍历依赖关系列表记录并保存到数据库，得到节点级别最大的所有子节点的模型记录。模型记录中每个输入的业务模型具有至少一个节点级别，取至少一个节点级别中的最大值作为该业务模型的批次号。例如，上述X1的父节点为X2，X5，X2的节点级别和批次号为1，假设X5的节点级别为2，那么X1的节点级别为2和3，取节点级别最大值作为X1的批次号，即批次号为3。

通过基于这些输入的业务模型建立任务，将要创建的模型添加到任务中，例如，上述输入了业务模型X1～X5，将其中的业务模型X1～X3加入任务，并添加任务配置信息，主要有任务名称、任务的开始时间和结束时间、任务周期(如日、月、周、季等)、任务中的模型(即任务中添加的模型)，还可配置其他信息，例如设置周末是否执行该任务等信息。任务配置信息可以在任务执行过程中根据用户需求来变更，例如任务添加了X1～X3，后续根据需求还可添加输入的其他业务模型，例如添加X5，在任务执行的本周期内，变更任务配置信息不影响任务中业务模型的正常执行，该变更在下个任务周期生效。例如，X1依赖于X5，则在本轮任务周期内，X1和X5之间的依赖关系不影响X1的正常执行。

根据任务配置信息及用户操作可对任务进行启动、暂停、停止、重新启动任务。任务可根据配置的每天可执行时间进行自启动和暂停，只要该任务所添加的模型没有全部执行完，那么该任务每天都会在指定的时间进行自启动和自动暂停，周期性地运行，直到全部模型执行完成，本任务才会结束。例如，任务中添加了业务模型X1，X2，X3，并且任务周期是日任务，那么，如果当天没有执行完，那么第二天将接着执行，直到执行完成所有模型之后才开始下一轮的任务周期循环。

根据可执行模块选择规则确定可执行的业务模型，可执行模块选择规则包括业务模型的依赖关系和任务配置信息，还包括业务模型所依赖的业务模型的执行状态、业务模型的默认执行时间、业务模型所依赖的业务模型上次执行完成的时间。业务模型所依赖的业务模型的执行状态可包括同一任务中依赖模型的执行状态和不同任务中依赖模型的执行状态。根据可执行模块选择规则中的上述内容判断该业务模型是否可以执行，把能执行的放入执行队列中。否则，直到满足模型可执行的条件后，才能被加入执行队列中。不同任务中依赖模型的执行状态，例如任务中的业务模型X1～X3，X1依赖于X5，由于X5不是任务中配置的模型，那么执行X1之前需检查X5是否执行完毕，如果X5没执行完则无法执行X1，也就是说X1不能被加入到执行队列里。同一任务中依赖模型的执行状态，例如上述业务模型X1～X3，如果X2依赖于X3，那么执行X2之前要检查X3是否执行完成，若X3没有执行完则不能把X2加到执行队列中。业务模型上次执行完成的时间和任务执行开始时间两个因素，具体地，例如X2依赖于X3，X3上次执行完的时间为T1，任务执行的开始时间是从T2开始执行，那么执行X2要首先检查X3的上次执行完成时间T1是否晚于任务开始时间T2，只有T1晚于T2才可以把X2添加到执行队列中执行X2，否则要先执行X3再执行X2，这样可保证任务开始执行之后所使用的数据是最新数据。

执行队列中的业务模型根据业务模型的批次号升序、被依赖数降序以及业务模型所属任务的执行状态，对可执行的业务模型进行排序，以便模型执行模块按序执行业务模型，完成业务模型的自动创建。当业务模型所属任务处于执行状态，那么，首先考虑业务模型批次，按照业务模型批次的升序排序，对于同一批次的业务模型，再按照被依赖数降序排序，例如，业务模型X1～X5，X1和X5批次号都为1，X2批次号为2，则首先执行X1和X5，再执行X2，X1和X5中，如果3个业务模型依赖于X1，2个业务模型依赖于X5，则先执行X1后执行X5，即X1，X2，X5之间的顺序为X1、X5、X2。

执行队列中的业务模型在提交到模型执行模块执行业务模型的创建之前，还需要再次验证提交的模型是否可执行，具体的验证方法可根据上述的可执行模块选择规则来进行验证，把不能执行的模型要移除执行队列。

在将业务模型提交到模型执行模块，例如BI平台之前，还需考虑BI平台的可执行的模型总数和当前正在执行的模型数量，根据BI平台的可执行的模型总数和当前正在执行的模型数量确定可以提交的模型数量值N，然后从执行队列取出N个业务模型提交到BI平台，实现了并发量的控制。

业务模型的执行脚本在BI平台执行以创建业务模型，根据BI平台的执行结果信息更新保存的模型记录中的相关数据，包括更新执行结果的状态(如成功或失败)、执行数据的业务模型数据的条数、执行结果记录数、执行中的一些错误信息等，其中，执行结果记录数表示模型创建完之后模型中存在的记录的条数。在向BI平台提交业务模型时，通过httpclient(HTTP协议的客户端编程工具包)调用的方式调用BI的保存接口，以便将要执行的模型保存到BI平台进行执行模型的创建，BI平台执行完模型创建之后，BI平台返回队列标识码(例如BI平台中的BI任务ID)，通过httpclient调用的方式调用BI的查询接口来轮询BI平台中的各个BI任务队列，并根据BI任务队列的队列标识码来查询执行的结果。执行结果的具体文件内容通常保存在BI平台之外的第三方文件服务器中，例如保存在OSS(云存储服务)平台。通过调用BI的查询接口可获取到执行结果文件的文件名，以及任务名称、任务状态、执行开始和结束时间、结果文件行数、文件大小、执行结果信息等，根据该文件名调用OSS平台的接口(可通过Jar依赖调用的方式获取OSS平台的接口)，来下载执行结果文件，并解析，得到执行结果记录数等信息。

下面结合图2和图3进一步介绍本发明实施例的业务模型的执行方法的流程及数据流向。

如图2和图3所示，输入业务模型的信息，然后进行依赖解析，根据输入的业务模型的信息确定业务模型的依赖关系，将业务模型之间依赖关系保存为依赖关系列表的形式，并将该依赖关系列表存储在数据库中。获取输入的业务模型的信息，并建立任务，接收添加的任务配置信息，并连同任务保存到数据库中，从数据库中获取任务配置信息，并启动任务调度线程，可根据任务配置信息对任务进行停止、修改、恢复、删除等工作，然后生成定时任务，根据可执行模块选择规则确定可执行的业务模型，对可执行的业务模型进行排序，并将可提交的业务模型加入执行队列，将执行队列保存在数据库中。其中，将任务中的可提交的业务模型加入执行队列时，可以同时启动多个线程实现并发控制，以任务1(例如配置的业务模型X1，X2，X5)包含两个任务线程1-1和任务线程1-2为例，在并发情况下，两个线程都从任务中选取业务模型放入执行队列，如果X1被线程1-1选取，则可利用乐观锁机制将X1锁定，比如使X1的控制状态由0变成1，以使线程1-2无法再选取X1。同时，可通过更新控制状态(例如将业务模型的控制状态由1变更为0)，使得其中一个线程选取的业务模型执行失败时，其他线程还可以选取该业务模型。

从数据库中获取保存的执行队列，根据BI平台的可执行的模型总数和当前正在执行的模型数量确定可以提交的模型数量值N，然后从执行队列取出N个业务模型提交到BI平台时，可以启动多个提交BI线程以提交业务模型，例如启动两个线程，假设BI平台可容纳提交的模型数量值N为20个，那么该两个线程一起提交的模型队列总数量即为20个，利用队列执行锁(一种排他锁机制)使该两个线程串行提交，即同一时间只允许一个线程提交，若其中一个线程提交的业务模型数量不足20个，则另一个线程可继续提交业务模型，否则另一个线程无法提交业务模型。提交的业务模型在BI平台的指定的数据库中执行模型的创建，其中，该指定的数据库在输入业务模型的信息时预先确定。执行的结果以数据文件的形式保存在第三方的OSS平台，可通过启动结果回写线程从BI平台获取执行结果的信息以及从OSS平台获取执行结果的数据文件，最后，更新业务模型的信息并保存在数据库中。其中，向BI平台查询执行结果时可以启动多个任务解析线程来调用BI平台的查询接口查询执行结果，并调用OSS平台的接口获取执行结果文件，最后完成结果的回写。并且，本发明的方案支持错误回调，即，获取到执行结果之后，如果执行结果为执行错误，例如超时等，那么可通过错误回调的方式重新启动提交BI线程以将业务模型提交到BI平台重新执行。

图4是根据本发明实施例的业务模型的执行装置的主要模块示意图。

如图4所示，业务模型的执行装置40主要包括依赖关系确定模块41、业务模型选择模块42、业务模型排序模块43、模型信息更新模块44。其中：

依赖关系确定模块41用于接收并保存输入的业务模型的信息，并根据该信息确定业务模型的依赖关系；业务模型选择模块42用于接收业务模型的任务配置信息，并根据可执行模块选择规则确定可执行的业务模型，可执行模块选择规则包括业务模型的依赖关系和任务配置信息；业务模型排序模块43用于根据预定的业务模型排序规则对可执行的业务模型进行排序并按序执行可执行的业务模型；模型信息更新模块44用于根据执行的结果更新业务模型的信息。

其中，业务模型的信息主要包括：业务模型的名称、执行脚本、模型执行模块、默认执行时间和业务模型的字段。

任务配置信息主要包括：任务名称、任务的开始时间和结束时间、任务周期、任务中的模型。

依赖关系确定模块41还可用于：读取输入的业务模型的信息以及基础业务模型的信息，并利用正则表达式确定每个输入的业务模型所依赖的业务模型；将所依赖的业务模型不属于输入的业务模型的业务模型的节点级别和批次号设为1；利用业务模型之间的依赖关系进行递归处理，得到每个输入的业务模型的节点级别、批次号和被依赖数，其中，每个输入的业务模型具有至少一个节点级别，且取至少一个节点级别中的最大值作为业务模型的批次号。

可执行模块选择规则还可以包括业务模型所依赖的业务模型的执行状态、业务模型的默认执行时间、业务模型所依赖的业务模型上次执行完成的时间。

预定的业务模型排序规则主要包括：根据业务模型的批次号升序、被依赖数降序以及业务模型所属任务的执行状态，对可执行的业务模型进行排序。

业务模型排序模块43还可用于：将可执行的业务模型以队列的形式提交给模型执行模块以便模型执行模块按序执行可执行的业务模型，并且，在将可执行的业务模型提交前，再次验证可执行的业务模型的可执行性，并将不能执行的业务模型移除队列。

模型信息更新模块44还可用于：根据模型执行模块返回的队列标识码，调用结果查询接口来轮询模型执行模块的各个队列，以获得业务模型的执行结果。

本发明实施例的另一种业务模型的执行装置主要包括：存储器和处理器，其中，存储器存储指令；处理器执行该指令用于：接收并保存输入的业务模型的信息，并根据该信息确定业务模型的依赖关系；接收业务模型的任务配置信息，并根据可执行模块选择规则确定可执行的业务模型，可执行模块选择规则包括业务模型的依赖关系和任务配置信息；根据预定的业务模型排序规则对可执行的业务模型进行排序并按序执行可执行的业务模型；根据执行的结果更新业务模型的信息。

通过对上述的实施例的详细描述，本领域技术人员可以清楚地理解，本发明实施例的技术方案使得用户无需手动设定批次号，降低了维护和沟通成本，并提高了业务模型的执行效率，支持定时执行模型创建，并且可限制并行执行的模型数量，实现并发控制。

根据本发明实施例的技术方案，接收并保存输入的业务模型的信息，并确定业务模型的依赖关系，接收业务模型的任务配置信息，并根据可执行模块选择规则确定可执行的业务模型，可执行模块选择规则包括业务模型的依赖关系和任务配置信息，根据预定的业务模型排序规则对可执行的业务模型进行排序并按序执行可执行的业务模型，根据执行的结果更新业务模型的信息。使用本发明实施例的技术方案，能够在业务模型信息录入或变更时自动维护模型依赖关系并生成对应的批次号，规避了手工管理带来的风险，方便用户对业务模型的管理和维护，并节约了线下维护依赖关系的时间及人员成本，保证了数据的正确性；允许用户按照需要，在用户界面创建和管理模型执行的定时任务，可自动按照设定的任务时间启动任务并按序执行任务中包含的所有模型，实现模型的自动创建以及多种维度地定时执行任务，节约了用户的手动执行时间，保证了依赖执行的正确性；在模型提交执行时，可根据模型执行模块的执行压力配置任务的执行时间区间以避开高峰期，并根据当前执行的模型数量控制并发量，可以随时手动暂停或开始任务，合理利用空闲时间执行模型，提高工作效率。

上述具体实施方式，并不构成对本发明保护范围的限制。本领域技术人员应该明白的是，取决于设计要求和其他因素，可以发生各种各样的修改、组合、子组合和替代。任何在本发明的精神和原则之内所作的修改、等同替换和改进等，均应包含在本发明保护范围之内。

Claims (15)

1.一种业务模型的执行方法，其特征在于，包括：

接收并保存输入的业务模型的信息，并根据所述信息确定所述业务模型的依赖关系；

接收所述业务模型的任务配置信息，并根据可执行模块选择规则确定可执行的业务模型，所述可执行模块选择规则包括所述业务模型的依赖关系和所述任务配置信息；

根据预定的业务模型排序规则对所述可执行的业务模型进行排序并按序执行所述可执行的业务模型；

根据所述执行的结果更新所述业务模型的信息。

2.根据权利要求1所述的方法，其特征在于，确定所述业务模型的依赖关系的步骤包括：

读取输入的所述业务模型的信息以及基础业务模型的信息，并利用正则表达式确定每个所述输入的业务模型所依赖的业务模型；

将所依赖的业务模型不属于所述输入的业务模型的所述业务模型的节点级别和批次号设为1；

利用业务模型之间的依赖关系进行递归处理，得到每个所述输入的业务模型的节点级别、批次号和被依赖数，其中，每个所述输入的业务模型具有至少一个节点级别，且取所述至少一个节点级别中的最大值作为所述业务模型的批次号。

3.根据权利要求1所述的方法，其特征在于，所述可执行模块选择规则还包括：

所述业务模型所依赖的业务模型的执行状态、所述业务模型的默认执行时间、所述业务模型所依赖的业务模型上次执行完成的时间。

4.根据权利要求1所述的方法，其特征在于，预定的业务模型排序规则包括：

根据所述业务模型的批次号升序、被依赖数降序以及所述业务模型所属任务的执行状态，对所述可执行的业务模型进行排序。

5.根据权利要求4所述的方法，其特征在于，所述可执行的业务模型以队列的形式提交给模型执行模块以便所述模型执行模块按序执行所述可执行的业务模型，并且，

在将所述可执行的业务模型提交前，再次验证所述可执行的业务模型的可执行性，并将不能执行的业务模型移除队列。

6.根据权利要求5所述的方法，其特征在于，根据所述模型执行模块返回的队列标识码，调用结果查询接口来轮询所述模型执行模块的各个队列，以获得所述业务模型的执行结果。

7.根据权利要求1所述的方法，其特征在于，所述业务模型的信息包括：所述业务模型的名称、执行脚本、模型执行模块、默认执行时间和所述业务模型的字段；以及，

所述任务配置信息包括：任务名称、任务的开始时间和结束时间、任务周期、任务中的模型。

8.一种业务模型的执行装置，其特征在于，包括：

依赖关系确定模块，用于接收并保存输入的业务模型的信息，并根据所述信息确定所述业务模型的依赖关系；

业务模型选择模块，用于接收所述业务模型的任务配置信息，并根据可执行模块选择规则确定可执行的业务模型，所述可执行模块选择规则包括所述业务模型的依赖关系和所述任务配置信息；

业务模型排序模块，用于根据预定的业务模型排序规则对所述可执行的业务模型进行排序并按序执行所述可执行的业务模型；

模型信息更新模块，用于根据所述执行的结果更新所述业务模型的信息。

9.根据权利要求8所述的装置，其特征在于，所述依赖关系确定模块还用于：

读取输入的所述业务模型的信息以及基础业务模型的信息，并利用正则表达式确定每个所述输入的业务模型所依赖的业务模型；

将所依赖的业务模型不属于所述输入的业务模型的所述业务模型的节点级别和批次号设为1；

利用业务模型之间的依赖关系进行递归处理，得到每个所述输入的业务模型的节点级别、批次号和被依赖数，其中，每个所述输入的业务模型具有至少一个节点级别，且取所述至少一个节点级别中的最大值作为所述业务模型的批次号。

10.根据权利要求8所述的装置，其特征在于，所述可执行模块选择规则还包括：

所述业务模型所依赖的业务模型的执行状态、所述业务模型的默认执行时间、所述业务模型所依赖的业务模型上次执行完成的时间。

11.根据权利要求8所述的装置，其特征在于，预定的业务模型排序规则包括：

根据所述业务模型的批次号升序、被依赖数降序以及所述业务模型所属任务的执行状态，对所述可执行的业务模型进行排序。

12.根据权利要求11所述的装置，其特征在于，所述业务模型排序模块还用于：

将所述可执行的业务模型以队列的形式提交给模型执行模块以便所述模型执行模块按序执行所述可执行的业务模型，并且，

在将所述可执行的业务模型提交前，再次验证所述可执行的业务模型的可执行性，并将不能执行的业务模型移除队列。

13.根据权利要求12所述的装置，其特征在于，所述模型信息更新模块还用于：

根据所述模型执行模块返回的队列标识码，调用结果查询接口来轮询所述模型执行模块的各个队列，以获得所述业务模型的执行结果。

14.根据权利要求8所述的装置，其特征在于，所述业务模型的信息包括：所述业务模型的名称、执行脚本、模型执行模块、默认执行时间和所述业务模型的字段；以及，

所述任务配置信息包括：任务名称、任务的开始时间和结束时间、任务周期、任务中的模型。

15.一种业务模型的执行装置，其特征在于，包括：存储器和处理器，其中，

所述存储器存储指令；

所述处理器执行所述指令用于：

接收并保存输入的业务模型的信息，并根据所述信息确定所述业务模型的依赖关系；

接收所述业务模型的任务配置信息，并根据可执行模块选择规则确定可执行的业务模型，所述可执行模块选择规则包括所述业务模型的依赖关系和所述任务配置信息；

根据预定的业务模型排序规则对所述可执行的业务模型进行排序并按序执行所述可执行的业务模型；

根据所述执行的结果更新所述业务模型的信息。