分布式计算系统storm任务调度算法

分布式计算系统storm中worker、executor、task比较 http://www.111cn.net/sys/linux/96715.htm

3种Scheduler概述

    EventScheduler:将系统中的可用资源均匀地分配给需要资源的topology,其实也不是绝对均匀,后续会详细说明
    DefaultScheduler:和EvenetScheduler差不多,只不过会先将其它topology不需要的资源重新收集起来,再进行EventScheduler
    IsolationScheduler:用户可定义这个topology的机器资源,storm分配的时候会优先分配这些topology,以保证分配给该topology的机器只为这一个topology服务

DefaultScheduler

    调用cluster的needsSchedualerTopologies方法获得需要进行任务分配的topologies
    开始分别对每一个topology进行处理
        调用cluster的getAvailableSlots方法获得当前集群可用的资源,以<node,port>集合的形式返回,赋值给available-slots
        获得当前topology的executor信息并转化为<start-t ask-id,end-task-id>集合存入all-executors,根据topology计算executors信息,采用compute-executors算法,稍后会讲解
        然后调用EventScheduler的get-alive-assigned-node+port->executors方法获得该topology已经获得的资源,返回<node+port,executor>集合的形式存入alive-assigned,为什么要计算当前topology的已分配资源情况而不是计算集群中所有已分配资源?,猜测可能是进行任务rebalance的时候会有用吧。
        接着就调用slot-can-reassign对alive-assigned中的slots信息进行判断,选出其中能被重新分配的slot存入变量can-reassigned
        这样可用的资源就由available-slots和can-reassigned两部分组成
        接下来计算当前topology能使用的全部slot数目total-slots--to-use:min(topology的NumWorker数,available-slots+can-reassigned)
        如果total-slots--to-use>当前已分配的slots数目,则调用bad-slots方法计算可被释放的slot
        调用cluster的freeSlots方法释放计算出来的bad-slot
        最后调用EventScheduler的schedule-topologies-evenly进行分配
        继续下一个topology

主要流程梳理:获得当前集群空闲资源->计算当前topology的executor信息(分配时会用得上)->计算可重新分配和可释放的资源->分配

EventScheduler

EventScheduler调度算法与Default相比少了一个计算可重新分配资源的环节,直接利用Supervisor中空闲的slot进行分配,在此不再细讲。

EventScheduler和DefaultScheduler调度举例:

这两种调度机制在一般情况下调度结果基本保持一致,所以一起来看:

集群初始状态

接下来我们提交3个topology

Topology

Worker

Executer

Task

T-1

3

8

16

T-2

5

10

10

T-3

3

5

10

1、提交T-1

    sort-slots算法对可用slots进行处理,结果为{[s1 6700] [s2 6700] [s3 6700] [s4 6700] [s1 6701] [s2 6701] [s3 6701] [s4 6701] [s1 6702] [s2 6702] [s3 6702] [s4 6702] [s1 6703] [s2 6703] [s3 6703] [s4 6703]}
    compute-executors算法计算后得到的Executor列表为:{[1 2] [3 4] [5 6] [7 8] [9 10] [11 12] [13 14] [15 16]};注:格式为[start-task-id end-task-id],共8个worker,第一个包含2个task,start-task-id为1,end-task-id为2,所以记为[1 2],后面依次类推...compute-executors算法会在下一篇博客中详解
    8个Executor在3个worker上的分布状态为[3,3,2]
    分配结果为:
        {[1 2] [3 4] [5 6]} -> [s1 6700]
        {[7 8] [9 10] [11 12]} -> [s2 6700]
        {[13 14] [15 16]} -> [s3 6700]

分配后集群状态为:

2、提交T-2

    可用的slot经过sort-slots后:{[s1 6701] [s2 6701] [s3 6701] [s4 6700] [s1 6702] [s2 6702] [s3 6702] [s4 6701] [s1 6703] [s2 6703] [s3 6703] [s4 6702] [s4 6703]}
    comput-executors计算后得到的executor列表:{[1 1] [2 2] [3 3] [4 4] [5 5] [6 6] [7 7] [8 8] [9 9] [10 10]}
    10个executor在5个worker上的分布为[2,2,2,2,2]
    分配结果为:
        {[1 1] [2 2]} -> [s1 6701]
        {[3 3] [4 4]} -> [s2 6701]
        {[5 5] [6 6]} -> [s3 6701]
        {[7 7] [8 8]} -> [s4 6700]
        {[9 9] [10 10]} -> [s1 6702]

分配后集群状态为:

3、提交T-3

    sort-slots后slot列表为:{[s1 6703] [s2 6702] [s3 6702] [s4 6701] [s2 6703] [s3 6703] [s4 6702] [s2 6704] [s3 6704] [s4 6703] [s4 6704]}
    compute-executors后得到的executor列表为:{[1 2] [3 4] [5 6] [7 8] [9 10]}
    5个executor在3个worker上的分布为:[2,2,1]
    分配结果为:
        {[1 2] [3 4]} -> [s1 6703]
        {[5 6] [7 8]} -> [s2 6702]
        [9 10] -> [s3 6702]

分配后集群状态为:

如图,此任务调度方式也不是绝对均匀的,s1已经满负荷运转,而s4才刚使用一个slots。

