用于spark streaming的资源动态分配和反馈方法及装置

本发明属于spark streaming技术领域，尤其涉及用于spark streaming的资源动态分配和反馈方法及装置。

相关技术中，spark已经成为广告、报表以及推荐系统等大数据计算场景中首选系统，因效率高，易用以及通用性越来越得到大家的青睐。流(Streaming)，在大数据时代为数据流处理，就像水流一样，是数据流；既然是数据流处理，就会想到数据的流入、数据的加工、数据的流出。spark程序是使用一个spark应用实例一次性对一批历史数据进行处理，sparkstreaming是将持续不断输入的数据流转换成多个batch(批处理)分片，使用一批spark应用实例进行处理。Spark Streaming是以Spark Core为核心构建的一种分布式的流式计算框架，适用于对实时任务进行在线任务计算和输出，实现对数据的实时处理。

相似的技术主要用于网络控制器和虚拟机的调度上。例如：平时用户都有网上购物的经历，用户在网站上进行的各种操作通过Spark Streaming流处理技术可以被监控，用户的购买爱好、关注度、交易等可以进行行为分析。在金融领域，通过Spark Streaming流处理技术可以对交易量很大的账号进行监控，防止罪犯、财产转移、防欺诈等。在网络安全性方面，黑客攻击时有发生，通过Spark Streaming流处理技术可以将某类可疑IP进行监控并结合机器学习训练模型匹配出当前请求是否属于黑客攻击。其他方面，如：垃圾邮件监控过滤、交通监控、网络监控、工业设备监控的背后都是Spark Streaming发挥强大流处理的地方。

现有的一些专利解决网络控制器的资源调度，包括：资源虚拟层，用于从多个底层设备中获取网络资源，并对网络资源进行虚拟化，以得到虚拟化网络资源；核心控制层，用于控制上层应用从资源虚拟层获取虚拟化网络资源，核心控制层分别与资源虚拟层和上层应用相连。根据该专利实施例的软件定义网络控制器，通过核心控制层对上层应用与资源虚拟层的数据交互进行监控，从而提高了网络资源的利用率，实现应用层对网络资源的动态弹性的调度。

另外有一些专利提供一种动态资源调度方法和动态资源调度器，能够提高动态资源调度的效率。该方法包括：确定多个虚拟机迁移动作；确定多个虚拟机迁移动作之间的依赖关系；根据多个虚拟机迁移动作之间的依赖关系，执行多个虚拟机迁移动作。该专利实施例在执行虚拟机迁移动作时考虑它们之间的依赖关系，而非简单地按照顺序执行虚拟机迁移动作，从而能够提高动态资源调度的效率。

发明人在实现本申请的过程中发现：现有技术需要人工对计算任务的负载与承载任务的机器状态进行监控，效率很低，而且容易出错。并且伸缩的原则全凭个人的经验，没有一套统一的标准，伸缩质量得不到保证。

本发明实施例提供一种用于spark streaming的资源动态分配和反馈方法及装置，用于至少解决上述技术问题之一。

第一方面，本发明实施例提供一种用于spark streaming的资源动态分配方法，包括：响应于首次接收的spark streaming任务数据流，计算处理所述spark streaming任务数据流需要使用的初始资源并向资源管理器发送初始资源使用申请，其中，所述初始资源对应多台处理设备；基于接收的与所述初始资源对应的多台处理设备反馈的运行时指标数据，计算所述多台处理设备的负载情况；至少基于所述多台处理设备的负载情况，周期性地计算与所述spark streaming任务数据流对应的动态分配资源并向所述资源管理器发送动态资源分配申请。

第二方面，本发明实施例提供一种用于spark streaming的资源动态反馈方法，包括：接收并处理首次接收的spark streaming任务数据流中的子数据流；采集对所述子数据流的处理状态以及处理所述子数据流时的运行时指标，其中，所述处理状态包括处理中和已完成；周期性地上报所述子数据流的处理状态和运行时指标。

