课程已帮忙300+人成功转型Hadoop开发

本文是Storm连串之一,重要介绍Storm的架构设计,推荐读者在阅读Storm介绍(一)的根基之上,阅读这一篇。本文只是作者的读书笔记,偏重于浅层次的架构介绍,假使想真正领悟里面设计时候的权衡,还需要更多的去阅读Storm源码。

5. Storm容错机制

Storm的容错机制包括架构容错和数目容错。

1) 架构容错:

Nimbus和Supervisor进程被规划成高速失败(fail
fast)的(当遇到特其它状况,进程就会挂掉)并且是无状态的(状态都保留在Zookeeper或者在磁盘上)。

最关键的是,worker进程不会因为Nimbus或者Supervisor挂掉而受影响。这跟Hadoop是不相同的,当JobTracker挂掉,所有的任务都会没了。

当Nimbus挂掉会怎么?

假定Nimbus是以引进的主意处于进程监管(例如通过supervisord)之下,这它会被重启,不会有任何影响。

否则当Nimbus挂掉后:

l 已经存在的拓扑可以继承健康运作,不过不可能交付新拓扑

l 正在运转的worker进程依然可以连续做事。而且当worker挂掉,supervisor会一向重启worker。

l 退步的任务不会被分配到其他机器(是Nimbus的职责)上了

当一个Supervisor(slave节点)挂掉会如何?

如若Supervisor是以引进的艺术处于进程监管(例如通过(supervisord)[supervisord.org/])之下,这它会被重启,不会有其他影响

要不当Supervisor挂掉:分配到这台机械的持有任务(task)会晚点,Nimbus会把那几个职责(task)重新分配给其余机器。

当一个worker挂掉会怎么样?

当一个worker挂掉,supervisor会重启它。假诺开行一向失败那么此时worker也就不可能和Nimbus保持心跳了,Nimbus会重新分配worker到任何机器。

Nimbus算是一个单点故障吗?

假若Nimbus节点挂掉,worker进程依然可以继承做事。而且当worker挂掉,supervisor会一向重启worker。但是,没有了Nimbus,当需要的时候(假如worker机器挂掉了)worker就不可以被重新分配到任何机器了。

由此答案是,Nimbus在“某种程度”上属于单点故障的。在骨子里中,这种情状没什么大不断的,因为当Nimbus进程挂掉,不会有悲惨的工作爆发

2) 数据容错:

Storm中的每一个Topology中都涵盖有一个Acker组件。
Acker组件的职责就是跟踪从某个task中的Spout流出的每一个messageId所绑定的Tuple树中的所有Tuple的拍卖情状。假使在用户设置的最大超时时间(timetout
可以通过
Config.TOPOLOGY_MESSAGE_TIMEOUT_SECS来指定)内这多少个Tuple没有被统统处理,那么Acker会告诉Spout该信息处理失败,相反则会告知Spout该信息处理成功,它会独家调用Spout中的fail和ack方法。

作者:Jack47

4. Storm系统架构

图片 1 

1) 主节点(Nimbus):

在分布式系统中,调度服务特别重要,它的规划,会一向关系到系统的运作成效,错误恢复生机(fail
over),故障检测(error detection)和档次扩大(scale)的能力。

集群上职责(task)的调度由一个Master节点来负责。这台机械上运行的Nimbus进程负责任务的调度。其它一个经过是Storm
UI,能够界面上查看集群和富有的拓扑的周转情况。

2) 从节点(Supervisor)

Storm集群上有三个从节点,他们从Nimbus上下载拓扑的代码,然后去真正履行。Slave上的Supervisor进程是用来监督和管制实际运作工作代码的长河。在Storm
0.9过后,又多了一个过程Logviewer,可以用Storm
UI来查看Slave节点上的log文件。

3) 协调服务Zookeeper:

ZooKeeper在Storm上不是用来做音信传输用的,而是用来提供协调服务(coordination
service),同时储存拓扑的场所和总结数据。

l Supervisor,Nimbus和worker都在ZooKeeper留下约定好的信息。例如Supervisor启动时,会在ZooKeeper上登记,Nimbus就可以发现Supervisor;Supervisor在ZooKeeper上预留心跳音讯,Nimbus通过那些心跳信息来对Supervisor举办健康检测,检测出坏节点

