一种具有集群自适应性的Storm任务部署与配置平台

摘要

一种具有集群自适应性的Storm任务部署与配置平台，属于实时流数据计算处理领域。通过运用此平台，Storm集群可感知节点间内部通信量大小与剩余资源，并结合用户发布的topology任务需求与集群剩余资源进行运行进程数目配置自调节，从而达到突破以往Storm调度方法都需要人为指定进程数目的限制。该平台向用户提供了一个友好的、集中式通信量监控接口，方便用户在任务程序中调用，实现负载和资源感知。另外在此平台内嵌实现了与以往Storm两阶段提交调度方法都不同的一阶段提交调度方法，实现了同一节点不同进程之间通信量优化。本发明只需要设定基本的优化阈值参数即可实现最优化的调度，极大的便利了集群用户和管理者。

说明书

技术领域

涉及一种具有集群自适应性的Storm任务部署与配置平台，属于海量数据处理、实时流计算领域。

背景技术

伴随着信息科技的发展，信息呈现爆发式增长。在很多信息处理问题中都需要对流式大数据进行实时的复杂计算，这是一种新的数据模式，与传统数据建模方式不同，这类数据适用瞬态数据流建模。例如微博热门、购物推荐、路由器数据报的统计等场景都需要在实时流数据上进行复杂的决策。

在传统的数据处理模式中，数据往往独立于应用，由系统负责将数据集中存储到磁盘中，数据是静态的、固定的集合。而流计算的核心价值在于对海量“运动”中的数据进行连续实时处理，显然这些数据的产生速度和规模都已超出了传统分布式系统的处理能力。

Storm是由Twitter公司开源的针对流数据实时处理的计算框架，是工业界技术最成熟的流计算框架之一。一个基本的Storm程序topology在结构上是一个边表示数据流，点代表计算组件的有向图。计算组件有两种：spout和bolt，spout是一个topology的数据tuple源头，bolt负责接收处理。每个bolt或者spout的实例化对象被称为一个task，一个或多个task由包含在JVM进程worker中的JAVA线程executor执行，worker对应着storm的逻辑概念slot。为保证数据处理的低延迟性，Storm对数据的处理完全基于内存。

Storm集群在流计算上有着卓越的成效，但在使用时需要用户在topology任务中配置运行进程数目，这个设定可能会造成诸多问题。

(1)运行进程数目过多，可能会导致运行topology的节点过多，通信开 销过大。这个问题同时也显现在Storm现有的一些调度优化的方法上。所有优化方法，其调度的先提条件是由用户决定运行进程数。如果运行进程数设定过多，会导致executor会散部到更多节点之上，这势必会造成节点间通信量增大，无论如何进行优化，都很难达到一个理想的调度方案。

(2)如果运行进程数设置的过少，executor会集中到少数的一个或几个worker，这样一方面可能会带来线程上下文切换的开销，更重要的一方面是可能会导致部分节点由于运行executor超载而导致宕机。如果工作节点宕机，其上的任务会由于Storm的可靠性保障机制而得到重做，高频率的任务重做也会导致较大的处理时延。

据我们所知，目前还没有任何方法可以很好的解决这个难题。现有的方法都集中在对Storm任务的调度问题上，忽略了对任务进程数目的设置，它们都需要用户在编写topology程序时明确地指定为该任务配置的运行进程数目。这是因为现有的所有调度算法都是遵照两阶段提交的设计思想，第一阶段：executor安排到worker(slot)，第二阶段：worker安排到node。而executor安排到worker的前提是需要知道worker的数目。虽然这些调度算法在一定程度上能够缓解节点过载与进程内部通信开销等问题，但是不能从根本上解决这个问题。因为由于用户无法实时的对集群的全局状态信息进行掌控，在这种情况下盲目地对任务设定运行进程数目，势必会对集群处理性能造成更严重的影响。

实际上，设定运行进程数目，应该结合任务本身需求以及集群剩余资源来决定。本发明致力于此难点，提出一种具有集群自适应性的Storm任务部署与配置平台能够很好的解决此项难题。

本平台设计实现了对集群节点间通信量监控，并提供监控数据给调度方法， 以便调度方法能够计算出通信量最小的调度方案；设计实现了配置自调节功能，部署本平台之后，集群可以依据监控模块提供的集群资源信息并结合任务本身需要而计算出最佳的配置。在此配置下，结合监控到的通信量数据可以计算出真正意义上的通信量最小的最佳调度方案。在此平台中我们也内嵌实现了基于这两项功能而实现的一阶段提交调度算法，该算法与以往的优化算法相比还有一个优势：该算法考虑到同一节点中不同进程之间的通信，以往的优化调度算法没有考虑此通信量，实际上，不同线程只有在同一进程中通过共享内存传递数据才不会产生通信量。