第三方面，本发明实施例提供一种用于spark streaming的资源动态分配装置，包括：初始资源申请模块，配置为响应于首次接收的sparkstreaming任务数据流，计算处理所述spark streaming任务数据流需要使用的初始资源并向资源管理器发送初始资源使用申请，其中，所述初始资源对应多台处理设备；负载计算模块，配置为基于接收的与所述初始资源对应的多台处理设备反馈的运行时指标数据，计算所述多台处理设备的负载情况；以及动态分配模块，配置为至少基于所述多台处理设备的负载情况，周期性地计算与所述spark streaming任务数据流对应的动态分配资源并向所述资源管理器发送动态资源分配申请。

第四方面，本发明实施例提供一种用于spark streaming的资源动态反馈装置，包括：接收处理模块，配置为接收并处理首次接收的sparkstreaming任务数据流中的子数据流；采集模块，配置为采集对所述子数据流的处理状态以及处理所述子数据流时的运行时指标，其中，所述处理状态包括处理中和已完成；以及上报模块，配置为周期性地上报所述子数据流的处理状态和运行时指标。

第五方面，提供一种电子设备，其包括：至少一个处理器，以及与所述至少一个处理器通信连接的存储器，其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行本发明任一实施例的用于spark streaming的资源动态分配和反馈方法的步骤。

第六方面，本发明实施例还提供一种计算机程序产品，所述计算机程序产品包括存储在非易失性计算机可读存储介质上的计算机程序，所述计算机程序包括程序指令，当所述程序指令被计算机执行时，使所述计算机执行本发明任一实施例的用于sparkstreaming的资源动态分配和反馈方法的步骤。

本申请实施例的方法和装置通过先初始化需要的处理设备，之后在根据各处理设备反馈的负载情况，周期性地进行资源动态分配调整，能够使得资源能够一直处于一个比较优化的使用状态，spark streaming任务数据流也能得到及时的处理，并且整个过程智能完成，无需人工干预。

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

图1为本发明一实施例提供的一种用于spark streaming的资源动态分配方法的流程图；

图2为本发明一实施例提供的另一种用于spark streaming的资源动态分配方法的流程图；

图3为本发明一实施例提供的又一种用于spark streaming的资源动态分配方法的流程图；

图4为本发明一实施例提供的再一种用于spark streaming的资源动态分配方法的流程图；

图5为本发明一实施例提供的一种用于spark streaming的资源动态反馈方法的流程图；

图6为本发明一实施例提供的一种针对spark streaming的自动扩缩容系统的模块图；

图7为本发明一实施例提供的一种用于spark streaming的资源动态分配装置的框图；

图8为本发明一实施例提供的一种用于spark streaming的资源动态反馈装置的框图；

图9是本发明一实施例提供的电子设备的结构示意图。

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

请参考图1，其示出了本申请的用于spark streaming的资源动态分配方法一实施例的流程图，本实施例的用于spark streaming的资源动态分配方法可以适用于用到了spark streaming的各种设备，主要是对现有的sparkstreaming的优化。

如图1所示，在步骤101中，响应于首次接收的spark streaming任务数据流，计算处理spark streaming任务数据流需要使用的初始资源并向资源管理器发送初始资源使用申请，其中，初始资源对应多台处理设备；

之后，在步骤102中，基于接收的与初始资源对应的多台处理设备反馈的运行时指标数据，计算多台处理设备的负载情况；

最后，在步骤103中，至少基于多台处理设备的负载情况，周期性地计算与sparkstreaming任务数据流对应的动态分配资源并向资源管理器发送动态资源分配申请。

