一种考虑繁忙程度的大数据平台多服务接口执行时间预测方法

摘要

本发明公开了一种考虑繁忙程度的大数据平台多服务接口执行时间预测方法，定义物联网接口服务执行过程中的参数；从接口服务的历史执行信息和平台的监控信息中获取数据量的大小、数据块大小、数据库的IO性能和空闲容器数量，并根据其建立服务执行时间的初级预测模型；按照接口服务功能类型分别拟合初级预测模型，获得修正的服务执行时间的预测模型；根据不同的服务，不同的运行时间段，求解修正的服务执行时间的预测模型的预测执行时间。本发明根据平台繁忙程度修正预测模型，满足提高了服务运行时间预测模型的准确性的目的。

说明书

技术领域

本发明涉及一种考虑繁忙程度的大数据平台多服务接口执行时间预测方法。

背景技术

随着互联网技术的发展，以及面向服务体系架构技术的成熟，以服务形式为主的接口应用技术，被广泛地应用到了IoT中。在IoT中的服务管理层，把传统的数据接口升级为接口服务，不仅便于接口的管理，简化了数据传输的过程，也极大的改善了接口传输数据的质量，提升了用户对数据和应用产品的满意度。然而，对于平台而言，面对着众多的接口服务，该如何准确预测接口服务执行时间，既满足用户的数据需求，又能充分利用平台的资源，已然成为IoT 中一个亟待解决的问题。

目前我国已形成基本齐全的物联网产业体系，在物联网网络通信服务业领域，我国物联网M2M网络服务保持高速增长势头，目前M2M终端数已超过1000 万，年均增长率超过80％，应用领域覆盖公共安全、城市管理、能源环保、交通运输、公共事业、农业服务、医疗卫生、教育文化、旅游等多个领域，物联网服务在我们的日常生活中无处不在，对提高生产力和改善生活质量发挥了重要作用。物联网中，服务的自动化配置系统实现将设备封装成设备服务，并通过设备服务与设备厂商通信，同时，系统支持从设备端获取数据传输到服务，并且对于用户的服务，用户可以自由链接。用户利用接口服务实现自身需求，由于用户业务需求特点对接口服务的执行时间要求较高，如果接口服务没有在用户期望的时间内完成，用户将不满意所提供的服务质量，而且准确的预测接口服务执行时间关系着后续的调度等操作。针对物联网接口服务执行时间预测，传统时间预测方法未考虑平台实际运行环境，所以实用性较差，且主观性较强，难以准确预测服务接口执行时间，因此亟需采用有效数据分析处理技术，针对服务接口的执行时间进行准确预测，从而提高了服务执行时间预测模型的准确性，充分利用平台的资源，提升了平台的综合性能，同时也方便IoT服务的管理，促进IoT的发展。

发明内容

本发明为了解决上述问题，提出了一种考虑繁忙程度的大数据平台多服务接口执行时间预测方法，本发明提出多元线性拟合方法建立服务执行时间初级预测模型，并根据平台繁忙程度修正预测模型，满足提高了服务运行时间预测模型的准确性的目的。

为了实现上述目的，本发明采用如下技术方案：

一种考虑繁忙程度的大数据平台多服务接口执行时间预测方法，包括以下步骤：

定义物联网接口服务执行过程中的参数；

从接口服务的历史执行信息和平台的监控信息中获取数据量的大小、数据块大小、数据库的IO性能和空闲容器数量，并根据其建立服务执行时间的初级预测模型；

按照接口服务功能类型分别拟合初级预测模型，获得修正的服务执行时间的预测模型；

根据不同的服务，不同的运行时间段，求解修正的服务执行时间的预测模型的预测执行时间。

进一步的，定义参数变量包括接口服务的启动时间、用户指定的接口服务完成的最晚时间、接口服务的数据来源、接口服务的标识、接口服务的预执行时间、集群容器的数量、接口服务接收数据的速度和服务发送数据的速度。

进一步的，接口服务的数据来源，主要分为中间库、其他接口服务的中间结果和其他接口服务的最终结果。

进一步的，接口服务的标识，分为常规服务和周期性执行两种。

进一步的，集群容器包括内存和CPU两种资源。

进一步的，建立的服务执行时间的初级预测模型为：接口服务的预执行时间与数据量的大小、原数据库的接收速度表示、目的数据库的接收速度和服务执行前容器空闲的数量称线性关系。

进一步的，接口服务的类型按照消耗资源程度和功能的不同进行分类。