l 由于Storm组件(component)的状态音信存储在ZooKeeper上,所以Storm组件就可以无状态,可以kill -9来杀死

比如:Supervisors/Nimbus的重启不影响正在运作中的拓扑,因为状态都在ZooKeeper上,从ZooKeeper上重新加载一下就好了

l 用来做心跳

Worker通过ZooKeeper把孩子executor的情况以心跳的格局汇报给Nimbus

Supervisor进程经过ZK把团结的情况也以心跳的款型汇报给Nimbua

l 存储最近任务的失实意况(拓扑停止时会删除)

4) 进程Worker

运转具体处理组件逻辑的过程,一个Topology可能会在一个要么三个worker里面执行,每个worker是一个物理JVM并且实施总体Topology的一局部

比如说:对于并行度是300的topology来说,即使我们采用50个干活过程来施行,那么每个工作过程会处理内部的6个tasks,Storm会尽量均匀的行事分配给持有的worker

5) Task

Worker中的每一个spout/bolt的线程称为一个task,每一个spout和bolt会被看做很多task在方方面面集群里推行,每一个executor对应到一个线程,在那些线程上运行六个task,Stream Grouping则是概念怎么从一堆task发出tuple到另外一堆task,能够调用TopologyBuilder类的setSpout和setBolt来安装并行度(也就是有多少个task)

 

ZooKeeper

  1. 推荐精心设计过的机器,因为ZooKeeper是Storm的瓶颈
    • 各类机器使用一个ZK的实例
    • 在意因为同一台机械上的任何进程或者虚拟机他们是共享那台机器的,所以可能会潜移默化ZK的属性(来源)
  2. I/O是ZooKeeper的瓶颈
  • 把ZooKeeper的存储放到自己的磁盘上
  • 应用SSD会显然升级性能
  • 正规意况下,Zookeeper的历次写操作都会联合到磁盘,这就招致了五遍磁盘寻址操作(两回是多少,两次是数据的日志)。当有着的worker都发心跳给ZooKeeper时,可能会分明影响属性(来源)。
    • 急需监控ZooKeeper节点的I/O负载
  1. 引进在生产条件上运行的ZooKooper集群有起码3个节点,这样就是有一个ZooKeeper服务器挂掉了(例如举行保障),也是可以的。

课程已扶助300+人成功转型Hadoop开发,90%起薪超越20K,工资比此前翻了一倍。

Storm的容错(Fault Tolerance)机制

正如“搭建一个Storm集群”一文介绍的平等,必须用工具如daemontools或者monit来监督Nimbus和Supervisor的后台进程。这样只要Nimbus或者Supervisor进程挂掉,会被daemontools检测到,并举办重启。

NimbusSupervisor进程被设计成高速失利(fail
fast)的(当遭受特其它景色,进程就会挂掉)并且是无状态的(状态都封存在Zookeeper或者在磁盘上)。

最着重的是,worker进程不会因为Nimbus或者Supervisor挂掉而受影响。那跟Hadoop是不平等的,当JobTracker挂掉,所有的天职都会没了。

  1. 当Nimbus挂掉会怎么样?

    假若Nimbus是以引进的措施处于进程监管(例如通过supervisord)之下,这它会被重启,不会有此外影响

    否则当Nimbus挂掉后:

    • 业已存在的拓扑可以延续健康运作,然而无法交付新拓扑
    • 正在运作的worker进程仍旧可以连续做事。而且当worker挂掉,supervisor会从来重启worker。
    • 战败的任务不会被分配到另外机器(是Nimbus的天职)上了
  2. 当一个Supervisor(slave节点)挂掉会如何?

    假若Supervisor是以引进的艺术处于进程监管(例如通过(supervisord)[supervisord.org/])之下,这它会被重启,不会有此外影响

    不然当Supervisor挂掉:
    分配到这台机械的有着任务(task)会晚点,Nimbus会把这个任务(task)重新分配给任何机器。

  3. 当一个worker挂掉会怎么?

    当一个worker挂掉,supervisor会重启它。假如开行一向失利那么此时worker也就不可能和Nimbus保持心跳了,Nimbus会重新分配worker到另外机器

  4. Nimbus算是一个单点故障吗?
    一旦Nimbus节点挂掉,worker进程仍可以延续工作。而且当worker挂掉,supervisor会从来重启worker。可是,没有了Nimbus,当需要的时候(假如worker机器挂掉了)worker就无法被重新分配到其他机器了。
    故此答案是,Nimbus在“某种程度”上属于单点故障的。在实际上中,这种场地没什么大不断的,因为当Nimbus进程挂掉,不会有悲惨的政工时有爆发