在本实施例中，对于步骤101，资源动态分配装置对于新接收的sparkstreaming任务数据流，因为所有的处理设备还都没有开始处理，所以要先初始化，即先计算处理sparkstreaming任务数据流需要使用的初始资源，然后再向资源管理器或者资源管理模块申请相应的资源，该初始资源对应多台处理设备，其中，处理设备包括计算机等具有处理能力的设备。对于步骤102，当向资源管理器申请了相应的资源后，处理设备就会开始处理sparkstreaming任务数据流，之后资源动态分配装置会接收到处理设备反馈的运行时指标数据，然后根据该运行时指标数据计算多台处理设备的负载情况，其中，运行时指标数据可以包括以下数据中的一种或多种：处理延迟、每秒处理消息数、内存使用率、CPU使用率、磁盘IO以及网络流量。最后，对于步骤103，至少根据多台设备的负载情况，周期性地计算与sparkstreaming任务数据流对应的动态分配资源并向资源管理器发送动态资源分配申请，另外，还可以根据各个设备的处理速率以及故障率等，允许一定的容错率，这样整个系统更不易崩溃。

本实施例的方法通过先初始化需要的处理设备，之后在根据各处理设备反馈的负载情况，周期性地进行资源动态分配调整，能够使得资源能够一直处于一个比较优化的使用状态，spark streaming任务数据流也能得到及时的处理，并且整个过程智能完成，无需人工干预。

进一步参考图2，其示出了本申请的用于spark streaming的资源动态分配方法的另一实施例的流程图。该流程图图2主要是针对图1中步骤101进一步细化的步骤的流程图。

如图2所示，在步骤201中，响应于首次接收的spark streaming任务数据流，获取数据流的第一到达速率；

之后，在步骤202中，基于第一到达速率，计算需要使用的初始资源，其中，初始资源对应多台处理设备；

最后，在步骤203中，向资源管理器发送初始资源使用申请，并基于资源管理器的反馈搭建多条数据传输通道对接多台处理设备。

在本实施例中，对于步骤201，资源动态分配装置响应于首次接收的sparkstreaming任务数据流，获取spark streaming任务数据流的第一到达速率，基于该到达速率可以知道需要什么处理速率才能与之匹配。之后，对于步骤202，基于该第一到达速率，计算需要使用的初始资源，其中，初始资源对应多台处理设备。例如，每一台处理设备都会有一个处理速率，将多台设备的处理速率与spark streaming任务数据流的第一到达速率相匹配就能得到需要多少台处理设备并行处理这个数据流，当然，有一些在后的任务可能会需要用到在前的任务的处理结果，这种情况可以考虑将其分在同一台设备上处理，在具体的实现过程中，还会需要考虑其他很多因素，本申请在此没有限制。最后，对于步骤203，根据计算得到的需要使用的初始资源向资源管理器发送初始资源使用申请，然后得到资源管理器的确认之后(或者其实资源动态分配装置预先知道资源管理器那有足够的资源就不用资源管理器再确认了)，搭建多条数据传输通道对接之前资源管理器所分配的多台处理设备进行并行数据处理。

本实施例的方法通过获取spark streaming任务数据流的第一到达速率，之后根据该速率可以计算得到初始资源，根据计算得到的初始资源进行资源的申请和对接，从而可以使得资源与任务更好地匹配。

进一步参考图3，其示出了本申请的用于spark streaming的资源动态分配方法的又一实施例的流程图。该流程图图3主要是针对图1中步骤103进一步细化的步骤的流程图。

如图3所示，在步骤301中，获取spark streaming任务数据流的第二达到速率；

之后，在步骤302中，基于第二达到速率和多台处理设备的负载情况，周期性地计算计算与spark streaming任务数据流对应的动态分配资源，其中，动态分配资源包括增加处理设备、减少处理设备和维持现状；

最后，在步骤303中，若需要增加或减少处理设备，向资源管理器发送动态资源分配申请，并基于资源管理器的反馈搭建或拆除某些数据传输通道对应于增加或删除的某些处理设备。