采用本平台的好处有：

(1)通过平台可实现通信量优化，提高了集群处理性能。

(2)简化集群用户操作，用户不需在编写topology任务时进行过多的参数配置，使用户可以专注于topology任务的编程。

(3)方便了集群管理，减少了用户任务的不合理配置，集群也减少了节点超载宕机的可能，这样集群更加稳定。

(4)平台向下兼容，具有很好的移植性。以往Storm组织架构不需要任何变动，只需要在原topology任务中调用本平台API，修改一下配置文件即可使用本平台。

发明内容

为克服Storm计算框架现有调度算法的种种不足以及突破必须由用户指定运行进程数目的限制。本发明提出一种具有集群自适应性的Storm任务部署与配置平台。通过运用此平台，Storm集群可感知节点间内部通信量大小与剩余资源，并结合用户发布的topology任务需求与集群剩余资源进行运行进程数目配置自调节，从而达到突破以往Storm调度方法都需要人为指定进程数目的限制。 该平台向用户提供了一个友好的、集中式通信量监控接口，方便用户在任务程序中调用，实现负载和资源感知。另外在此平台内嵌实现了与以往Storm两阶段提交调度方法都不同的一阶段提交调度方法，实现了同一节点不同进程之间通信量优化。与其他Storm优化调度方法复杂的参数配置要求不同，本发明只需要设定基本的优化阈值参数即可实现最优化的调度，极大的便利了集群用户和管理者。

首先，要想实现基于内部通信量的任务调度，必须能够在拓扑任务运行时持续监测节点间内部通信量。然而Storm计算框架源码没有实现相关功能或提供有关调用接口。本方法为用户提供一个友好的、集中式的集群监控API供用户在拓扑中调用，自动下发监测任务到集群的各个工作节点，每个工作节点都会运行一个监控线程，在拓扑运行在集群机器上时，监控线程还收集了节点CPU利用率信息和节点间通信量一起定时写入缓存数据库中。

其次，Storm计算框架的缺省调度方法以及其他Storm优化调度方法都依赖用户指定运行进程个数，人为设定运行进程具有盲目性，极易造成内部通信量过大，优化效果不明显的问题。本平台添突破了此项限制，设计实现了任务配置自调节功能。在任务分配时依据监控功能收集到的信息以及任务本身需求，进行任务配置调整，最终为整个集群的任务调度提供一个合理的任务配置参数。

再次，Storm计算框架的缺省调度方法以及其他Storm优化调度方法通过完成executor到slot分配、slot到node的分配这两个阶段才能完成调度。这就造成了在同一工作节点上的executor可能会被分配在不同的进程中。虽然这时没有节点通信开销，但是会存在进程间通信开销。从Storm源码可以看到分配在同一个slot中的executor是通过共享内存来传递数据。所以，本方法采用独特的executor到node分配的一阶段提交调度算法，确保同一拓扑任务在同 一节点上的executor都会被分配到同一个slot中去，从而达到减小进程间通信开销。

本发明解决技术问题所采用的技术方案是：

一种具有集群自适应性的Storm任务部署与配置平台，架构逻辑上分为资源层、数据层、应用层、用户层四个层次。

资源层主要包括硬件资源Storm集群以及部署在主控节点上的用以缓存监控数据以及集群资源信息的MySQL数据库，在storm集群每个工作节点上的监控线程由拓扑任务下发时触发；数据层通过JAVA对象从监控线程获取数据，通过JDBC驱动对数据库进行读写；数据层包括节点管理、通信量管理、数据管理三大模块；应用层分三个子模块：感知模块、调度模块、计算模块；用户层上，主要是监控API和集群配置文件，配置文件是集群自有配置文件storm.yaml，用户需要在这里配置使用本方法，而监控API供用户编程时调用；

该Storm任务部署与配置平台的工作流程包括三个部分：

(1)主要工作流程：检测当前是否达到触发计算重调度的时间阈值，如果没达到则继续调用Storm源码中的事物调度否则开计算最佳调度方案，在计算出最佳调度方案会进行触发调度的原因判断，如果是由于集群中某些节点过载引起的则直接触发重调度；如果是因为内部通信量的优化，则还需要进行一次判断，只有优化效果超过了用户规定的阈值，才会触发重调度；进行重调度时，会先释放所有工作节点上的可用端口，然后会对逻辑executor和物理executor进行匹配并按计算出的最佳分配方案进行物理安排；