有些视频截图展现

开行拓扑

为了在集群上启动一个拓扑,需要首先把代码打包成一个“胖jar包”–必须包含所有的倚重代码,除了Storm它本身,因为Storm集群会提供。然后在一台设置了storm命令行的机械上经过storm jar一声令下来交给拓扑:

storm jar my-topology-version-with-dependency.jar com.corp.MyTopology arg1 arg2

以此命令会连到Nimbus,上传jar包。接下来Nimbus会把拓扑的代码运送到多台不同的机械或者JVM上。惟有当拓扑在机械上配备成功了并且在JVM中先导化了将来,才能确实先河拍卖音讯。

流式总计解决方案-Storm

在Hadoop生态圈中,针对大数量举行批量乘除时,平时需要一个要么六个MapReduce作业来形成,但这种批量总括方法是知足不断对实时性要求高的场景。

Storm是一个开源分布式实时统计类别,它可以实时可靠地处理流数据。

本章内容:

1) Storm特点

2) Storm基本概念

3) Storm分组格局

4) Storm系统架构

5) Storm容错机制

6) 一个简练的Storm实现

Storm安全性

原始设计Storm时,完全没有把安全性考虑在内
今昔安全性能相关的功能在一步步加进去
Storm 0.9.x版本上的白山问题:

  1. 并未表达机制(authentication),没有授权机制(authorization)
  2. 传输的数码(例如worker之间)没有加密
  3. ZooKeeper上囤积的多少尚未访问限制
  4. 假诺Nimbus的Thrift端口没有锁住,任意的用户代码都足以在节点上执行

更多Storm安全性方面的提出见这里

题外话:
在触及Storm之后,有个问题在自家的脑海里升起,国内的大商厦,比如Baidu,Ali,腾讯,都是有出生Storm这类实时统计框架的土壤的,不过为啥没有做出来啊?

Apache Storm Basic
Training

Fault
tolerance

Storm in pictures

Storm 0.9 Basic
Training


一经您看了本篇博客,觉得对你抱有收获,请点击右下角的“推荐”,让更多少人看出!

帮衬杰克47写作,打赏一个鸡蛋灌饼钱吧

图片 2

微信打赏

图片 3

支付宝打赏

图片 4

Master结点(Master node)

在分布式系统中,调度服务特别重大,它的计划,会一贯关乎到系统的运转功能,错误复苏(fail
over),故障检测(error detection)和品位扩充(scale)的力量。

集群上职责(task)的调度由一个Master节点来负责。这台机械上运行的Nimbus进程负责任务的调度。此外一个过程是Storm
UI,可以界面上查看集群和具有的拓扑的运行处境。

6. 一个简单易行的Storm实现

兑现一个拓扑包括一个spout和五个bolt。Spout发送单词。每个bolt在输入数据的尾巴扩展字符串“!!!”。六个节点排成一条线:spout发射给第一个bolt,然后,这么些bolt再发射给第二个bolt。假设spout发射元组“bob”和“john”,然后,第二个bolt将发出元组“bob!!!!!!”和“john!!!!!!”。

1) 其中Topology代码如下,定义整个网络拓扑图:

TopologyBuilder builder = new TopologyBuilder();

builder.setSpout("words", new TestWordSpout(), 10);

builder.setBolt("exclaim1", new ExclamationBolt(), 3)              .shuffleGrouping("words");

builder.setBolt("exclaim2", new ExclamationBolt(), 2)

             .shuffleGrouping("exclaim1");

2) Spout实现:

public void nextTuple() {

        Utils.sleep(100);

        final String[] words = new String[] {"nathan", "mike", "jackson",                                                                           "golda", "bertels"};

        final Random rand = new Random();

        final String word = words[rand.nextInt(words.length)];

        _collector.emit(new Values(word));

}

3) Bolt实现:

public static class ExclamationBolt implements IRichBolt {

        OutputCollector _collector;

        public void prepare(Map conf, TopologyContext context, OutputCollector collector) {

                _collector = collector;

        }