在本实施例中，对于步骤301，获取spark streaming任务数据流的第二达到速率，可以设一个固定的周期，这样每一个周期都进行一次资源动态调整，而获取第二到达速率就是需要做的第一件事。之后，对于步骤302，基于该第二到达速率和多台设备的负载情况周期性地计算与sparkstreaming任务数据流对应的动态分配资源，例如第二到达速率相比第一到达速率增加了，说明需要增加更多的处理设备了，或者正在处理任务的处理设备负载超过预定的高负荷了，也说明需要增加新的处理设备了；另一方面，如果速率减慢了，或者负载低于预定的低负荷了，则说明需要减少处理设备来了，本申请在此没有限制。最后，对于步骤303，如果需要增加或减少处理设备，则可以向资源管理器发送动态资源分配申请，要求分配更多的处理设备或者减少某些处理设备，即搭建或拆除某些数据传输通道对应于增加或删除的某些处理设备，以实现对处理设备的利用的最大化，并且不容易使得系统超负荷工作导致崩溃。

本实施例的方法通过周期性地获取spark streaming任务数据流的第二达到速率和计算与spark streaming任务数据流对应的动态分配资源，能够使得处理设备能够被周期性地调整，从而使得资源的利用率更高，且降低系统宕机的几率。

进一步参考图4，本申请的用于spark streaming的资源动态分配方法的再一实施例的流程图。该流程图图4主要是针对图3中步骤303进一步细化的步骤的流程图。需要说明的是，步骤404是与步骤401、402、403并列的步骤，进一步地，步骤402和步骤403也是并列的步骤，这些并列的步骤并不具有严格的先后顺序关系。

如图4所示，在步骤401中，若需要减少处理设备，基于多台处理设备的负载情况确定负载为零的处理设备的数量；

在步骤402中，若需要减少的设备的数量不大于负载为零的处理设备的数量，则按照需要减少的设备的数量相应地减少负载为零的处理设备，并反馈给资源管理器；

在步骤403中，若需要减少的设备的数量大于负载为零的处理设备的数量，则减少所有负载为零的处理设备，并反馈给资源管理器；

在步骤404中，若需要增加处理设备，则向资源管理器发送动态资源增加申请。

在本实施例中，对于步骤401，若需要减少处理设备，基于多台处理设备的负载情况确定负载为零的处理设备的数量，负载为零说明该处理设备处于空闲状态，此时需要适当的减少处理设备以解放该空闲处理设备让它能够被用于处理别的任务。对于步骤402，若计算出来的需要减少的处理设备的数量不大于负载为零的处理设备的数量，则按照需要减少的设备的数量相应地减少负载为零的处理设备，并反馈给资源管理器；对于步骤403，若需要减少的设备的数量大于负载为零的处理设备的数量，则减少所有负载为零的处理设备，并反馈给资源管理器。当然，在另一些可选的实施例中，也可以直接根据负载情况减少所有负载为零的处理设备，在此不再赘述。对于步骤404，若需要增加处理设备，则向资源管理器发送动态资源增加申请，从而申请增加新的处理设备来进行任务处理。

本实施例的方法通过对减少和增加处理设备的情况进行具体的说明，能够使得减少和增加的情况更加严谨，使得资源动态调整不会破坏现有的处理设备正在处理的任务，从而在维持现有的处理设备的状态的基础上更加优化资源动态调整的过程。

请参考图5，其示出了本发明一实施例提供的一种用于spark streaming的资源动态反馈方法的流程图。本实施例的用于spark streaming的资源动态分配方法可以适用于用到了spark streaming的各种设备，主要是对现有的spark streaming的反馈的优化。

如图5所示，在步骤501中，接收并处理spark streaming任务数据流中的子数据流；

在步骤502中，采集对子数据流的处理状态以及处理子数据流时的运行时指标，其中，处理状态包括处理中和已完成；

在步骤503中，周期性地上报子数据流的处理状态和运行时指标。

在本实施例中，对于步骤501，资源动态反馈装置接收到资源动态分配装置通过资源管理器首次分配的spark streaming任务数据流中的子数据流后，对子数据流进行处理。之后，对于步骤502，反馈装置还采集对子数据流的处理状态以及所管辖的处理设备处理子数据流时的运行时指标，其中，处理状态包括处理中和已完成两种状态，运行时指标数据可以包括以下数据中的一种或多种：处理延迟、每秒处理消息数、内存使用率、CPU使用率、磁盘IO以及网络流量。最后，对于步骤503，周期性地向分配装置上报子数据流的处理状态和运行时指标。