进一步的，将平台的单位时间按照繁忙程度分成多个阶段，对于同一个功能类型的接口服务，在数据量一定的情况下，不同的阶段，执行时间是不同的。

进一步的，根据集群的运行情况，按照时间段对数据分类，根据数据分类的情况，从原始数据中提取出当前的服务功能类型和集群运行阶段的监控数据。

进一步的，修正后的服务执行时间的预测模型内包括有动荡因子，动荡因子的具体值由服务的历史执行信息中获取确定。

一种考虑平台繁忙程度的物联网接口服务执行时间预测系统，包括：

变量定义模块，定义物联网接口服务执行过程中的参数；

预测模型构建模块，从接口服务的历史执行信息和平台的监控信息中获取数据量的大小、数据块大小、数据库的IO性能和空闲容器数量，并根据其建立服务执行时间的初级预测模型；

优化模型模块，按照接口服务功能类型分别拟合初级预测模型，获得修正的服务执行时间的预测模型；

计算模块，根据不同的服务，不同的运行时间段，求解修正的服务执行时间的预测模型的预测执行时间。

与现有技术相比，本发明的有益效果为：

1、以往接口服务的完成时间根据经验判断，误差率较大。例如，如果一个服务的推送时间为30分钟，假如我们准时按照调度序列中的启动时间启动服务，则可能会由于平台资源的限制，导致这个服务不能按时完成；如果我们提前一段时间启动服务，这将面临两个小问题：第一，这个一段时间不能准确的估计；第二，提前启动这个服务会占用一些系统资源，影响其他服务的执行，影响平台的性能。本发明采用根据历史执行信息和平台的监控信息，从而确定接口服务执行时间，从而既保障服务执行时间预测的准确性，又提高整个服务效率和质量，解决了上述问题。

2、现有技术中平台的资源不能够得到充分的利用，例如，接口服务平台通常会在午夜和凌晨的时候比较空闲，从而不能充分利用平台的资源，而本发明根据平台繁忙程度，划分为多个时间段，并依据每个阶段的平台特征，修正初级预测模型，生成多个更加精准的终极服务执行时间预测模型，这样进一步提高预测执行时间的准确性。

附图说明

构成本申请的一部分的说明书附图用来提供对本申请的进一步理解，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。

图1为IoT和接口服务示意图；

图2为服务执行时间预测模型的建立过程示意图；

图3为预测模型准确率示意图；

图4为数据与准确度之间的关系示意图；

图5为本发明数据传输速度与精度的关系示意图；

图6为本发明资源利用率与准确度之间的关系示意图；

图7(a)为预测模型和准时性示意图；

图7(b)为某天内平台的准时性示意图；

图7(c)为常规服务与不期望的服务之间的关系示意图；

具体实施方式：

下面结合附图与实施例对本发明作进一步说明。

应该指出，以下详细说明都是例示性的，旨在对本申请提供进一步的说明。除非另有指明，本文使用的所有技术和科学术语具有与本申请所属技术领域的普通技术人员通常理解的相同含义。

需要注意的是，这里所使用的术语仅是为了描述具体实施方式，而非意图限制根据本申请的示例性实施方式。如在这里所使用的，除非上下文另外明确指出，否则单数形式也意图包括复数形式，此外，还应当理解的是，当在本说明书中使用术语“包含”和/或“包括”时，其指明存在特征、步骤、操作、器件、组件和/或它们的组合。

在本发明中，术语如“上”、“下”、“左”、“右”、“前”、“后”、“竖直”、“水平”、“侧”、“底”等指示的方位或位置关系为基于附图所示的方位或位置关系，只是为了便于叙述本发明各部件或元件结构关系而确定的关系词，并非特指本发明中任一部件或元件，不能理解为对本发明的限制。

本发明中，术语如“固接”、“相连”、“连接”等应做广义理解，表示可以是固定连接，也可以是一体地连接或可拆卸连接；可以是直接相连，也可以通过中间媒介间接相连。对于本领域的相关科研或技术人员，可以根据具体情况确定上述术语在本发明中的具体含义，不能理解为对本发明的限制。

针对物联网接口服务执行时间预测，传统时间预测方法未考虑平台实际运行环境故实用性较差，且主观性较强，难以准确预测服务接口执行时间，基于历史执行数据和监控信息，提出考虑繁忙程度的大数据平台多服务接口执行时间预测方法，实现了对接口服务执行时间的准确预测。

