流式云服务作业调度

论文总字数：28592字

摘 要

Storm是分布式的实时流式计算系统，它采用事件流的形式，通过多个组件构成一个处理网络框架，能保证数据在低延迟下被有效地处理，能够迎合数据实时处理的要求。Storm内置的默认调度器以轮询（round-robin）的方式把任务相对平衡地分配给集群中的工作节点。这种调度算法负载平衡且易于实现，但在实际应用中仍然存在一些问题，如：默认调度策略无法达到精细化的调度管理以均衡不同流式作业中多个工作节点之间的负载，同时，默认调度方案缺乏对数据本地化的考虑。也就是说，正如其他的大数据处理系统，Storm也并没有配置智能调度机制。由于默认的调度机制无法完备探察到集群中的资源可用性和任务的资源需求，在集群运行中会很容易出现资源使用的盲目性。在流式任务执行的过程中，任务具有相互依赖性，因此不同任务调度序列将会最终导致完成时间的差异。本文将通过构建Storm实时数据处理的云计算平台，面向流式云服务作业调度，提出作业调度算法的改进方案，实现负载均衡、灵活应对多种任务需求的流式云服务作业调度。实验结果表明，所提出的算法能够有效实现数据本地化、减少数据传输消耗，从而最小化所有流作业的完工时间。

关键词：Storm，云计算，作业调度，流式任务

Abstract

Storm is a distributed real-time streaming computing system, which adopts the form of event flow and forms a processing network framework through multiple components, which can ensure that the data is processed effectively under low delay. It can meet the requirements of real-time data processing. Storm's built-in default scheduler allocates tasks to the work nodes in the cluster in a relatively balanced manner in the form of polling (round-robin). This scheduling algorithm is load-balanced and easy to implement, but there are still some problems in practical applications, such as: the default scheduling strategy can not achieve fine scheduling management to balance the load between multiple work nodes in different flow jobs, at the same time, The default scheduling scheme lacks consideration for data localization. That is to say, like other big data processing systems, Storm does not have an intelligent scheduling mechanism. Because the default scheduling mechanism can not fully detect the resource availability and task resource requirements in the cluster, the blindness of resource use will easily occur in the cluster operation. In the process of streaming task execution, the task is interdependent, so different task scheduling sequences will eventually lead to the difference of completion time. In this paper, by constructing the cloud computing platform of Storm real-time data processing, facing the streaming cloud service job scheduling, an improved scheme of job scheduling algorithm is proposed to realize load balancing and flexibly respond to a variety of task requirements. The experimental results show that the data localization can be effectively realized, the data transmission consumption can be reduced, and the completion time of all stream jobs can be minimized.

KEY WORDS: Storm, cloud computing, job scheduling, streaming tasks

目 录

第一章 绪论 1

1.1 研究背景和意义 1

1.2 研究现状分析 2

1.3研究目标与内容 5

1.4 论文组织结构 5

第二章 Storm系统及其调度机制 6

2.1 Storm系统简介 6

2.1.1 Storm系统定义 6

2.1.2 Storm系统组成部分 7

2.1.3 Storm模型架构 10

2.1.4 Storm部署框架 11

2.1.5 Storm作业拓扑提交流程 13

2.2 Storm调度机制 13

2.2.1 Storm内置的调度算法 13

2.2.2 JStorm调度算法 14

2.2.3 R-Storm调度算法 16

2.2.4 已有算法中存在的问题 17

第三章 基于逆向拓扑分析的改进算法 18

3.1 整体框架 18

3.2 遍历分析拓扑 19

3.4 分配策略 22

3.5 在Storm框架上的实现 24

第四章 实验与结果分析 25

4.1 实验环境 25

4.2 实验结果分析 27

第五章 未来工作展望 34

致 谢 36

第一章 绪论

1.1 研究背景和意义