本实施例的方法通过接收并处理spark streaming任务数据流中的子数据流，之后采集任务的处理状态和运行时指标数据，然后周期性地反馈给分配装置，可以使得分配装置能够得到第一手的反馈数据，及时周期性地进行资源动态调整。

以下给出一个具体实施例，以使本领域技术人员能够更好地理解本申请的方案。

发明人发现现有技术中存在的这些缺陷是由于上面提到的相似的技术中的以下内容导致的：分布式计算任务的资源动态分配主要依靠对于集整体资源和任务的处理资源的动态计算得出，在实现和模型设计上有一定的难度。

请参考图6，其示出了本发明一实施例提供的一种针对spark streaming的自动扩缩容系统的模块图，示出了模块之间的交互。

如图6所示，这里主要有两个模块，Resource Scheduler(资源调度模块)用于对资源进行动态管理、计算和资源申请，Metrics Provider(计量提供模块)用于运行时指标的收集和将动态上报给Resource Scheduler以进行资源的动态调整。

其中，Resource Manager(资源管理模块)用于管理资源集的资源，包括CPU，内存和硬盘，Node Manager(节点管理模块)用于管理单台机器资源和任务，而Container(容器)指单机上单个任务的抽象，App Master(应用主节点)是指应用的主节点，用于监控任务在集中的运行状态。

Resource Scheduler主要负责任务资源申请，任务动态运行信息的收集，动态资源的计算，完成资源在运行态的动态调整。

Metrics Provider主要负责提供Resource Scheduler计算动态资源所需要的运行时指标数据，提供准确的数据支撑。

根据图6中所示，首先，Resource Scheduler接收提交的任务(submit task)；然后Resource Scheduler向Resource Manager申请资源(request resource)；之后ResourceManager将任务分配下去，在集中开始处理(start task in cluster)；然后各个NodeManager管理单台机器上的资源和任务，内部的App Master监控任务在集中的运行状态，之后由Node Manager反馈给Resource Scheduler(send runtime Metrics to ResourceScheduler)；然后Resource Scheduler再根据反馈的信息重新规划，向Resource Manager申请资源，周而复始，形成资源动态管理。

发明人在实现本申请的方案之前也考虑到手工进行调整，但效率不好，而且大部分都要依赖经验。

本申请的方案能够达到的效果：通过统一的动态资源调度框架来完成对于计算资源的动态扩缩容，减少人工进行干预；通过运行时指标收集和资源动态计算，实现资源的动态精准分配和调整。

请参考图7，其示出了本发明一实施例提供的用于spark streaming的资源动态分配装置的框图。

如图7所示，用于spark streaming的资源动态分配装置700，包括请求模块710、负载计算模块720和动态分配模块730。

其中，初始资源申请模块710，配置为响应于首次接收的spark streaming任务数据流，计算处理所述spark streaming任务数据流需要使用的初始资源并向资源管理器发送初始资源使用申请，其中，所述初始资源对应多台处理设备；负载计算模块720，配置为基于接收的与所述初始资源对应的多台处理设备反馈的运行时指标数据，计算所述多台处理设备的负载情况；以及动态分配模块730，配置为至少基于所述多台处理设备的负载情况，周期性地计算与所述spark streaming任务数据流对应的动态分配资源并向所述资源管理器发送动态资源分配申请。

在一些可选的实施例中，上述初始资源申请模块710进一步配置为：响应于首次接收的spark streaming任务数据流，获取所述数据流的第一到达速率；基于所述第一到达速率，计算需要使用的初始资源，其中，所述初始资源对应多台处理设备；以及向资源管理器发送初始资源使用申请，并基于所述资源管理器的反馈搭建多条数据传输通道对接所述多台处理设备。

