[0049] 为了使本发明的目的、技术方案及优点更加清楚,以下结合附图及实施例,对本发明进行进一步详细说明。应当理解,此处所描述的具体实施例仅仅用以解释本发明,并不用于限定本发明。此外,下面所描述的本发明各个实施方式中所涉及到的技术特征只要彼此之间未构成冲突就可以相互组合。
[0050] 如图1所示,本发明实施例提供一种海量数据的任务调度方法,包括:
[0051] S101.服务请求节点获取计算任务,所述计算任务为时延敏感型任务;
[0052] 服务请求节点可以是终端,也可以是网络节点,其具备基础的数据处理能力,也具备数据收发能力,由于处于数据大爆发时代,单一的网络节点或移动终端的能力已经不满足各种任务处理的需要,因此,需要一种任务卸载方案来保证不同任务的处理和执行,尤其是时延敏感型(低时延)任务,其对时延的要求很高,常常需要在较短的时间内完成该任务,例如智能驾驶等场景,长时延通常是不可接收的。
[0053] 为了满足低时延、高可靠的要求,雾计算应运而生,在雾计算中,可以允许资源受限的终端设备或网络节点将资源匮乏的移动设备的数据处理卸载到其他雾节点中,以保证良好的低时延,高可靠路径。因此,本发明以雾计算为背景,介绍多种任务卸载解决方案。
[0054] S102.所述服务请求节点生成博弈策略,并基于所述博弈策略,制定服务报酬,并将所述服务报酬及所述计算任务信息分发至一个或多个雾节点;
[0055] 在雾计算网络中,为了更好地确保时延要求,服务请求节点产生计算任务后,除本地计算外,需卸载到服务节点中进行处理。但网络中有很多服务节点并非由运营商部署,其具有许多空闲的计算资源。但很多服务请求节点产生的任务为时延敏感型,需要付出大量计算能力,服务节点会承担因自身能耗过高而造成性能受损的风险。若不考虑经济因素,雾节点缺少参与任务卸载的积极性和驱动力,不愿无私地贡献自身计算能力,不利于网络性能的提升。因此,在本发明实施例中,引入了一种基于博弈的激励机制,综合考虑了服务请求节点和雾节点的自身特性和网络环境,在激励服务请求节点参与卸载服务的同时,通过博弈过程,服务请求节点向雾节点支付最优的任务卸载报酬,雾节点向服务请求节点提供最优的计算能力。降低了服务请求节点任务卸载时延,实现了服务请求节点和雾节点各自净收益的最大化,达到了全局最优点。
[0056] 在本发明实施例中,博弈策略的定义是:服务请求节点综合自身情况,提供最优的服务报酬,雾节点综合自身情况,参与卸载并提供最优的计算能力。具体而言,包括如下三个方面:
[0057] (1)服务请求节点作为博弈的领导者,首先预测雾节点提供的计算能力大小,依据自身特性和网络环境计算收入和成本之间的净收益,然后优化自身净收益,根据最优净收益向雾节点提供任务卸载报酬价格。
[0058] (2)雾节点作为博弈的跟随者,依据服务请求节点给出的卸载报酬价格,以及自身特性和网络环境,计算收入和成本之间的净收益,然后优化自身净收益,确定向服务请求节点提供的最优计算能力。
[0059] (3)服务请求节点以最优卸载服务价格支付给雾节点报酬,雾节点以最优计算能力参与卸载服务。
[0060] 具体而言,基于所述博弈策略而制定服务报酬,包括如下步骤:
[0061] 服务请求节点计算收入和成本,获取净收益,所述净收益为所述收入减去所述成本;对所述净收益进行优化,根据优化的净收益向每个服务节点提供所述服务报酬。
[0062] 其中,所述服务请求节点基于如下公式对净收益进行优化:
[0063]
[0064] s.t.ωi≥0.
[0065] 收入为Ft和成本为Gt,服务报酬为 其中,所述收入根据服务请求节点支付的任务计算单价、任务数据量的大小和服务节点自身的计算速率来确定;所述成本根据提供给服务请求节点的计算能力大小、任务数据量的大小、服务节点CPU周期和服务节点每比特数据处理能耗来确定。例如,计算速率越高,其收入越高,时延越小,收入越高。
[0066] 而成本则根据支付给雾节点的任务计算单价、任务数据量的大小、雾节点的计算速率来确定。例如,当支付给雾节点的任务计算单价一定时,雾节点的计算速率越高、任务数据量越大时,需支付给雾节点的报酬越多,服务请求节点的成本也就越高。
[0067] 此外,在本发明实施例中,考虑到不同雾节点的计算能力、能够接收的报价不同,因此,在本发明实施例中,针对不同场景,分别作出以下说明:
[0068] 场景一:一对一;
[0069] 在场景一中,如图2所示,假设雾节点为一个时,则该服务请求节点确定最优服务报酬,并将所述最优服务报酬及所述计算任务信息分发给该雾节点,并等待该雾节点的反馈或响应。场景一是最为简单的情况,即单点发送给单点,并等待雾节点的反馈,适用于局域网或小范围物联网场景。
[0070] 场景二:一对多;
[0071] 在场景二中,一个服务请求节点对应多个雾节点。即,当雾节点为多个时,服务请求节点对多个雾节点的KPI性能进行预估,并基于预估结果,为每个雾节点定制对应的服务报酬,并将计算任务信息及定制的服务报酬分发至对应的多个雾节点中。其中,KPI性能包括计算速率、CPU利用率、存储利用率等指标,对KPI性能进行预估,可采用时间序列的机器学习或深度学习方法进行预测或预估,该预估技术属于公知,本发明实施例对比不再累述。
[0072] 具体而言,场景二又可以分为三种情况,分别如图3a、3b和图3c所示。
[0073] 在图3a中,服务请求节点分别针对不同的雾节点制定不同的服务报酬,对于雾节点1制定报酬1(图中简称为B1),针对雾节点2制定报酬2(B2)....
[0074] 在图3b中,雾节点呈现星型结构,具备一中心雾节点(雾节点A),该中心雾节点分别与其他雾节点进行直连,负责与其他雾节点进行收发。在图3b中,服务请求节点采用了分时发送的机制,即T1时刻先发第一定制的服务报酬(图中简称为B1),若无雾节点对此响应,则T2时刻再发第二定制的服务报酬(图中简称为B2),以此类推,直到有雾节点对该服务请求节点反馈任务卸载响应为止。具体而言:
[0075] 服务请求节点将第一定制的服务报酬发送至雾中心节点(图中为A节点)中,雾中心节点为多个雾节点中的中心控制节点;
[0076] 雾中心节点将第一定制的服务报酬分发至其余多个雾节点(图中为B,C,D节点)中,以使其余多个雾节点单独对服务请求节点进行反馈,例如,D节点单独对该服务请求节点进行任务卸载响应,那么服务请求节点与D节点即可进行后续的任务卸载操作;
[0077] 若服务请求节点在预定时间内未收到任一雾节点反馈的任务卸载响应,则基于分时策略,在预设定周期内将第二定制的服务报酬发送至雾中心节点中,以便雾中心节点将第二定制的服务报酬分发至其余多个雾节点中,以使其余多个雾节点单独对服务请求节点进行反馈。
[0078] 在图3c中,与前者方案不同的是,服务请求节点采取了总包+拆分的方式,打包发送给雾中心节点,所谓总包即该服务报酬既包括了节点A的服务报酬B1,也包括了节点B,C,D的服务报酬B2,B3和B4,即所有定制的服务报酬Q=B1+B2+B3+B4。拆分即是将Q拆分为B1,B2,B3和B4,然后分别发送给对应的雾节点。具体而言:
[0079] 服务请求节点将所有定制的服务报酬发送至雾中心节点中,雾中心节点为多个雾节点中的中心控制节点,所有定制的服务报酬包括每一雾节点对应的服务报酬;
[0080] 雾中心节点将所有定制的服务报酬进行拆分,并将拆分后的服务报酬依次分发至对应的雾节点中,若任一一个雾节点同意该服务报酬,即可通过中心雾节点或自身发送任务卸载响应给服务请求节点,完成后续的任务卸载动作。
[0081] 场景三:同一运营商;
[0082] 当雾节点为多个时,若服务请求节点和其中一个或多个雾节点属于同一运营商时,其支付报酬会有一定程度的优惠,且同一运营商的雾节点更愿意将最优的计算能力提供给该服务请求节点。因此,服务请求节点可以通过路由路径寻找的方式找寻该同一运营商的雾节点,并提供优惠服务报酬给该雾节点,该雾节点响应的概率也较大。具体而言:
[0083] 服务请求节点获取多个雾节点的ID、IP地址和类型;
[0084] 服务请求节点基于多个雾节点的ID、IP地址和类型,识别出与服务请求节点同一个运营商的一个或多个雾节点,具体地,ID、IP地址和类型可以由不同的运营商来制定,通过识别该ID号,和/或IP地址,和/或类型,即可反推出该雾节点是否是与服务请求节点同一个运营商;
[0085] 基于识别出的一个或多个雾节点,服务请求节点生成路由表,并制定服务报酬,将服务报酬及计算任务信息根据路由表,按照最短路径发送至识别出的一个或多个雾节点。
[0086] 如图4所示,服务请求节点根据路由表LIST,将服务报酬和计算任务信息发送给雾节点A,雾节点A根据路由信息,透发给雾节点C,雾节点C之后再透发给雾节点D,最终雾节点D和该服务请求节点属于同一运营商,能够及时高效地提供任务卸载响应。
[0087] 场景四:集群式分配;
[0088] 集群式分配的方案适用于当雾节点为多个、且计算任务为多个时,集群式分配即将总包和分包策略统一发送给雾中心节点,由雾中心节点根据分包策略,将总包进行报酬切割,并将切割后的单个服务报酬发送给对应的雾节点中。如图5所示,其总包为Q,分包策略为:1:2:2:5。即总包包括了给雾节点1(雾中心节点)的B1报酬,该报酬为总包Q的1/10;给雾节点2的B2报酬,该报酬为总包Q的1/5;给雾节点3的B3报酬,该报酬为总包Q的1/5;给雾节点4的B4报酬,该报酬为总包Q的1/2。
[0089] 具体而言:
[0090] 服务请求节点基于博弈策略,制定服务报酬总包以及分包策略,服务报酬总包为多个计算任务的服务报酬总和,分包策略为服务报酬总包的分配方案;
[0091] 服务请求节点将服务报酬总包及分包策略发送至雾中心节点,雾中心节点为多个雾节点的中心控制节点;
[0092] 雾中心节点将服务报酬总包及分包策略分发至其余每一个雾节点中,并实时收集其余每一个雾节点的反馈,并将其余每一个雾节点的反馈透发至服务请求节点中。例如,对于雾节点4给的报酬较高,则雾节点4愿意进行该任务的调度,则通过雾中心节点发送任务卸载响应至服务请求节点,完成后续的任务卸载操作。
[0093] 此外,若所述服务请求节点接收到两个及以上的雾节点(例如雾节点1和雾节点4)的任务卸载响应,则所述方法还包括:
[0094] 制定任务分配策略,并基于所述任务分配策略,将所述多个计算任务依次分配给所述两个及以上的雾节点,以使所述两个及以上的雾节点向所述服务请求节点提供不同计算任务的卸载。例如,将任务1和2分配给雾节点1来处理,任务3,4和5分配给雾节点4来处理。
[0095] S103.所述服务请求节点接收第一雾节点反馈的任务卸载响应,并基于所述任务卸载响应,所述第一雾节点向所述服务请求节点提供计算任务卸载,其中,所述第一雾节点属于接收了所述服务报酬及计算任务信息的所述一个或多个雾节点中的其中一个或多个雾节点。
[0096] 需要说明的是,第一雾节点是任何一个或多个能够反馈任务卸载响应的雾节点。其中,雾节点确定最优计算能力的过程为:
[0097] (1)服务请求节点作为博弈的跟随者,根据自身特征和网络环境,计算收入Fi和成本Gi,得出净收益Ui=Fi‑Gi。
[0098] (2)通过数学方法优化雾节点净收益,根据优化的净收益向雾节点提供最优任务计算能力百分比
[0099] 影响雾节点净收益的因素:
[0100] 1)雾节点收入:雾节点的收入取决于服务请求节点提供的任务卸载报酬。影响收入的因素有:服务请求节点支付的任务计算单价、任务数据量的大小、雾节点自身的计算速率。当收到来自服务请求节点的任务计算单价一定,雾节点自身计算速率越高、任务数据量越大时,雾节点收到来自服务请求节点的报酬越多,收入越高。
[0101] 2)雾节点成本:雾节点的成本取决于参与任务卸载的能耗,由于任务处理结果通常很小,因此可以省去任务结果的传输能耗。影响成本的因素有:提供给服务请求节点的计算能力大小、任务数据量的大小、雾节点CPU周期、雾节点每比特数据处理能耗。当提供给服务请求节点的计算能力越高、任务数据量越大、CPU周期越大、每比特数据处理能耗越高,雾节点自身能量消耗越大,成本也就越高。
[0102] 雾节点净收益和任务计算能力百分比的优化:
[0103]
[0104] s.t.τi≥0.
[0105] 本发明实施例还提供了一种海量数据的任务调度系统,包括存储器和处理器,所述存储器上存储有计算机可执行指令,所述处理器运行所述存储器上的计算机可执行指令时实现上述的方法。
[0106] 本发明实施例的方法及系统具有下列优点:
[0107] 本发明实施例中,服务请求节点生成博弈策略,并基于所述博弈策略,制定具备激励性质的服务报酬,并将所述服务报酬及所述计算任务信息分发至一个或多个雾节点,通过该激励机制,使得不同的雾节点在一定程度上愿意进行多任务的调度,有效提升了时延敏感型任务的任务调度效率,增强了任务处理时效。
[0108] 本发明实施例还提供一种系统,包括存储器和处理器,所述存储器上存储有计算机可执行指令,所述处理器运行所述存储器上的计算机可执行指令时实现上述的方法。
[0109] 本发明实施例还提供一种计算机可读存储介质,其上存储有计算机可执行指令,该计算机可执行指令用于执行上述实施例中的方法。
[0110] 图6为一个实施例中系统的硬件组成示意图。可以理解的是,图6仅仅示出了系统的简化设计。在实际应用中,系统还可以分别包含必要的其他元件,包含但不限于任意数量的输入/输出系统、处理器、控制器、存储器等,而所有可以实现本申请实施例的大数据管理方法的系统都在本申请的保护范围之内。
[0111] 存储器包括但不限于是随机存储记忆体(random access memory,RAM)、只读存储器(read至only memory,ROM)、可擦除可编程只读存储器(erasable programmable read only memory,EPROM)、或便携式只读存储器(compact disc read至only memory,CD至ROM),该存储器用于相关指令及数据。
[0112] 输入系统用于输入数据和/或信号,以及输出系统用于输出数据和/或信号。输出系统和输入系统可以是独立的器件,也可以是一个整体的器件。
[0113] 处理器可以包括是一个或多个处理器,例如包括一个或多个中央处理器(central processing unit,CPU),在处理器是一个CPU的情况下,该CPU可以是单核CPU,也可以是多核CPU。处理器还可以包括一个或多个专用处理器,专用处理器可以包括GPU、FPGA等,用于进行加速处理。
[0114] 存储器用于存储网络设备的程序代码和数据。
[0115] 处理器用于调用该存储器中的程序代码和数据,执行上述方法实施例中的步骤。具体可参见方法实施例中的描述,在此不再赘述。
[0116] 在本申请所提供的几个实施例中,应该理解到,所揭露的系统和方法,可以通过其它的方式实现。例如,该单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如,多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。所显示或讨论的相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口,系统或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
[0117] 作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
[0118] 在上述实施例中,可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时,可以全部或部分地以计算机程序产品的形式实现。该计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行该计算机程序指令时,全部或部分地产生按照本申请实施例的流程或功能。该计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程系统。该计算机指令可以存储在计算机可读存储介质中,或者通过该计算机可读存储介质进行传输。该计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(digital subscriber line,DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。该计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。该可用介质可以是只读存储器(read至only memory,ROM),或随机存储存储器(random access memory,RAM),或磁性介质,例如,软盘、硬盘、磁带、磁碟、或光介质,例如,数字通用光盘(digital versatile disc,DVD)、或者半导体介质,例如,固态硬盘(solid state disk,SSD)等。
[0119] 以上仅为本申请的具体实施方式,但本申请的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本申请揭露的技术范围内,可轻易想到各种等效的修改或替换,这些修改或替换都应涵盖在本申请的保护范围之内。因此,本申请的保护范围应以权利要求的保护范围为准。