在《大数据时代》中，作者Viktor首次确切地提到大数据（big data），书中直接地指出了大数据有四个特点：迅速、巨量、多样和价值（Velocity, Volume, Variety amp; Value）。2014年，我国的《政府工作报告》提出“大数据”的概念，这是我国大数据发展史的重要起点之一。作为一种新兴的技术热点和产业概念，大数据开始渗透进中国的各个领域产业发展中的方方面面。再进一步的是，伴随着《大数据产业发展规划》的公布，大数据开始逐渐与实体经济相互融合，其作为我国数字领域经济建设的重要组成部分，已然成为了一大吸睛热点，在各大媒体头条频频出现。2017年，我国大数据相关产业的经济规模高达4700亿元人民币，增长十分迅速。如今，大数据与商业、金融、医疗、文教等传统领域的融合越来越紧密，与电子商务等新时代经济领域的结合效益更为显著，在推动传统产业的革新、促进传统行业转型升级上，大数据发挥的作用越来越巨大，产生的影响也越来越深远。大数据企业数量的迅速增长正推动整个产业迅猛发展。大数据的迅速发展依托于网络数据量的爆炸式上升，而最近的数据增长主要出现在搜索引擎、电子购物、社交网络等数据依赖型、数据密集型服务领域。随着社会步入了一个数据主导的时代，实现实时处理海量数据成为了人们关心的一项重要挑战。在大数据的各项结构中，非结构化数据在主要构成部分中的占比日渐增大。而非结构化数据在用户与关系型数据库之间的传输、用于分析或者下载时，都会消耗掉较多的成本，这是大数据所面临的一个重大问题。

由于实时的大型数据分析处理需要向大量的用户或计算机分配任务，所以大数据的计算、分析和传输往往会和云服务紧密联系在一起。云计算是通过大量的远程服务器而非本地计算机，实现远程分布式计算,常被用以满足用户的远程传输、计算等需求^[14]。对于企业级用户，云服务的意义显得格外非凡。云服务能够将大量资源负载分布到需要的服务应用平台上，进而根据用户需求，来提供对计算机服务系统或者云存储系统的访问。云服务云计算在近几年得到了迅猛而稳健的发展，现在有越来越多的公司和从业者开始进入相关产业的技术研究以及产品开发等，产业之中含有着无限商机。在云计算领域巨大的商业前景和研究热度中，国内外各大IT企业相继推出自己的云计算平台和产品，如：Google的App_Engine，Amazon的Web_Service，百度的个人云盘服务，VMware的vSphere，Microsoft的Azure_Service_Platform，Apple的iCloud云存储平台等。而传统硬件厂商诸如Intel、Cisco和华为等，也逐渐开始向云计算服务领域进发，逐步完成产业转型和企业增值。由此可见，云计算已然收获了来自于学术界和产业界等多个领域的充分关注。

随着近年以来数据业务的激增、云计算需求的快速增长，缺少“实时的分布式数据处理系统”已成为日渐被人们重视的话题，Storm的出现很好地契合了大数据生态环境的渴求。Storm是分布式的实时流式计算系统，它采用事件流的形式，通过多个组件构成一个处理网络框架，能保证数据在低延迟下被有效地处理，能够迎合数据实时处理的要求。Storm中默认的调度器以轮询（round-robin）的方式把任务相对平衡地分配给集群中的工作节点，能保证处理数据的可靠性和低延迟，适合实时处理的需求。这种调度算法负载平衡且易于实现，但在实际应用中仍然存在一些问题，如：默认调度策略无法达到精细化的调度管理以均衡不同流式作业中多个工作节点之间的负载，同时，默认调度方案缺乏对数据本地化的考虑。也就是说，正如其他的大数据处理系统，Storm也并没有配置智能调度机制。由于默认的调度机制无法完备探察到集群中的资源可用性和任务的资源需求，在集群运行中会很容易出现资源使用的盲目性。因此，设计出一种可以应对不同作业调度序列的智能算法成为了近年来热门的研究领域。

1.2 研究现状分析

