Storm-编程入门


一 编程接口java

 

 

 



Spout 接口编程

 

Spout组件的实现能够经过继承BaseRichSpout类或者其余*Spout类来完成,也能够经过实现IRichSpout接口来实现。须要根据状况实方法有:数组

 

open方法缓存

 

当一个Task被初始化的时候会调用此open方法。通常都会在此方法中对发送Tuple的对象SpoutOutputCollector和配置对象TopologyContext初始化。示例以下:框架

 

public void open(Map conf, TopologyContext context, SpoutOutputCollector collector) {   dom

          _collector = collector;  分布式

}  函数

declareOutputFields方法ui

 

此方法用于声明当前SpoutTuple发送流的域名字。Stream流的定义是经过OutputFieldsDeclare.declareStream方法完成的,其中参数为域名。示例以下:google

 

public void declareOutputFields(OutputFieldsDeclarer declarer) {  

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

}

getComponentConfiguration方法

 

此方法定义在BaseComponent类内,用于声明针对当前组件的特殊的Configuration配置。示例以下:

 

public Map<String, Object> getComponentConfiguration() {  

         if(!_isDistributed) {  

           Map<String, Object> ret = new HashMap<String, Object>();  

           ret.put(Config.TOPOLOGY_MAX_TASK_PARALLELISM, 3);  

           return ret;  

         } else {  

             return null;  

         }  

 }  

这里即是设置了Topology中当前Component的线程数量上限。

 

nextTuple方法

 

这是Spout类中最重要的一个方法。发射一个TupleTopology都是经过这个方法来实现的。示例以下:

 

public void nextTuple() {  

     Utils.sleep(100);  

     final String[] words = new String[] {"twitter","facebook","google"};  

     final Random rand = new Random();  

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

     _collector.emit(new Values(word));  

}  

这里即是从一个数组中随机选取一个单词做为Tuple,而后经过_collector发送到Topology

 

另外,除了上述几个方法以外,还有ackfailclose方法等。Storm在监测到一个Tuple被成功处理以后会调用ack方法,处理失败会调用fail方法,这两个方法在BaseRichSpout类中已经被隐式的实现了。

 

Bolts 接口

 

Bolt类接收由Spout或者其余上游Bolt类发来的Tuple,对其进行处理。Bolt组件的实现能够经过继承BasicRichBolt类或者IRichBolt接口来完成。Bolt类须要实现的主要方法有:

 

prepare方法

 

此方法和Spout中的open方法相似,为Bolt提供了OutputCollector,用来从Bolt中发送Tuple。示例以下:

 

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

         _collector = collector;  

注:BoltTuple的发送能够在prepare方法中、execute方法中、cleanup等方法中进行,通常都是些在execute中。

 

declareOutputFields 方法

 

用于声明当前Bolt发送的Tuple中包含的字段,和Spout中相似。示例以下:

 

public void declareOutputFields(OutputFieldsDeclarer declarer) {  

       declarer.declare(new Fields("obj", "count", "length"));  

}  

此例说明当前Bolt类发送的Tuple包含了三个字段:"obj", "count", "length"

 

getComponentConfiguration方法

 

Spout类同样,在Bolt中也能够有getComponentConfiguration方法。示例以下:

 