时间: 2024-09-25 01:19:32

分布式计算系统storm任务调度算法的相关文章

分布式计算系统storm中worker、executor、task比较

storm基础框架分析 本文我们要证明的主要问题是:在Topology中我们可以指定spout.bolt的并行度,在提交Topology时Storm如何将spout.bolt自动发布到每个服务器并且控制服务的CPU.磁盘等资源的? worker.executor.task的关系 nimbus将可以工作的worker称为worker-slot. nimbus是整个集群的控管核心,总体负责了topology的提交.运行状态监控.负载均衡及任务重新分配,等等工作. nimbus分配的任务包含了topo

专访QQ大数据团队,谈分布式计算系统开发

NoSQL是笔者最早接触大数据领域的相关知识,因此在大家都在畅谈Hadoop.Spark时,笔者仍然保留着NoSQL博文的阅读习惯.在偶尔阅读一篇Redis博文过程中,笔者发现了 jacksu的个人博客,并在其中发现了大量的分布式系统操作经验,从而通过他的引荐了解了QQ成立之初后台3个基础团队之一的QQ运营组,这里我们一起走进. QQ大数据团队 CSDN:首先,请介绍一下您的团队? 聂晶:我们团队是社交网络事业群/社交网络运营部/数据中心/平台开发二组,前身是QQ成立之初后台3个基础团队之一的Q

Onyx 0.9.11 发布,分布式计算系统

Onyx 0.9.11 发布了,Onyx 是一个无中心.支持云.容错的分布式计算系统,使用 Clojure 编写,支持批处理和流处理混合,提供信息模型用于描述和构建分布式工作流. 更新说明: Generate plugin READMEs from their info models Upgrade rocksdb to support Windows OS 文章转载自 开源中国社区 [http://www.oschina.net]

Storm、Spark和MapReduce 开源分布式计算系统框架比较

比较项 Storm Spark Streaming 分布式计算在许多领域都有广泛需求,目前流行的分布式计算框架主要有 Hadoop MapReduce, Spark Streaming, Storm: 这三个框架各有优势,现在都属于 Apache 基金会下的顶级项目,下文将对三个框架的特点与适用场景进行分析,以便开发者能快速选择适合自己的框架进行开发. Hadoop MapReduce 是三者中出现最早,知名度最大的分布式计算框架,最早由 Google Lab 开发,使用者遍布全球(Hadoop

分布式基础学习【二】 —— 分布式计算系统(Map/Reduce)

二. 分布式计算(Map/Reduce) 分布式式计算,同样是一个宽泛的概念,在这里,它狭义的指代,按Google Map/Reduce 框架所设计的分布式框架.在Hadoop中,分布式文件系统,很大程度上,是为各种分布式计 算需求所服务的.我们说分布式文件系统就是加了分布式的文件系统,类似的定义推广到分 布式计算上,我们可以将其视为增加了分布式支持的计算函数.从计算的角度上看, Map/Reduce框架接受各种格式的键值对文件作为输入,读取计算后,最终生成自定义格式的 输出文件.而从分布式的角

大数据流式计算三种框架:Storm,Spark和Samza

许多分布式计算系统都可以实时或接近实时地处理大数据流.本文将对三种Apache框架分别进行简单介绍,然后尝试快速.高度概述其异同. Apache Storm 在Storm中,先要设计一个用于实时计算的图状结构,我们称之为拓扑(topology).这个拓扑将会被提交给集群,由集群中的主控节点(master node)分发代码,将任务分配给工作节点(worker node)执行.一个拓扑中包括spout和bolt两种角色,其中spout发送消息,负责将数据流以tuple元组的形式发送出去:而bolt

大数据架构师:hadoop、Storm该选哪一个

首先整体认识:Hadoop是磁盘级计算,进行计算时,数据在磁盘上,需要读写磁盘;http://www.aliyun.com/zixun/aggregation/13431.html">Storm是内存级计算,数据直接通过网络导入内存.读写内存比读写磁盘速度快n个数量级.根据Harvard CS61课件,磁盘访问延迟约为内存访问延迟的75000倍.所以Storm更快. 注释: 1. 延时 , 指数据从产生到运算产生结果的时间,"快"应该主要指这个. 2. 吞吐, 指系统单

从Storm和Spark 学习流式实时分布式计算的设计

0. 背景 最近我在做流式实时分布式计算系统的架构设计,而正好又要参加CSDN博文大赛的决赛.本来想就写Spark源码分析的文章吧.但是又想毕竟是决赛,要拿出一些自己的干货出来,仅仅是源码分析貌似分量不够.因此,我将最近一直在做的系统架构的思路整理出来,形成此文.为什么要参考Storm和Spark,因为没有参照效果可能不会太好,尤其是对于Storm和Spark由了解的同学来说,可能通过对比,更能体会到每个具体实现背后的意义. 本文对流式系统出现的背景,特点,数据HA,服务HA,节点间和计算逻辑间

Esper Storm S4

http://esper.codehaus.org/tutorials/tutorial/tutorial.html http://esper.codehaus.org/esper-4.6.0/doc/reference/en-US/html/index.html http://www.slideshare.net/hemapani/siddhi-a-second-look-at-complex-event-processing-implementations Esper Reference V