国内外学者针对云计算中作业调度算法以及Storm默认调度策略的不足，提出并探究了改进的Storm调度算法，其中的作业调度算法更多地会关注降低通信延迟、提高资源利用率等。部分调度策略会兼顾用户的服务质量（QoS）的同时减少作业完成时间和所花费用等。下面分别对云计算中作业调度算法和Storm调度算法的研究现状进行探讨说明。

第一方面是针对云计算作业调度算法的改进问题。文献[1]提出了基于节点资源监控的RBS（Resource Based Schedule）任务调度算法和支持单节点的SNS(Single Node Schedule)任务调度算法。并在RBS算法和SNS算法的基础上，设计并实现了相应的Topology任务调度器。基于RBS算法的任务调度器可根据工作节点资源的使用情况，将工作进程调度到资源利用率较低的节点上；基于SNS算法的调度器可将一些只执行简单运算并且没有太多中间状态的Topology的多个工作进程调度到一个单一的物理节点上运行。针对Storm中控制节点的单点失效问题，通过Zookeeper协调服务实现主控制节点选举和主从控制节点之间的状态同步。侯明霞提出一种云计算环境下基于改进蚁群算法的作业调度算法：任务在虚拟机上的总成本值决定其调度顺序（总是被分配到总成本最小的虚拟机上）^[2]。该算法在实现该目标的同时,兼顾了用户的服务质量(QoS),如作业完成时间和所花费用,并考虑了云计算中虚拟机资源的负载均衡。对于作业请求数较多、数据中心资源不足的情况，提出了一种基于接入控制的作业调度策略：获得到来的作业请求QoS要求，计算作业的执行时间和成本；判断作业优先级实施抢占机制；利用惩罚机制，按照线性关系计算回报率；选择回报率最大的作业接收策略。文献[3]进一步提出了基于蚁群算法的资源感知任务调度算法（RSBA），在调度过程中将工作节点的资源动态变化表示为蚂蚁运动所需的信息素，觅食的蚂蚁身上带着自身资源需求标签，任务调度过程类似蚂蚁觅食过程。计算每个topology的所有component的executor数量，对每种资源类型的component，分别计算权值，计算topology中各类资源所需要的worker数量，在运行周期内将topology中相互通信的executor对进行组合，增加一个新的executor队列并对应相应的资源，最后将工作节点上的资源状态转换为蚁群算法中的信息素，按浓度高低排列进行任务分配。