public Map<String, Object> getComponentConfiguration() {  

         Map<String, Object> conf = new HashMap<String, Object>();  

         conf.put(Config.TOPOLOGY_TICK_TUPLE_FREQ_SECS, emitFrequencyInSeconds);  

         return conf;  

此例定义了从系统组件“_system”的“_tick”流中发送Tuple到当前Bolt的频率,当系统须要每隔一段时间执行特定的处理时,就能够利用这个系统的组件的特性来完成。

 

execute方法

 

这是Bolt中最关键的一个方法,对于Tuple的处理均可以放到此方法中进行。具体的发送也是经过emit方法来完成的。此时,有两种状况,一种是emit方法中有两个参数,另外一个种是有一个参数。

 

(1) emit有一个参数:此惟一的参数是发送到下游BoltTuple,此时,由上游发来的旧的Tuple在此隔断,新的Tuple和旧的Tuple再也不属于同一棵Tuple树。新的Tuple另起一个新的Tuple树。

 

(2) emit有两个参数:第一个参数是旧的Tuple的输入流,第二个参数是发往下游Bolt的新的Tuple流。此时,新的Tuple和旧的Tuple是仍然属于同一棵Tuple树,即若是下游的Bolt处理Tuple失败,则会向上传递到当前Bolt,当前Bolt根据旧的Tuple流继续往上游传递,申请重发失败的Tuple。保证Tuple处理的可靠性。

 

这两种状况要根据本身的场景来肯定。示例以下:

 

public void execute(Tuple tuple) {  

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

          _collector.ack(tuple);  

}  

注:输入Tuple通常在最后一行被ack

 

public void execute(Tuple tuple) {  

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

 } 

此外还有ack方法、fail方法、cleanup方法等。其中cleanup方法和Spout中的close方法相似,都是在当前Component关闭时调用,可是针对实时计算来讲,除非一些特殊的场景要求之外,这两个方法通常都不多用到。

 

注:cleanup方法在bolt被关闭的时候调用, 它应该清理全部被打开的资源。可是集群不保证这个方法必定会被执行。好比执行task的机器down掉了,那么根本就没有办法来调用那个方法。cleanup设计的时候是被用来在local mode的时候才被调用(也就是说在一个进程里面模拟整个storm集群), 而且你想在关闭一些topology的时候避免资源泄漏。

 

有几点须要说明的地方:

 

1.每一个组件(Spout或者Bolt)的构造方法和declareOutputFields方法都只被调用一次。

 

2.open方法、prepare方法的调用是屡次的。入口函数中设定的setSpout或者setBolt里的并行度参数指的是executor的数目,即负责运行组件中的task的线程的数目,此数目是多少,上述的两个方法就会被调用多少次,在每一个executor运行的时候调用一次。至关于一个线程的构造方法。

 

3.nextTuple方法、execute方法是一直被运行的,nextTuple方法不断的发射TupleBoltexecute不断的接收Tuple进行处理。只有这样不断地运行,才会产生无界的Tuple流,体现实时性。

 

4.在提交了一个topology以后,Storm就会建立spout/bolt实例并进行序列化。以后,将序列化的component发送给全部的任务所在的机器(Supervisor节点),在每个任务上反序列化component

 

5. SpoutBolt之间、BoltBolt之间的通讯,是经过zeroMQ的消息队列实现的。

 

二 做业的提交

 

下面的代码展现了以本地运行方式提交一个Topology做业

 

//Topology definition  

   TopologyBuilder builder = new TopologyBuilder();  

   builder.setSpout("word-reader",new WordReader());  

   builder.setBolt("word-normalizer", new WordNormalizer())  

     .shuffleGrouping("word-reader");  

   builder.setBolt("word-counter", new WordCount(),1)  

     .fieldsGrouping("word-normalizer", new Fields("word"));  

  

  //Configuration  

    Config conf = new Config();  

   conf.put("wordsFile", args[0]);  

   conf.setDebug(true);  

  

  //Topology run  

   conf.put(Config.TOPOLOGY_MAX_SPOUT_PENDING, 1);  

   LocalCluster cluster = new LocalCluster();  

   cluster.submitTopology("Getting-Started-Toplogie", conf, builder.createTopology());  

   Thread.sleep(2000);  

   cluster.shutdown(); 

此例中的builderTopologyBuilder对象,经过它的createTopology方法能够建立一个Topology对象,同时此builder还要定义当前Topology中用到的SpoutBolt对象,分别经过setSpout方法和setBolt方法来完成。

 

setSpout方法和setBolt方法中的第一个参数是当前的Component组件的StreamID号;第二个参数是具体的Component实现类的构造;第三个参数是当前Component的并行执行的线程数目,Storm会根据这个数字的累加和来肯定TopologyTask数目。

 

经过一个LocalCluster对象来定义一个进程内的集群。提交topology给这个虚拟的集群和提交topology给分布式集群是同样的。经过调用submitTopology方法来提交topology, 它接受三个参数:要运行的topology的名字,一个配置对象以及要运行的topology自己。

 

下面对workerexecutor以及task作一下说明:

 

worker:每一个worker都属于一个特定的Topology,每一个Supervisor节点的worker能够有多个,每一个worker使用一个单独的端口,它对Topology中的每一个component运行一个或者多个executor线程来提供task的运行服务。其数目能够经过设置yaml中的topology.workers属性以及在代码中经过ConfigsetNumWorkers方法设定。

 

executor:产生于worker进程内部的线程,会执行同一个component的一个或者多个task。 其数目能够在Topology的入口类中setBoltsetSpout方法的最后一个参数指定,不指定的话,默认为1

 

task:实际的数据处理由task完成,在Topology的生命周期中,每一个组件的task数目是不会发生变化的,而executor的数目却不必定。executor数目小于等于task的数目,默认状况下,两者是相等的。在代码中经过TopologyBuildersetNumTasks方法设定具体某个组件的task数目;

 

有几点须要说明的地方:

 

1.Storm提交后,会把代码首先存放到Nimbus节点的inbox目录下,以后,会把当前Storm运行的配置生成一个stormconf.ser文件放到Nimbus节点的stormdist目录中,在此目录中同时还有序列化以后的Topology代码文件;

 

2.在设定Topology所关联的SpoutsBolts时,能够同时设置当前SpoutBoltexecutor数目和task数目,默认状况下,一个Topologytask的总和是和executor的总和一致的。以后,系统根据worker的数目,尽可能平均的分配这些task的执行。worker在哪一个supervisor节点上运行是由storm自己决定的;

 

3. 任务分配好以后,Nimbes节点会将任务的信息提交到zookeeper集群,同时在zookeeper集群中会有workerbeats节点,这里存储了当前Topology的全部worker进程的心跳信息;

 

4. Supervisor节点会不断的轮询zookeeper集群,在zookeeperassignments节点中保存了全部Topology的任务分配信息、代码存储目录、任务之间的关联关系等,Supervisor经过轮询此节点的内容,来领取本身的任务,启动worker进程运行;

 

5.一个Topology运行以后,就会不断的经过Spouts来发送Stream流,经过Bolts来不断的处理接收到的Stream流,Stream流是无界的。最后一步会不间断的执行,除非手动结束Topology

 

6.经过在Nimbus节点利用以下命令来终止一个Topology的运行:storm kill topologyName kill以后,能够经过UI界面查看topology状态,会首先变成KILLED状态,在清理完本地目录和zookeeper集群中的和当前Topology相关的信息以后,此Topology就会完全消失了。

 

三 分组策略

 

1.shuffleGrouping 随机分组

 

builder.setBolt("word-normalizer", new WordNormalizer())

           .shuffleGrouping("word-reader");

它只有一个参数(数据源组件),而且数据源会向随机选择的bolt发送元组,保证每一个消费者收到近似数量的元组。

 

2.fieldsGrouping 域数据流组

 

builder.setBolt("word-counter", new WordCounter(),2)

           .fieldsGrouping("word-normalizer", new Fields("word"));

域数据流组容许你基于元组的一个或多个域控制如何把元组发送给bolts。它保证拥有相同域组合的值集发送给同一个bolt

 

在域数据流组中的全部域集合必须存在于数据源的域声明中

 

3.allGrouping 所有数据流组

 

builder.setBolt("word-counter", new WordCounter(),2)

           .fieldsGroupint("word-normalizer",new Fields("word"))

           .allGrouping("signals-spout","signals");

所有数据流组,为每一个接收数据的实例复制一份元组副本。这种分组方式用于向全部bolts发送信号。好比,你要刷新缓存,你能够向全部的bolts发送一个刷新缓存信号。

 

4.customGrouping 自定义数据流组

 

builder.setBolt("word-normalizer", new WordNormalizer())

           .customGrouping("word-reader", new ModuleGrouping());

5.directGrouping 直接数据流组

 

builder.setBolt("word-counter", new WordCounter(),2)

           .directGrouping("word-normalizer");

这是一个特殊的数据流组,数据源能够用它决定哪一个组件接收元组。与前面的例子相似,数据源将根据单词首字母决定由哪一个bolt接收元组。

 

6.全局数据流组

 

全局数据流组把全部数据源建立的元组发送给单一目标实例(即拥有最低ID的任务)。

 

四 配置选项

 

在运行Topology以前,能够经过一些参数的配置来调节运行时的状态,参数的配置是经过Storm框架部署目录下的conf/storm.yaml文件来完成的。在此文件中能够配置运行时的Storm本地目录路径、运行时Worker的数目等。

 

在代码中,也能够设置Config的一些参数,可是优先级是不一样的,不一样位置配置Config参数的优先级顺序为:

 

default.yaml < storm.yaml <Topology内部的configuration <内部组件的special configuration < 外部组件的special configuration

 

storm.yaml中经常使用的几个选项为:

相关文章
相关标签/搜索