(2)配置调节流程：先判断是否是初次分配，如果是初次分配，则利用初始配置尝试进行分配，如果不能完成分配，则依据CPU负载将超出的executor数目按比例分配到节点，增大调整这些节点上的最大可运行executor数目；如 果不是初次分配，则需要获取历史分配方案并尝试调整运行拓扑的节点个数，尝试折半减少节点个数成功后，所有的executor数目按CPU负载比例调整这些节点上的可运行最大executor数目；

(3)计算最佳调度方案的流程：先进行配置调节然后再转入具体分配流程；分配流程开始是获取内部executor通信列表，此列表的元素是executorPair，此列表由数据层的通信量管理模块编译所得，每个executorPair是由两个有通信的executor组成，并记录其间通信量，也就是传递的tuple个数；循环遍历此列表，对于每个executorPair做以下处理：executorPair中的两个executor分别为e1、e2，判断e1、e2是否都未被安排，如果都未被安排，则先判断是否有最近使用节点lastUsedNode，如果没有最近使用节点lastUsedNode，则寻找能够承载e1和e2负载的最小负载节点leastLoadedNode分配e1、e2，如果不能找到leastLoadedNode则e1、e2分别分配到能够负载其负载的最小负载节点，分配e2的节点被指定为最近使用节点；如果找到能够承载e1和e2负载的最小负载节点，则e1、e2都分配到此节点，并将此节点指定为最近使用节点；如果存在lastUsedNode，则先要检测lastUsedNode能否同时承载e1、e2，如果可以则都分配到lastUsedNode，如果不能则寻找能够承载e1、e2的最小负载节点leastLoadedNode，如果存在，分配e1和e2到此节点，并指定此节点为最近使用节点；如果不存在，则e1、e2分开分配到不同节点，优先使用最近使用节点其次是能够承载其负载的最小负载节点；如果e1、e2至少有一个已经被安排，则获取已经被安排的executor所在的节点列表nodeList，获取能够承载e1、e2中较大的负载的最小负载节点leastLoadedNode，判断leastLoadedNode和lastUsedNode是否在nodeList中，如果不在，则将其加入nodeList；尝试将e1、e2分配到nodeList中任意一个或两个节点，计算分配后的内部通信量，遍 历所有的安排方法，寻找最小通信量分配方案，如果出现内部通信量一样小的情况优先使用包含lastUsedNode的分配方案，记录最小的内部通信量以及相应的分配方案，最后被分配的最佳安排节点被指定为最近使用节点；如此循环直至内部executor通信列表被完整遍历，所有executor得到分配。

本项发明未改动Storm计算框架原架构，对以往的拓扑任务有良好的移植性与继承性。本发明的方法部署实施极其便利，用户只需在拓扑任务中调用API即可实现对内部通信量以及集群资源的监控。缓存数据库和调度算法生成器都部署在主控节点，并且该方法支持热插拔，用户只需在主控节点更改配置文件即可实现方法切换。在很多环境下，Storm集群都已部署完毕并已投入生产，如果轻易改动原有的架构或者部署会给用户带来极大的不便，甚至造成不必要的损失。

附图说明

图1是系统架构图

图2是平台工作流程图

图3是配置调节流程图

图4是计算最佳调度流程图

具体实施方式

下面结合附图对本专利进行具体实施说明。

如图1所示，该发明系统架构逻辑上分为资源层、数据层、应用层、用户层四个层次。

资源层主要包括硬件资源Storm集群以及部署在主控节点上的用以缓存监控数据以及集群资源信息的MySQL数据库，在storm集群每个工作节点上的监控线程由拓扑任务下发时触发。

数据层通过JAVA对象从监控线程获取数据，通过JDBC驱动对数据库进行读写。数据层包括节点管理、通信量管理、数据管理三大模块。节点管理的主要作用是从数据管理获取节点数据，进行再封装，以便计算最佳分配时向应用层提供多种参数情况下获取最小负载节点的查询服务。数据管理模块的作用是读写MySQL数据库的基本数据，作为其他模块与数据库交互的中介，提供了对拓扑、负载、通信量、历史分配、节点信息的读取和存储服务。数据管理模块还为算法生成器提供返回内部executor通信量列表、内部节点通信量列表、过载节点查询服务。通信量管理为当次调度逻辑计算提供中间数据，此模块编译当次调度的内部executor通信量列表和内部节点通信量列表，executor的安排和移除会直接影响此模块上的中间数据。此模块还提供包含executor的节点查询服务以及当前分配的查询服务。