第二个方面是针对改进Storm调度策略的问题。论文[4]中提出的算法首先计算Bolt的容量，然后分析消息队列拥塞度，最后改变拓扑的一些参数以动态消除性能瓶颈。工作流程如下：第一步，bolt的容量计算与bolt的消息队列拥塞度分析；第二步，在以上这些值的基础上相应地调整参数；第三步，executors到slots分配与slots到工作节点分配。所提出的方法使用bolt容量策略和bolt消息队列拥挤度分析逐步识别性能瓶颈。通过分析这些值，可以相应地调整性能参数，而无需停止拓扑（topology）。最后，优化拓扑。经过Storm拓扑动态优化算法后，消息处理延迟减少，整体系统吞吐量也得到提升。该调度器主要集中在以下几个方面：为了提高系统性能，降低负载均衡、消息处理延迟、提高系统吞吐量等因素，提出了Storm拓扑动态优化算法；为了解决节点间负载均衡的另一个问题，提出了一种综合考虑拓扑结构、工作节点负载均衡和节点间通信量的实时调度算法，对Storm调度器进行了改进。在文献[5]中不考虑拓扑优化，程序的算法分为两个步骤：第一步，根据拓扑图和节点间流量，将executors分配给slots以确保最小的交互流量；第二步，考虑工作节点负载，为slots分配选择最后一个负载节点。此调度算法考虑采用执行器调度。大多数调度算法只关注改进executors到slots的分配，如基于拓扑的调度算法，基于流量的调度算法等，此调度程序在两个步骤（executors到slots，然后slots到工作节点）中改进了调度程序。从executors到slots的分配这一部分中，Storm拓扑的依赖关系首先根据拓扑结构进行划分，然后根据executors间通信流量进行预处理，将预处理的executors分配给slots，然后进行 slots到工作节点分配。论文[6]提出的调度算法的核心思想是考虑executors之间的通信设计，这些executors试图将高频率通信的executors放置在同一个slot中。作者在此基础上提出了两种不同的算法：其一考虑组件在拓扑中是如何相互关联的，以确定应该将哪些executors分配给同一个slot；另一种方法是在运行时监督执行程序之间交换元组的通信量。其设计包括：离线调度器：此调度程序分析拓扑DAG，并通过查看它们的连接方式来识别要在同一节点上安排的可能的bolts集合；在线调度器：通过持续监视系统性能和重新安排运行时的部署来增加离线调度器的方法，以提高总体性能。自适应在线调度（Adaptive Online Scheduler）算法依赖于贪心方法，即将executors放置到节点上，以限制节点间的通信量，避免节点之间的负载不平衡。它由连续的两个阶段组成。在第一阶段中，每个拓扑的executors被分配给一批已经安排好拓扑的工作节点上以维持运行。部署主要关注限制特定工作节点的executors之间的通信量以及调整每个工作节点的总CPU请求。在第二阶段，必须将第一阶段交付的工作节点分配到集群中的可用slots。这种分配仍然需要同时考虑节点间通信量之间的关系，从而限制节点流量和节点负载，以满足负载限制约束。Boyang Peng等将R-Storm实现为Storm的自定义版本[7]，修改核心Storm代码，以允许物理机器节点将其资源可用性发送到用户调度拓扑。R-Storm的核心调度功能在定制版Storm中作为自定义调度程序实现。用户可以通过创建实现预定义接口的类来创建自定义调度程序，调度程序作为Storm守护程序的一部分运行。收集Storm群集中的统计信息，例如任务、组件和拓扑级别的吞吐量。采用独有模块存储群集中物理机的所有资源可用性信息以及所有已调度或需要调度的Storm拓扑的所有任务的资源需求信息，生成数据用于评估。通过运行各种微基准Storm拓扑以及Yahoo!使用的生产拓扑来评估R-Storm，吞吐量和CPU利用率R-Storm的性能表现明显优于默认结构。T-Storm算法^[8]通过检测分析作业负载情况以及节点之间的流量来实现实时流式处理系统中任务的动态分配，具有以下的几个优点：（1）可以在维持工作节点负载状态的同时尽可能地降低网络传输的成本，实现资源本地化；（2）对于同一个工作节点上所分配的属于同一个topology的各项任务，仅分配一个工作进程，精简进程数量的同时可以消除进程间的通信成本；（3）在最大化处理性能的同时，系统会尽可能精简工作节点，减少维护运行的成本。存在的不足是这个算法中考虑资源负载的方向比较单一，仅考虑CPU负载状况，而不综合考量其他负载如内存、网络带宽等。Eskandari 等在论文[9]中提出了P-Storm，核心思想是将topology划分为多个子集，最小化子集之间的通信成本，该算法时间复杂度低，同时在Storm平台上易于实现。但是该算法的缺点在于考虑的维度并不够丰富，仅仅考虑拓扑子图在各节点的调度，而不关心资源开销和节点间的通信情况，在优化Storm调度上仍有许多探索的空间。针对这些算法改进的方向，文献[10]中例举了7种不同的调度器，包括Storm的默认循环调度器，进行了比较研究，并就Storm改进算法思路的维度方面提出了建设意见。

从上面的分析可以看到，国内外对于云计算环境下的作业调度问题研究从不同的方向深入，但还不够充分。因此，针对现有研究，进行进一步的探索与研究是很有必要的。本文将进一步探究云计算中流式作业的调度策略，与已有研究中调度策略不同，本文是从逆序拓扑遍历分析出发构建模型，是一种以静态分析机制处理差异化任务拓扑的方法，在调度中，着重关心拓扑结构下游的数据强耦合性节点之间的关系，从最大本地化、最小通信成本化的维度来增强框架的数据处理效率。