在一些可选的实施例中，上述动态分配模块730进一步配置为：获取所述sparkstreaming任务数据流的第二达到速率；基于所述第二达到速率和所述多台处理设备的负载情况，周期性地计算计算与所述spark streaming任务数据流对应的动态分配资源，其中，所述动态分配资源包括增加处理设备、减少处理设备和维持现状；以及若需要增加或减少处理设备，向所述资源管理器发送动态资源分配申请，并基于所述资源管理器的反馈搭建或拆除某些数据传输通道对应于增加或删除的某些处理设备。

进一步地，上述“若需要增加或减少处理设备，向所述资源管理器发送动态资源分配申请”的模块进一步配置为：若需要减少处理设备，基于所述多台处理设备的负载情况确定负载为零的处理设备的数量；若需要减少的设备的数量不大于负载为零的处理设备的数量，则按照所述需要减少的设备的数量相应地减少负载为零的处理设备，并反馈给所述资源管理器；若需要减少的设备的数量大于负载为零的处理设备的数量，则减少所有负载为零的处理设备，并反馈给所述资源管理器；以及若需要增加处理设备，则向所述资源管理器发送动态资源增加申请。

在一些可选的实施例中，上述运行时指标包括以下一个或多个的组合：处理延迟、每秒处理消息数、内存使用率、CPU使用率、磁盘IO以及网络流量。

请参考图8，其示出了本发明一实施例提供的用于spark streaming的资源动态反馈装置的框图

如图8所示，用于spark streaming的资源动态反馈装置800，包括接收处理模块810、采集模块820和上报模块830。

其中，接收处理模块810，配置为接收并处理首次接收的spark streaming任务数据流中的子数据流；采集模块820，配置为采集对所述子数据流的处理状态以及处理所述子数据流时的运行时指标，其中，所述处理状态包括处理中和已完成；上报模块830，配置为周期性地上报所述子数据流的处理状态和运行时指标。

应当理解，图7和图8中记载的诸模块与参考图1、图2、图3、图4和图5中描述的方法中的各个步骤相对应。由此，上文针对方法描述的操作和特征以及相应的技术效果同样适用于图7和图8中的诸模块，在此不再赘述。

值得注意的是，本公开的实施例中的模块并不用于限制本公开的方案，例如负载计算模块可以描述为基于接收的与所述初始资源对应的多台处理设备反馈的运行时指标数据，计算所述多台处理设备的负载情况的模块。另外，还可以通过硬件处理器来实现相关功能模块，例如负载计算模块也可以用处理器实现，在此不再赘述。

在另一些实施例中，本发明实施例还提供了一种非易失性计算机存储介质，计算机存储介质存储有计算机可执行指令，该计算机可执行指令可执行上述任意方法实施例中的用于spark streaming的资源动态分配方法；

作为一种实施方式，本发明的非易失性计算机存储介质存储有计算机可执行指令，计算机可执行指令设置为：

响应于首次接收的spark streaming任务数据流，计算处理所述spark streaming任务数据流需要使用的初始资源并向资源管理器发送初始资源使用申请，其中，所述初始资源对应多台处理设备；

基于接收的与所述初始资源对应的多台处理设备反馈的运行时指标数据，计算所述多台处理设备的负载情况；

至少基于所述多台处理设备的负载情况，周期性地计算与所述spark streaming任务数据流对应的动态分配资源并向所述资源管理器发送动态资源分配申请。

作为另一种实施方式，本发明的非易失性计算机存储介质存储有计算机可执行指令，计算机可执行指令设置为：

接收并处理spark streaming任务数据流中的子数据流；

采集对所述子数据流的处理状态以及处理所述子数据流时的运行时指标，其中，所述处理状态包括处理中和已完成；

周期性地上报所述子数据流的处理状态和运行时指标。

作为一种非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块，如本发明实施例中的用于spark streaming的资源动态分配方法对应的程序指令/模块。一个或者多个程序指令存储在非易失性计算机可读存储介质中，当被处理器执行时，执行上述任意方法实施例中的用于spark streaming的资源动态分配或反馈方法。