        public void execute(Tuple tuple) {

                _collector.emit(tuple, new Values(tuple.getString(0) + "!!!"));

                _collector.ack(tuple);

        }

        public void cleanup() {

        }

        public void declareOutputFields(OutputFieldsDeclarer declarer) {

                declarer.declare(new Fields("word"));

        }

}

了解Storm的架构,有助于帮忙我们清楚大型分布式系统设计中需要缓解的题材,以及解决问题的思绪,帮忙我们更好的开展Storm性能调优化。

1. Storm特点

在Storm出现从前,举办实时处理是极度痛苦的作业,我们第一的年美利坚合众国的首都花在关怀往哪儿发新闻,从哪儿接收音信,音讯如何体系化,真正的事务逻辑只占了源代码的一小部分。一个应用程序的逻辑运行在许多worker上,但这一个worker需要各自独立安排,还索要配备音信队列。最大问题是系统很薄弱,而且不是容错的:需要协调保证信息队列和worker进程工作例行。

Storm完整地化解了这几个题目。它是为分布式场景而生的,抽象了音信传递,会自动地在集群机器上并发地处理流式总结,让您放在心上于实时处理的作业逻辑。

Storm有如下特点:

1) 编程简单:开发人士只需要关爱应用逻辑,而且跟Hadoop类似,Storm提供的编程原语也很简单

2) 高性能,低顺延:可以行使于广告搜索引擎这种要求对广告主的操作举行实时响应的气象。

3) 分布式:可以轻松应对数据量大,单机搞不定的情景

4) 可扩充:随着业务发展,数据量和总括量越来越大,系统可水平扩大

5) 容错:单个节点挂了不影响使用

6) 音讯不丢掉:保证消息处理

只是Storm不是一个一体化的缓解方案。使用Storm时您需要关怀以下几点:

1) 假诺利用的是友善的音讯队列,需要投入新闻队列做多少的源于和出现的代码

2) 需要考虑什么做故障处理:如何记录音讯处理的快慢,应对Storm重启,挂掉的光景

3) 需要考虑什么做信息的回退:如果某些音信处理直接战败肿么办?

架构

先上一张Storm的架构图,倘诺熟悉GFS和Hadoop的架构,会意识这一个系列的架构图都很相近。
图片 5

Storm架构图

分享一套二零一九年最新Hadoop大数目教程和100道Hadoop大数额必相会试题。

各节点的机能

只要您熟稔Hadoop的话,可以这么做一下类比:

Hadoop Storm
JobTracker Nimbus(只有一个)
TaskTracker Supervisor(有很多个)
MapReduce任务 Topology

可以看看Nimbus是调度器,WorkerTask的容器,Task是天职的着实实施者。

2. Storm与Hadoop区别

1) 定义及架构

Hadoop是Apache的一个序列,是一个可知对大气数据开展分布式处理的软件框架。

Storm是Apache基金会的孵化项目,是使用于流式数据实时处理领域的分布式总计系统。

 

Hadoop

Storm

系统角色

JobTracker

Nimbus

 

TaskTracker

Supervisor

 

Child

Worker

应用名称

Job

Topology

组件接口

Mapper/Reducer

Spout/Bolt

2) 应用方面

Hadoop是分布式批处理总括,强调批处理,常用于数据挖掘和剖析。

Storm是分布式实时总结,强调实时性,常用于实时性要求较高的地点。

3) 总括处理形式

Hadoop是磁盘级总结,举办测算时,数据在磁盘上,需要读写磁盘;Hadoop应用MapReduce的思想,将数据切片总计来处理大量的离线数据。Hadoop处理的数码必须是已经存放在HDFS上仍然类似HBase的数据库中,所以Hadoop实现的时候是透过活动计量到那多少个存放数据的机器上来提高效能的。

Storm是内存级统计,数据直接通过网络导入内存。Storm是一个流总计框架,处理的数额是实时音信队列中的,需要写好一个Topology逻辑,然后将吸收进来的多寡举办拍卖,所以Storm是由此活动数据平均分配到机械资源来收获高效用的。

4) 数据处理方面

多少出自:Hadoop是HDFS上某个文件夹下的多寡,数据量可能以TB来计;而Storm则是实时新增的某一笔数量。