1.3研究目标与内容

本文的研究工作来源于导师课题：流式云服务作业调度。

本课题以云环境中流式作业调度为出发点，目标在于对Storm计算框架中的作业调度策略进行优化。由于流式任务执行过程中的相互依赖性，不同任务调度序列导致不同的完成时间策略是从拓扑分析出发，将逆序深度优先遍历拓扑抽象表达为一个逻辑进程系统，将该逻辑进程系统等效简化为一个有向无环图模型以表示拓扑结构，将这个模型作为调度依据，在分配过程中实现最大本地化，降低进程间通信开销，以提高Storm集群的处理效率。内容主要包括：通过构建基于批处理的大数据服务和流式计算系统Storm的实时数据处理的云平台，根据逆序遍历分析拓扑并构建模型，对流式作业Storm默认调度策略进行改进。实现负载均衡、灵活应对多种任务需求的流式云服务作业调度，考虑数据本地化以减少数据传输时间，从而最小化流作业的完工时间。

1.4 论文组织结构

全文共有四个章节。

第一章为绪论，主要讲述以下四个方面的内容：研究背景、对于作业调度策略的研究现状、主要研究内容和论文组织结构。其中，根据研究现状分析了现有作业调度研究中存在的不足。

第二章介绍了Storm的基本概念、体系结构以及相关技术。列举并总结了几种基本的算法和现有研究中的改进算法结构。

第三章介绍了本文提出的作业调度模型，包括拓扑分析处理方法和作业调度策略，具体介绍了基于拓扑结构分析的Storm的核心体系结构、云计算调度中的作业调度策略，然后介绍了基于拓扑结构分析的节点分配算法。

在第四章中，进行了实验分析和总结，其中包括实验环境的搭建、实验结果分析等内容。根据得出的测量数据讨论算法的效果并得出实验结果。

第五章为总结与未来工作的展望。

第二章 Storm系统及其调度机制

随着近年以来数据业务的激增、云计算需求的快速增长，缺少“实时的分布式数据处理系统”已成为日渐被人们重视的话题，Storm的出现很好地满足了整个大数据生态环境的渴求。Storm有许多用例：实时分析、在线机器学习、连续计算等等，在“网上购物”、“搜索引擎”等与生活息息相关的技术领域中有相当的泛用性。在流数据处理、分布式RPC（Remote Procedure Call）等应用场景中，Storm都能表现出良好的处理效率。本章节将介绍Storm相关概念、Storm基础架构、相关技术以及面临的问题，结合作业调度策略进行分析，为云服务流式作业调度的算法探究做铺垫。

2.1 Storm系统简介

随着近年以来数据业务的激增、云计算需求的快速增长，缺少“实时的分布式数据处理系统”已成为日渐被人们重视的话题，Storm的出现很好地契合了大数据生态环境的渴求。在Storm被开发出来之前，实时处理需要维护一堆消息队列和消息接收节点，复杂的图结构使得开发与维护非常困难。作为分布式的实时计算系统，Storm在应对流式作业时可以让开发和维护的过程都变得格外从容。正如Hadoop之于批量处理计算，Storm可以轻松地实现实时流式作业处理。Storm的可靠性和容错性，使其能在保持操作和设置的简易性的同时，保证即时有效的流式数据处理。此外，Storm可扩展性使得它可以和队列以及数据库技术集成在一起。

2.1.1 Storm系统定义

Storm是分布式的实时流式计算系统，它采用事件流的形式，通过多个组件构成一个处理网络框架，能保证数据在低延迟下被有效地处理，能够迎合数据实时处理的要求。Storm拓扑在运行的时候，将会以流的形式对数据进行处理，同时在计算处理的不同节点之间也是通过流来进行数据传输的。一个简单的Storm如下图2-1所示。