非易失性计算机可读存储介质可以包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需要的应用程序；存储数据区可存储根据用于sparkstreaming的资源动态分配装置的使用所创建的数据等。此外，非易失性计算机可读存储介质可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实施例中，非易失性计算机可读存储介质可选包括相对于处理器远程设置的存储器，这些远程存储器可以通过网络连接至用于spark streaming的资源动态分配装置。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

本发明实施例还提供一种计算机程序产品，计算机程序产品包括存储在非易失性计算机可读存储介质上的计算机程序，计算机程序包括程序指令，当程序指令被计算机执行时，使计算机执行上述任一项用于spark streaming的资源动态分配或反馈方法。

图9是本发明实施例提供的电子设备的结构示意图，如图9所示，该设备包括：一个或多个处理器910以及存储器920，图9中以一个处理器910为例。用于spark streaming的资源动态分配方法的设备还可以包括：输入装置930和输出装置940。处理器910、存储器920、输入装置930和输出装置940可以通过总线或者其他方式连接，图9中以通过总线连接为例。存储器920为上述的非易失性计算机可读存储介质。处理器910通过运行存储在存储器920中的非易失性软件程序、指令以及模块，从而执行服务器的各种功能应用以及数据处理，即实现上述方法实施例用于spark streaming的资源动态分配方法。输入装置930可接收输入的数字或字符信息，以及产生与信息投放装置的用户设置以及功能控制有关的键信号输入。输出装置940可包括显示屏等显示设备。

上述产品可执行本发明实施例所提供的方法，具备执行方法相应的功能模块和有益效果。未在本实施例中详尽描述的技术细节，可参见本发明实施例所提供的方法。

作为一种实施方式，上述电子设备，包括：至少一个处理器；以及，与至少一个处理器通信连接的存储器；其中，存储器存储有可被至少一个处理器执行的指令，指令被至少一个处理器执行，以使至少一个处理器能够：

响应于首次接收的spark streaming任务数据流，计算处理所述spark streaming任务数据流需要使用的初始资源并向资源管理器发送初始资源使用申请，其中，所述初始资源对应多台处理设备；

基于接收的与所述初始资源对应的多台处理设备反馈的运行时指标数据，计算所述多台处理设备的负载情况；

至少基于所述多台处理设备的负载情况，周期性地计算与所述spark streaming任务数据流对应的动态分配资源并向所述资源管理器发送动态资源分配申请。

作为另一种实施方式，上述电子设备，包括：至少一个处理器；以及，与至少一个处理器通信连接的存储器；其中，存储器存储有可被至少一个处理器执行的指令，指令被至少一个处理器执行，以使至少一个处理器能够：

接收并处理spark streaming任务数据流中的子数据流；

采集对所述子数据流的处理状态以及处理所述子数据流时的运行时指标，其中，所述处理状态包括处理中和已完成；

周期性地上报所述子数据流的处理状态和运行时指标

本申请实施例的电子设备以多种形式存在，包括但不限于：

(1)移动通信设备：这类设备的特点是具备移动通信功能，并且以提供话音、数据通信为主要目标。这类终端包括:智能手机(例如iPhone)、多媒体手机、功能性手机，以及低端手机等。

(2)超移动个人计算机设备：这类设备属于个人计算机的范畴，有计算和处理功能，一般也具备移动上网特性。这类终端包括：PDA、MID和UMPC设备等，例如iPad。

(3)便携式娱乐设备：这类设备可以显示和播放多媒体内容。该类设备包括:音频、视频播放器(例如iPod)，掌上游戏机，电子书，以及智能玩具和便携式车载导航设备。

(4)服务器:提供计算服务的设备，服务器的构成包括处理器、硬盘、内存、系统总线等，服务器和通用的计算机架构类似，但是由于需要提供高可靠的服务，因此在处理能力、稳定性、可靠性、安全性、可扩展性、可管理性等方面要求较高。

(5)其他具有数据交互功能的电子装置。

以上所描述的装置实施例仅仅是示意性的，其中作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分的方法。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。