处理过程:Hadoop是Map阶段到Reduce阶段的;Storm是由用户定义处理流程,流程中得以蕴涵两个步骤,每个步骤可以是数据源(SPOUT),也得以是处理逻辑(BOLT)。

是不是截至:Hadoop最终必须要终结;而Storm没有终结状态,到最后一步时,就停在那,直到有新数据进入时再重复起始。

处理速度:Hadoop以处理HDFS上大方数据为目标,速度慢;Storm只要处理新增的某一笔数量即可,故此它的快慢很快。

适用场景:Hadoop首假使处理一批数量,对时效性要求不高,需要处理就提交一个JOB;而Storm重假若处理某一猛增多少的,故此时效性要求高。

统计,Hadoop和Storm并不曾真正优劣之分,它们只是在各自的园地上有着新鲜的属性而已,倘诺真的把它们举办单独的可比,反而是有失公平了。事实上,只有在最合适的下面接纳最合适的大数目平台,才可以真的体现出它们的价值,也才可以真正为大家的做事提供极致便捷的助力!

转载请保留作者和原文出处

 

ZooKeeper的作用

ZooKeeper在Storm上不是用来做音讯传输用的,而是用来提供协调服务(coordination
service),同时储存拓扑的情景和总计数据。

  • ZooKeeper相当于一块黑板,SupervisorNimbus和worker都在地点留下约定好的音信。例如Supervisor启动时,会在ZooKeeper上注册,Nimbus就足以窥见SupervisorSupervisor在ZooKeeper上留下心跳音信,Nimbus经过那些心跳音讯来对Supervisor拓展例行检测,检测出坏节点
  • 鉴于Storm组件(component)的状态消息囤积在ZooKeeper上,所以Storm组件就足以无状态,可以kill -9来杀死
    • 例如:Supervisors/Nimbus的重启不影响正在周转中的拓扑,因为状态都在ZooKeeper上,从ZooKeeper上重复加载一下就好了
  • 用来做心跳
    • Worker通过ZooKeeper把孩子executor的意况以心跳的格局报告给Nimbus
    • Supervisor进程经过ZK把温馨的事态也以心跳的款型反映给Nimbua
  • 储存近期任务的一无是处情状(拓扑停止时会删除)

图片 6

硬件要求

因为链接通常被调和,需要的情人请 加微信
ganshiyun666 来获取最新下载链接,讲明“OSC”

从节点(Slave node)

Storm集群上有五个从节点,他们从Nimbus上下载拓扑的代码,然后去真正进行。Slave上的Supervisor经过是用来监督和治本实际上运作工作代码的历程。在Storm
0.9未来,又多了一个进程Logviewer,可以用Storm
UI来查看Slave节点上的log文件。
在布局文件storm.yaml中,决定了一台机械上运行多少个worker:

supervisor.slots.ports:
- 6700
- 6701
- 6702

内容包括0基础入门、Hadoop生态系统、真实商业类型实战3大部分。其中经贸案例能够让你接触实际的生育环境,练习自己的开发力量。

迎接关注自身的微信公众账号程序员杰克(Jack),两边的篇章会联手,也足以添加我的RSS订阅源

3. Storm基本概念

1) Topology

一个Storm拓扑打包了一个实时处理程序的逻辑。一个Storm拓扑跟一个MapReduce的职责(job)是看似的。紧要区别是MapReduce任务最后会截止,而拓扑会从来运行(当然直到你杀死它)。一个拓扑是一个透过流分组(Stream
Grouping)把Spout和Bolt连接到一起的拓扑结构。图的每条边表示一个Bolt订阅了其它Spout或者Bolt的输出流。一个拓扑就是一个错综复杂的多阶段的流总括。

图片 7 

2) Tuple

元组是Storm提供的一个轻量级的数据格式,可以用来包装你需要实际处理的数量。元组是五遍音讯传递的中坚单元。一个元组是一个命名的值列表,其中的各个值都足以是擅自档次的。元组是动态地开展项目转化的—字段的花色不需要事先表明。在Storm中编程时,就是在操作和转移由元组组成的流。平常,元组包含整数,字节,字符串,浮点数,布尔值和字节数组等项目。要想在元组中行使自定义类型,就需要实现团结的连串化格局。

图片 8 

3) Stream

流是Storm中的主题抽象。一个流由无限的元组体系组成,这个元组会被分布式并行地创制和拍卖。通过流中元组包含的字段名称来定义这个流。