图2-1 Apache Storm示意图

Storm框架拥有以下的几个主要特点：1.操作和设置的简易性：开发人员只需要和应用业务逻辑交互，而不需要花费大量精力维护消息队列；2.高响应性，低延迟：Storm的可靠性在需要大量实时响应的场景中表现出色，十分契合线上检索、即时通讯等领域的数据处理需求；3.分布式：易于拓展计算系统，保证可靠性的同时，可以拓展平台的计算能力和服务面积，提供更为强大和稳定的服务；4.可扩展性：当今数据领域业务的迅速发展，决定了数据处理和计算量将不可避免地往复杂和大量的方向发展，系统可水平扩展注定是分布式平台的重要属性和优点；5.容错率非常高：整个分布式系统中，单个节点的宕机基本不会造成整个平台的运行波动，可以迅速重启节点或者重新进行任务分配；6.可靠性：采用ack函数跟踪消息处理的方式，能极大降低流中数据信息的丢失率，进而保证消息的处理。

2.1.2 Storm系统组成部分

Storm中有以下一些基本概念名词：

1. 元组(Tuple)：_Tuple 是 Storm 中的采用的数据表示模型。用以包装实际所需处理的数据，所有的数据都以Tuple的形式在各个组件之间流动^[11]。元组是Storm的数据传输（一般形式为流）中最基本的数据单位。作为数据模型，元组会是int，byte，string，float，boolean和数组等数据类型的包装。用户也可以通过实现自己的序列化方式，将新的类型包装在元组中。
2. 流(Streams)：_Stream是由大量元组组成的消息序列。元组以流为载体，在各个节点上被特定计算逻辑所处理。流在初始化的时候会被提交一个ID用以识别，而其定义来自于流中的元组所包含的字段。
3. Spout：_Spout是集群中产生流的节点。Spout可以从内存中生成流，但其生成的流中数据通常来自于外部数据（从数据库读取或从其他系统生成的消息队列中获取）。由spout产生的元组数据将会发布到集群中，被其他节点（一般为bolt）所订阅。对于一个被发布到Storm中的元组，可靠的(reliable)Spout会持续关注这个元组是否被处理，获得失败信息的时候将会重新发送信息以保证元组被征程处理，而非可靠的(unreliable)Spout在topology中仅关心发布数据的动作，而不考虑元组是否被正常处理。系统会持续调用spout中的nextTuple函数，通过这个函数对元组进行轮询，维持连续的流式传输状态。一旦有新的元组产生，就会把新元组吐到拓扑里。Spout可以同时在多个流中发布数据、被多个节点接收，以此来组成Storm中topology结构的源头或者“上游”。

图2-2 Spout示意图

1. Bolts:在Storm集群中,使用_bolt来作为数据处理节点，集群依赖bolt节点来实现所有的计算逻辑，进行流的接收、过滤、函数处理和转发。Bolt在系统中接收指定数量的输入流，同时可以发布指定数量的输出流到拓扑中去。在bolt中可以加载函数处理、数据转存等计算逻辑。作为整个分布式系统上的处理节点，用户需要关注的是合理配置bolt节点，包括：配置多个bolt上的数据处理函数，把流式数据的处理按步骤拆解并分配到多个相关的bolt上，注意blot之间的数据复用和协作关系以提高整个集群的数据处理能力，提升拓扑结构中流式任务处理的并发度等。初始化bolt的输入流，就是根据字段订阅另外一个特定组件的特定输出流。在整个系统中，通常bolt在处理接收到的元组时，将会根据这个元组的处理结果进一步吐出零个或者多个元组到系统中，然后在处理完成的时候，对这一元组的处理进行确认(ack)，以便元组的输出端可以确保这一元组被可靠处理。和Spout一样，bolt也可以同时在多个流中发布数据、被多个节点接收，以此来组成Storm中topology结构的数据处理节点或者“中下游”。