应用层分三个子模块：感知模块、调度模块、计算模块。感知模块包括任务监控、进程监控、资源监控是监控API的具体实现。任务监控中的对象会封装线程ID以及task ID，另外提供tuple发送通知函数和tuple接收记录函数。用户在拓扑的spout节点调用tuple发送通知函数，在bolt节点调用tuple接受记录函数，从而实现线程之间传递的tuple个数。进程监控模块维护一个任务监控的列表，负责汇总线程间通信量并写入通信量管理和数据管理模块。具体步骤是：监控线程对bolt接收到的tuple做简单的解析，根据tuple的发出executor、接收executor以及两者之间传递的tuple个数编译内部executor通信列表，然后定时写入缓存数据库中。资源监控是对集群工作节点的CPU负载资源、可运行线程数目的监控，采用定时上报和行为触发两种方式实现监控数据读写，资源监控线程每个一段时间收集工作节点上的负载和运行线程数目信息并写入数据管理模块，在触发重调度时会实时写入一次数据。调度模块里 主要包含实现调度的逻辑操作，通过此模块编译出nodePair、executorPair便于计算通信量。executor安排与移除是基本的调度逻辑操作。计算模块中主要提供配置参数调节的计算以及最佳调度方案的计算。算法生成器在配置调节器给出参数数值之后会运用调度模块提供的基本操作，进行调度尝试，最终得到最佳的调度方法，后文会详细说明计算流程。

用户层上，主要是监控API和集群配置文件，配置文件是集群自有配置文件storm.yaml，用户需要在这里配置使用本方法，而监控API供用户编程时调用。

如图2所示，平台的主要流程是：检测当前是否达到触发计算重调度的时间阈值，如果没达到则继续调用Storm源码中的事物调度否则开计算最佳调度方案，在计算出最佳调度方案会进行触发调度的原因判断，如果是由于集群中某些节点过载引起的则直接触发重调度；如果是因为内部通信量的优化，则还需要进行一次判断，只有优化效果超过了用户规定的阈值，才会触发重调度。进行重调度时，会先释放所有工作节点上的可用端口，然后会对逻辑executor和物理executor进行匹配并按计算出的最佳分配方案进行物理安排。

如图3所示，配置调节流程是：先判断是否是初次分配，如果是初次分配，则利用初始配置尝试进行分配，如果不能完成分配，则依据CPU负载将超出的executor数目按比例分配到节点，增大调整这些节点上的最大可运行executor数目。如果不是初次分配，则需要获取历史分配方案并尝试调整运行拓扑的节点个数，尝试折半减少节点个数成功后，所有的executor数目按CPU负载比例调整这些节点上的可运行最大executor数目。

如图4所示，计算最佳调度方案的流程是：先进行配置调节然后再转入具体分配流程。分配流程开始是获取内部executor通信列表，此列表的元素是 executorPair，此列表由数据层的通信量管理模块编译所得，每个executorPair是由两个有通信的executor组成，并记录其间通信量，也就是传递的tuple个数。循环遍历此列表，对于每个executorPair做以下处理：executorPair中的两个executor分别为e1、e2，判断e1、e2是否都未被安排，如果都未被安排，则先判断是否有最近使用节点lastUsedNode，如果没有最近使用节点lastUsedNode，则寻找能够承载e1和e2负载的最小负载节点leastLoadedNode分配e1、e2，如果不能找到leastLoadedNode则e1、e2分别分配到能够负载其负载的最小负载节点，分配e2的节点被指定为最近使用节点。如果找到能够承载e1和e2负载的最小负载节点，则e1、e2都分配到此节点，并将此节点指定为最近使用节点。如果存在lastUsedNode，则先要检测lastUsedNode能否同时承载e1、e2，如果可以则都分配到lastUsedNode，如果不能则寻找能够承载e1、e2的最小负载节点leastLoadedNode，如果存在，分配e1和e2到此节点，并指定此节点为最近使用节点。如果不存在，则e1、e2分开分配到不同节点，优先使用最近使用节点其次是能够承载其负载的最小负载节点。如果e1、e2至少有一个已经被安排，则获取已经被安排的executor所在的节点列表nodeList，获取能够承载e1、e2中较大的负载的最小负载节点leastLoadedNode，判断leastLoadedNode和lastUsedNode是否在nodeList中，如果不在，则将其加入nodeList。尝试将e1、e2分配到nodeList中任意一个或两个节点，计算分配后的内部通信量，遍历所有的安排方法，寻找最小通信量分配方案，如果出现内部通信量一样小的情况优先使用包含lastUsedNode的分配方案，记录最小的内部通信量以及相应的分配方案，最后被分配的最佳安排节点被指定为最近使用节点。如此循环直至内部executor通信列表被完整遍历，所有executor得到分配。