各类流声明时都被给予了一个ID。只有一个流的Spout和Bolt非凡广阔,所以Output菲尔德(Field)(Field)sDeclarer提供了不需要指定ID来声称一个流的函数(Spout和Bolt都亟待阐明输出的流)。这种情景下,流的ID是默认的“default”。

4) Spout

Spout(喷嘴,那么些名字很形象)是Storm中流的起源。通常Spout从外表数据源,如音信队列中读取元组数据并吐到拓扑里。Spout可以是可靠的(reliable)或者不可靠(unreliable)的。可靠的Spout可以在一个元组被Storm处理失利时再也展开拍卖,而非可靠的Spout只是吐数据到拓扑里,不关心处理成功或者失利了。

图片 9 

Spout可以一回给五个流吐数据。此时内需通过OutputFieldsDeclarer的declareStream函数来声称四个流并在调用SpoutOutputCollector提供的emit方法时指定元组吐给哪些流。

Spout中最要紧的函数是nextTuple,Storm框架会频频调用它去做元组的轮询。假诺没有新的元组过来,就直接回到,否则把新元组吐到拓扑里。nextTuple必须是非阻塞的,因为Storm在同一个线程里实施Spout的函数。

Spout中此外六个举足轻重的函数是Ack和fail。当Storm检测到一个从Spout吐出的元组在拓扑中中标拍卖完时调用Ack,没有中标拍卖完时调用Fail。只有可靠型的Spout会调用Ack和Fail函数。

5) Bolt

在拓扑中具有的计量逻辑都是在Bolt中实现的。一个Bolt可以拍卖任意数量的输入流,发生任意数量新的输出流。Bolt可以做函数处理,过滤,流的集合,聚合,存储到数据库等操作。Bolt就是流程上的一个处理单元,把多少的盘算处理过程合理的拆分到三个Bolt、合理设置Bolt的task数量,可以增进Bolt的拍卖能力,提高流水线的并发度。

图片 10 

Bolt可以给五个流吐出元组数据。此时需要动用Output菲尔德(Field)(Field)sDeclarer的declareStream方法来声称多少个流并在运用[OutputColletor](https://storm.apache.org/javadoc/apidocs/backtype/storm/task/OutputCollector.html)的emit方法时指定给哪个流吐数据。

当你阐明了一个Bolt的输入流,也就订阅了另外一个零件的某个特定的输出流。如若指望订阅另一个零部件的兼具流,需要单独挨个订阅。InputDeclarer有语法糖来订阅ID为默认值的流。例如declarer.shuffleGrouping(“redBolt”)订阅了redBolt组件上的默认流,跟declarer.shuffleGrouping(“redBolt”,
DEFAULT_STREAM_ID)是一样的。

在Bolt中最根本的函数是execute函数,它采纳一个新的元组当作输入。Bolt使用OutputCollector对象来吐出新的元组。Bolts必须为处理的每个元组调用OutputCollector的ack方法以便于Storm知道元组何时被依次Bolt处理完了(最终就足以肯定Spout吐出的某部元组处理完了)。通常处理一个输入的元组时,会依照这些元组吐出零个或者六个元组,然后确认(ack)输入的元组处理完了,Storm提供了IBasicBolt接口来机关完成确认。

不可能不注意OutputCollector不是线程安全的,所以具有的吐数据(emit)、确认(ack)、公告未果(fail)必须暴发在同一个线程里。更多信息方可参见问题一定

6) Task

各类Spout和Bolt会以四个任务(Task)的花样在集群上运行。每个任务对应一个举行线程,流分组定义了什么从一组任务(同一个Bolt)发送元组到其余一组任务(其余一个Bolt)上。可以在调用TopologyBuilder的setSpout和setBolt函数时设置每个Spout和Bolt的并发数。

7) Component

组件(component)是对Bolt和Spout的统称

8) Stream Grouping

概念拓扑的时候,一部分做事是指定每个Bolt应该花费怎么样流。流分组定义了一个流在一个消费它的Bolt内的两个任务(task)之间什么分组。流分组跟总计机网络中的路由效能是近似的,决定了每个元组在拓扑中的处理途径。

在Storm中有六个放置的流分组策略,你也可以经过实现CustomStreamGrouping接口来自定义一个流分组策略:

洗牌分组(Shuffle
grouping): 
随意分配元组到Bolt的某个任务上,这样保证同一个Bolt的每个任务都可以赢得相同数量的元组。

字段分组(Fields
grouping): 
遵照指定的分组字段来展开流的分组。例如,流是用字段“user-id”来分组的,这拥有相同“user-id”的元组就会分到同一个任务里,可是有例外“user-id”的元组就会分到不同的职责里。这是一种极度关键的分组办法,通过这种流分组格局,我们就足以成功让Storm产出的新闻在这么些”user-id”级别是严苛有序的,这对部分对时序敏感的采取(例如,计费系统)是特别首要的。

Partial Key
grouping: 
跟字段分组一样,流也是用指定的分组字段举行分组的,可是在两个下游Bolt之间是有负载均衡的,这样当输入数据有倾斜时可以更好的使用资源。这篇论文很好的演说了这是什么行事的,有咋样优势。

All grouping: 流会复制给Bolt的有所任务。小心使用这种分组办法。

Global
grouping:
 整个流会分配给Bolt的一个任务。具体一点,会分配给有小小ID的职责。

不分组(None grouping): 表达不关心流是什么分组的。近年来,None
grouping等价于洗牌分组。

Direct
grouping:
一种特有的分组。对于如此分组的流,元组的劳动者决定消费者的哪个任务会收取处理这一个元组。只可以在宣称做直连的流(direct
streams)上宣示Direct
groupings分组形式。只好通过采用emitDirect体系函数来吐元组给直连流。一个Bolt能够通过提供的TopologyContext来取得消费者的天职ID,也得以经过OutputCollector对象的emit函数(会回去元组被发送到的任务的ID)来跟踪消费者的职责ID。

Local or shuffle
grouping:假使目的Bolt在同一个worker进程里有一个或七个任务,元组就会通过洗牌的主意分配到那些同一个进程内的职责里。否则,就跟一般的洗牌分组一样。

图片 11 

9) Reliability

Storm保证了拓扑中Spout爆发的各种元组都会被拍卖。Storm是通过跟踪每个Spout所发出的富有元组构成的树形结构并得知这棵树哪一天被完好地拍卖来达成可靠性。每个拓扑对这个树形结构都有一个提到的“音信超时”。假使在这一个超时时间里Storm检测到Spout发生的一个元组没有被成功拍卖完,那Spout的这多少个元组就处理失败了,后续会重新处理两次。

为了表达Storm的可靠性,需要你在创造一个元组树中的一条边时告诉Storm,也急需在拍卖完每个元组之后告诉Storm。这一个都是由此Bolt吐元组数据用的OutputCollector对象来成功的。标记是在emit函数里完成,完成一个元组后需要运用Ack函数来报告Storm。

10) Workers

拓扑以一个或四个Worker进程的法子运行。每个Worker进程是一个物理的Java虚拟机,执行拓扑的一片段任务。例如,就算拓扑的产出设置成了300,分配了50个Worker,那么每个Worker执行6个任务(作为Worker内部的线程)。Storm会尽量把装有的职责均分到所有的Worker上。

百度Hadoop主题架构师亲自录制

7. Storm常用配置

1) Config.TOPOLOGY_WORKERS:

其一设置用略带个干活经过来举办这多少个topology。比如,假设您把它设置成25,
那么集群里面一共会有25个java进程来执行这么些topology的富有task。假若您的这多少个topology里面所有组件加起来一共有150的并行度,那么每个过程之中会有6个线程(150
/ 25 = 6)。

2) Config.TOPOLOGY_ACKERS:

本条布局安装acker任务的并行度。默认的acker任务并行度为1,当系统中有大气的音讯时,应该适量增强acker任务的并发度。设置为0,通过此形式,当Spout发送一个信息的时候,它的ack方法将立即被调用;

3) Config.TOPOLOGY_MAX_SPOUT_PENDING:

那些装置一个spout
task上边最多有微微个没有处理的tuple(没有ack/failed)回复,
我们推荐你设置那么些布局,以预防tuple队列爆掉。

4) Config.TOPOLOGY_MESSAGE_TIMEOUT_SECS:

其一布局storm的tuple的晚点时间 –
领先这一个日子的tuple被认为处理失利了。这一个设置的默认设置是30秒

 

相关文章