图2-3 Bolt示意图

1. 组件(Component)：component是Bolt和Spout的统称。
2. 拓扑(Topologies)：拓扑是一种无环有向图结构，它表征Storm系统中各个组件的逻辑关系。拓扑作为有向图，根据其各部分子集对应实时处理程序的关系，通过流分组(stream grouping)表征的有向边，把spout和bolt连接到一起。其中图的每条有向边的箭头代表一个bolt的输入流，这条边订阅接收spout或者其他bolt的输出流。

图2-4 topology示意图

1. 流分组(Stream Grouping)：Stream_Grouping就是拓扑中的有向边，它表征的是Storm集群中组件之间的相互工作关系。拓扑在初始化的时候，声明了每个bolt订阅上游节点的输出流的名称以及订阅的形式，这就需要通过不同的分组策略把_spout和_bolt连接到一起。在接受并处理一个流的_bolt内可能有多个任务(task)都需求这个输入流，流分组就是定义一个流在这些任务之间如何分组。流分组表征元组在集群中的被处理的方式，这类似与计算机网络中的路由广播概念。在Storm中，共有7种Stream_Grouping策略，如表2-1所示。

表2-1 Storm流分组策略

2.1.3 Storm模型架构

Storm集群与Hadoop的集群有许多的相似之处，很多概念可以一一对应起来。在Storm的集群内，主节点(master node)和从节点(worker node)通过主从关系形成调度管理秩序。主控节点上面维护的nimbus，它的作用就好比Hadoop集群中的JobTracker进程。在Storm上面运行拓扑时，nimbus将会在分布式系统中为各个从节点配置代码，分配拓扑中的工作给集群中从节点上的服务机器，同时监管各个工作节点的状态。工作节点上运行supervisor_程序，其在Hadoop中对应的是Task_Tracker。supervisor根据所收到来自主控节点的指令来调节工作状态，根据需要启动/关闭工作进程。根据系统中分布的任务，每个工作节点将运行对应的进程处理，执行任务拓扑（正如Hadoop中的 Job）的一个子集。在Storm平台上，分布在不同服务节点上的大量工作进程 Worker（在Hadoop中对应 Child）构成了一个正在处理的拓扑。Storm组件模型结构示意图如图2-6所示^[12]。

图2-6 Storm组件模型结构示意图

其中各个组成部分介绍如下：

Nimbus：_nimbus程序会为集群中的各个从节点配置代码，分配资源、进行任务调度。分配信息会发布到集群中，通过zookeeper进行公有数据的存放和集群各个节点的协调和配置信息的发布。

Supervisor：是监听配置信息并实现任务调度的节点，通过接收_nimbus 发布到_zookeeper上的任务，安排调度节点上worker进程。它是当前物理机器上的管理者，可以通过配置文件设置当前supervisor上启动多少个worker，根据接收到的任务信息进行对应调度处理。

Worker：是运行具体组件的载体，根据supervisor分配的任务，运行spout或bolt节点的逻辑进程。每个supervisor下可以管理运行多个worker进程，而每一个worker中的JVM（Java Virtual Machine）是进行具体处理的核心。Storm调度平衡的一个考量就是会尽可能地把所有的任务相对均匀地分配到所有的worker上。

Task：是实现具体spout或者bolt组件逻辑的线程。（当前新版本的Storm框架中，多个task将可以在同一物理线程中运行。新的spout/bolt线程模型称为executor。）

2.1.4 Storm部署框架

Storm集群把各个组件分配安排给每个服务节点上的worker，在分布式计算体系中运行用户提交的拓扑任务。Storm的部署如图2-7所示。

图2-7 Storm基础部署框架

有topology被提交时，nimbus在分布式系统中为各个从节点分配资源、进行任务分配，分配信息会发布到集群中，通过zookeeper进行公有数据的交互、集群状态的监控、各个节点的协调和配置信息的发布。Supervisor持续监听以获得配置信息，接收nimbus发布的任务分配信息等，根据这些信息进行相应的任务分配。根据topology结构，使用worker来追踪和处理信息。其中worker的基础结构如图2-8。