本发明提供了一种考虑繁忙程度的大数据平台多服务接口执行时间预测方法，步骤如下：

A.变量定义

本部分将给出发明中用到的一些变量的定义，具体内容如表一所示。

表一 缩写和含义

表1中，St为接口服务的启动时间；Dt为用户指定的接口服务完成的最晚时间，即接口服务必须在Dt或者Dt之前执行完毕；Ds为接口服务的数据来源，主要分为三种：中间库、其他接口服务的中间结果和其他接口服务的最终结果， Ds也表示了接口服务间的业务逻辑关系；Isi表示接口服务的标识，分为一天一次(常规服务)和一天多次(周期性执行)两种；Petime为接口服务的预执行时间，即根据接口服务的历史执行情况和当前平台的资源使用情况，通过分析、拟合等方法，综合得到的值；Nc表示集群容器的数量，容器中主要包括内存和CPU两种资源；Asr表示接口服务接收数据的速度，主要表示的是从数据库和硬盘接收数据的速度；Ast为服务发送数据的速度，它不仅与用户端的带宽、 IO负载和数据库负载有关，而且与接口服务平台自身的带宽也有关系。

B.服务执行时间的初级预测模型

接口服务的执行时间不仅与数据量的大小，数据块大小，数据库的IO性能有关，还与系统的空闲容器数量有关。通常，数据块的大小是固定的，所以暂不考虑。已知从接口服务的历史执行信息和平台的监控信息中，可以得到上述的信息，本发明主要根据这些信息得到接口服务的执行时间与其他变量间的关系。通过分析可知，这些变量与Petime成线性关系，所以建立多元函数进行数据拟合。假设从历史信息中整理出n组数据，数据量的大小表示为S，原数据库的接收速度表示为Asr(一段时间内的平均速度)，目的数据库的接收速度表示为Ast，服务执行前容器空闲的数量为Nc，则n组数据可表示为(Petimek,Sk, Nck,Asrk,Astk,k＝1,…,n)。Petimek为因变量，Sk,Nck,Asrk,Astk为变量，所以多元函数模型为：

Petime_k＝a₀+a₁*Sk+a₂*Nc_k+a₃*Asr_k+a₄*Ast_k,k＝1,2,3,...,n>

这是一个包含n个方程的超定方程组，系数矩阵和Petime矩阵为：

所以原方程可表示为，由最小二乘法可得到正规方程组：Petime＝AX，由最小二乘法可得到正规方程：A^TPetime＝A^TAX，通过方程组可以到X的值：

X＝[a₀a₁a₂a₃a₄]。a₀a₁a₂a₃a₄为参数，使用方程组是为求得模型参数，这些值为实数。

C.修正的服务执行时间的预测模型

通过多元线性函数的数据拟合，可以得到接口服务的预执行时间的计算公式(1)。但是，实际环境中，接口服务按照消耗资源程度和功能的不同，可以分为多种类型，例如IO密集型，CPU密集型等，所以将多种服务按照一种情况预测执行时间是不准确的，因此本发明修正了预测模型的方法，提出按照接口服务功能类型分别拟合(1)，求解X。

假设接口服务的功能类型分为FT＝{ft₁,ft₂,…ft_m}，根据FT，可以求解到>FT＝{X_ft1,X_ft2….X_ftm}。其中，X_ft1表示ft₁类型接口服务下X的值。

在平台中，平台的一天时间可以按照繁忙程度分成B个阶段，即 B＝{b₁,b₂,…b_p}。对于同一个功能类型的接口服务，在数据量一定的情况下，不同的阶段，执行时间也是不同的。因此，本发明针对同一个类型的服务，在不同的阶段对(1)进行拟合，得到X的值，即X＝X_FTB＝{{X_ft1b1,X_ft2b1,..X_ftmb1},{X_ft1b2,>ft2b2,..X_ftmb2},…{X_ft1bq,X_ft2bq,..X_ftmbq}}。通过层层深入的分析，最终得到了>FTB，此时，预测执行时间的准确有了很大的提高。最后为了保证服务可以按时完成，为Petime设置了一个动荡因子，所以Petiem＝Petime+d，d>

D.服务执行时间预测算法。

对于预测模型，经过研究可以发现接口服务的预执行时间与其他条件的关系成线性，所以本发明使用了多元线性函数对预执行时间和影响因素进行拟合，建立服务执行时间的预测模型。对于模型求解的算法可以为：