图2-8 worker结构示意图

Worker代表一个进程，而excutor代表线程，主要用于处理spouts和bolts的工作。

2.1.5 Storm作业拓扑提交流程

Storm作业提交，就是将拓扑提交到Storm分布式系统上运行，具体过程如下：（1）通过Storm提供的库和API进行编程，完成任务拓扑的创建；（2）在Storm系统上通过客户交互函数将拓扑代码包上传提交给主控节点。主控节点上nimbus将会根据代码中的任务拓扑将任务发布到系统中，通过调度将任务子集分配给集群中的supervisor；（3）Supervisor从系统中获得拓扑子集，会根据拓扑子集中对应的task，分配worker来完成计算任务；（4）worker执行计算逻辑以实现单个节点的数据处理。

2.2 Storm调度机制

通过Storm调度器，在向Storm集群提交作业拓扑之后，把各个组件分派到各个工作节点上去。Storm调度机制中，先把executor线程分配到worker上，然后把worker分配到有空闲资源的工作节点上^[12]。默认调度策略无法达到精细化的调度管理以均衡不同流式作业中多个工作节点之间的负载，同时，默认调度方案缺乏对数据本地化的考虑。也就是说，正如其他的大数据处理系统，Storm也并没有配置智能调度机制。Storm默认的任务调度机制没有很好地考虑资源可用性和需求，容易导致出现资源使用的盲目性。因此，设计出一种可以应对不同作业调度序列的智能算法成为了近年来热门的研究领域。

2.2.1 Storm内置的调度算法

根据Storm官网介绍，Storm内置了4种调度器，分别是: DefaultScheduler, IsolationScheduler, MultitenantScheduler, ResourceAwareScheduler^[11]。其中DefaultScheduler是Storm中默认的调度策略，拓扑内的组件将依次地被分配至当前拥有的资源上。默认调度策略是一种“EvenSvcheduler”（平等调度），它以轮询（round-robin）的方式在多个工作节点间均匀地分配任务,它分配executor给worker的时候，首先会遍历所有任务节点的线程，进行依次分配,然后再遍历所有worker，将它们依次分配到工作节点上^[7]。这种调度算法一定程度上实现了工作节点之间的负载平衡，但在实际应用中仍然存在一些问题，如：默认调度策略无法达到精细化的调度管理以均衡不同流式作业中多个工作节点之间的负载，同时，默认调度方案缺乏对数据本地化的考虑。因此。目前有学者提出了一些调度策略来解决存在的问题，具体分析如下

2.2.2 JStorm调度算法

JStorm^[13]是阿里巴巴公司基于Storm默认调度算法提出并开发的一种调度算法，有以下一些特点：

（1）表现稳定。JStorm会尽量均匀地将每个组件的线程分配到每个节点上去。Jstorm会更多地考虑将同一个组件中的不同线程分配到不同的节点或不同worker上以降低它们对同类型资源的竞争(同一个组件线程的工作类型相似，如它们均为CPU密集型工作，则将这两个线程分配到不同的工作节点上就能有效提高资源的利用率，进而促进整个系统的效率提升)。如下的示例中，由三个节点所组成的集群，A节点拥有3个worker，B节点有2个worker，C节点拥有1个。在用户向系统提交一个拓扑任务(需求4个worker：2X 2Y)的情况下，如图2-9所示。

图2-9 一个Storm节点分配状况示例

如果C节点宕机，则其中的worker需要重新分配。Storm默认的分配将不会考虑到稳定性和均衡性，新的分配结果如图2-10所示。

图2-10 Storm默认调度后的节点分配状况示例

JStorm调度则将会考虑到进行尝试更为合适的资源分配，分配结果如图2-11所示。

剩余内容已隐藏，请支付后下载全文，论文总字数：28592字