根据接口服务的功能类型对数据进行分类，根据集群的运行情况，按照时间段对数据分类。根据数据分类的情况，从原始数据中提取出当前的服务功能类型和集群运行阶段的监控数据。对提取的数据做进一步的提纯，从中获取到n 组S，Nc，Asr，Ast的数据。将数据带入公式(1)，求解出X的值。将X的值存储到Pset结果集中。

通过上述的算法，可以求得多组X的值。在对接口服务调度的时候，可以根据不同的服务，不同的运行时间段，使用不同的X的值，求解预测执行时间，这样可以提高服务预测执行时间的准确性，进而优化接口服务调度策略。该算法中可以设置适当的循环，此次总的时间复杂度为O(n2)。

实验环境如下：三台服务器(32CPU，32G内存，1T磁盘，Red Hat EnterpriseLinux6.2)作为平台的主节点和数据节点，五台笔记本电脑模拟用户端数据库，两台台式机作为平台的数据库，数据库均采用5.5.25MySQL Community Server (GPL)，编程环境选用Eclipse-SDK-4.3-win64，编程语言为Java 1.7。当然，在其他实施例中，可以更改编程环境、语言和设备。

实验中，从常规的推送服务中选出了16个作为测试服务，其中周期性执行的服务有3个，数据量从100M到20G，16个服务的具体要求如下表二、三和四所示。

表二 分类和服务类型

表三 周期服务的时间约束

表四 常规服务的时间限制

A.预测模型的准确性与影响因素

服务执行时间预测模型与影响模型准确性的因素相关性很大，因此设计了预测模型准确性的验证实验，并对影响模型准确性的因素进行了分析。

图3表示的是在常规服务和周期性服务下，服务执行时间预测模型的准确性。从图中可以看出，两种服务下，预测模型的准确率都是随着监控天数的增加而提高且到最后，提高幅度趋于平缓，这是因为监控天数越多，获取的数据越多，进而求解的参数越来越稳定，越来越准确。周期性服务下模型预测准确率比常规服务略低，这是因为周期性服务大多数都在平台比较繁忙的阶段执行，动荡性较大。图4展示了数据与服务执行时间预测模型准确性的关系，由图4 可知，固定数据量情况下，预测模型的准确性更高，且整体的变化不大；数据量变化的情况下，模型的准确性总体虽然也有提高，但是波动较大，这是因为数据量不断变化，模型就需要不断地被调整，导致同等条件下，积累的历史数据变少，预测模型准确性降低。

图5展示的是数据传输速度对预测模型的影响。由图可知，接收速度对于模型预测准确性的影响较大，波动较大，发送速度相对影响较小，这是因为客户端的数据库环境具有不可控性，系统得性能、负载等相对变化较大；发送端的整体环境我们是已知的，且系统的性能等变化相对比较有规律，所以对模型预测的准确性影响较小。图6表示的是平台的使用率与预测模型准确性的关系。由图可知，资源使用率越平稳，模型准确性越高，资源使用率变化越大，模型预测准确性越低，这是因为平台资源使用率突然变化，会对模型的部分参数有很大的影响，导致模型预测率降低。

B.接口服务的准时性与影响因素

为了验证本发明提出预测算法的有效性，因此设计了预测模型准确性与服务准时性比较，并对不期望的服务进行了实验。

图7(a)-(c)为服务推送准时率的影响因素，从图7(a)可知，服务执行时间的预测准确性与服务的推送准时性息息相关，预测模型越准确，服务推送相对也越准时。图7(b)展示了平台的不同执行阶段下的服务推送准确率情况，由图可知，在20点到次日上午8点之间，服务准确性很高，8-20点之间，服务准确性出现较大波动，准确率有所下降，这是因为白天的时候，平台相对比较繁忙，资源竞争激烈，容易出现资源不充足的情况，而午夜和早上，平台的任务比较少，资源空闲的相对比较多，所以服务执行更准确。由图7(c)可知，当服务群在执行的过程中，突然出现了不期望的服务时，数据推送的准确性急剧下降，当不期望服务执行完毕后，服务推送准时性由逐渐恢复到正常状态，这是因为突然执行的服务，抢占了平台的资源，导致计划中的服务得不到合适的服务，出现延迟。

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

上述虽然结合附图对本发明的具体实施方式进行了描述，但并非对本发明保护范围的限制，所属领域技术人员应该明白，在本发明的技术方案的基础上，本领域技术人员不需要付出创造性劳动即可做出的各种修改或变形仍在本发明的保护范围以内。