Strom 详解

首先回顾map reduce框架

主节点jobtracker，从节点 taskTracker。

用户提交任务给jobtracker，jobtracker分配给taskTracker，我们管这些任务叫job

运行的作业分为两种 map 和 reduce。

Storm是一个实时计算框架

主节点 nimbus  从节点 supervisor

用户提交作业给nimbus， nimbus把任务分配给supervisor，这些提交的任务就是topology（拓扑）

运行的作业分为两种 spout 和 bolt。

Storm是流式的处理既stream，stream的内容是tuple（元组）

Spout生产tuple（元组）发送给bolt处理，bolt处理过的tuple也可以再次发送给其他的tuple处理，最后存入容器。

Tuple的内容详解：

每一个Tuple都是一个值的集合，值是以name, value的形式存在tuple中，topology的每个节点都是靠name来接受和处理tuple

Topology（计算拓扑）

Topology相当与mayreduce中的job,但是，job任务会执行完，但topology不会结束，除非显示杀死它

Topology是由spouts和bolts组成

Spouts和bolts之间靠stream  groupings链接，如上图

stream  groupings消息分发策略

1、Shuffle Grouping：随机分组，随机派发stream里面的tuple，保证每个bolt接收到的tuple数目相同。

2、Fields Grouping：按字段分组，比如按userid来分组，具有同样userid的tuple会被分到相同的Bolts，而不同的userid则会被分配到不同的Bolts。

3、All Grouping：广播发送，对于每一个tuple，所有的Bolts都会收到。

4、Global Grouping: 全局分组，这个tuple被分配到storm中的一个bolt的其中一个task。再具体一点就是分配给id值最低的那个task。

5、Non Grouping：不分组，这个分组的意思是说stream不关心到底谁会收到它的tuple。目前这种分组和Shuffle grouping是一样的效果，有一点不同的是storm会把这个bolt放到这个bolt的订阅者同一个线程里面去执行。

6、Direct Grouping：直接分组,  这是一种比较特别的分组方法，用这种分组意味着消息的发送者指定由消息接收者的哪个task处理这个消息。只有被声明为Direct Stream的消息流可以声明这种分组方法。而且这种消息tuple必须使用emitDirect方法来发射。消息处理者可以通过TopologyContext来获取处理它的消息的taskid (OutputCollector.emit方法也会返回taskid)

注：Local or shuffle grouping：如果目标bolt有一个或者多个task在同一个工作进程中，tuple将会被随机发生给这些tasks。否则，和普通的Shuffle Grouping行为一致。

Streams：消息流

消息流是一个没有边界的tuple序列，而这些tuples会被以一种分布式的方式并行创建和处理。每个tuple可以包含多列，字段类型可以是：integer,long,short,byte,string,double,float,boolean和byte array。你还可以自定义类型--只要实现了对应的序列化器。

Spout（获取消息源的组件）

spout是topology消息生产者。spout从一个外部源（消息队列）读取数据向topology发出tuple。消息源spouts可以使可靠地也可以是不可靠的。一个可靠地消息源可以重新发射一个处理失败的tuple，一个不可靠的消息源spouts不会。

spout累的方法nextTuple不断发射tuple到topology，storm在检测到一个tuple被整个topology成功处理的时候调用ack，否则调用fail。

storm只对可靠的spout调用ack和fail。

Bolt（消息处理者）

消息处理逻辑被封装在bolts里面，Bolts可以做很多事情：过滤，聚合，查询数据库等。Bolts可以简单的做消息流的传递。负责的消息流处理往往需要很多步骤，从而也就需要经过很多Bolts。第一级bolt的输出可以作为下一级bolt的输入。而spout只能有一级。

bolts的主要方法是execute（死循环）连续处理传入的tuple，成功处理完每一个tuple后可以回调OutputCollector的ack方法，以通知storm这个tuple被处理完成了。当处理失败时，可以调fail方法通知spout端可以重新发送改tuple。

流程是：bolts处理一个输入tuple，然后调用ack通知storm自己已经处理过这个tuple了。

storm提供了一个IBasicBolt会自动调用ack。

Bolts使用OutputCollector来发射tuple到下一级Blot。

消息的可靠性

一个消息(tuple)从spout发送出来，可能会导致成百上千的消息基于此消息被创建

“单词统计”的例子：

storm任务从数据源每次读取一个完整的英文句子；将这个句子分解为独立的单词，最后，实时的输出每个单词以及它出现过的次数。

每个从spout发送出来的消息（每个英文句子）都会触发很多的消息被创建，那些从句子中分隔出来的单词就是被创建出来的新消息。

这些消息构成一个树状结构，我们称之为“tuple tree”

一条数据在Spout中形成一个Tuple，然后交给一个个Bolt执行,那我们怎么保证这个Tuple被完整的执行了呢？这里的完整执行说的是这个Tuple必须在后面的每一个Bolt都成功处理，假设在一个Bolt中发生异常导致失败，这就不能算完整处理。

为了保证消息处理过程中的可靠性,storm使用了ack机制。storm会专门启动若干acker线程，来追踪tuple的处理过程。acker线程数量可以设置。

每一个Tuple在Spout中生成的时候,都会分配到一个64位的messageId。通过对messageId进行哈希我们可以执行要对哪个acker线程发送消息来通知它监听这个Tuple。

acker线程收到消息后,会将发出消息的Spout和那个messageId绑定起来。然后开始跟踪该tuple的处理流程。如果这个tuple全部都处理完，那么acker线程就会调用发起这个tuple的那个spout实例的ack()方法。如果超过一定时间这个tuple还没处理完，那么acker线程就会调用对应spout的fail()方法,通知spout消息处理失败。spout组件就可以重新发送这个tuple。

从上面的介绍我们知道了，tuple数据的流向会形成一个拓扑图，也可以理解成是一个tuple树。这个拓扑图的节点可能会有很多个，如果要把这些节点全部保存起来，处理大量的数据时势必会造成内存溢出。

对于这个难题，storm使用了一种非常巧妙的方法，使用20个字节就可以追踪一个tuple是否被完整的执行。这也是storm的一个突破性的技术

消息完整条件：

无论何时在tuple tree中创建了一个新的节点，我们需要明确的通知Storm；

当处理完一个单独的消息时，我们需要告诉Storm 这棵tuple tree的变化状态。

通过上面的两步，storm就可以检测到一个tuple tree何时被完全处理了，并且会调用相关的ack或fail方法。

在什么条件下，Storm才会认为一个从spout发送出来的消息被完整处理呢?

tuple tree不再生长

树中的任何消息被标识为“已处理”

集群整体架构

Nimbus和Sipervisor必须通过zookeeper集群进行交互

nimbus进程和sipervisor是无法直接链接和无状态的

所有的状态维持在zookeeper中或保存在本地磁盘上

这意味着可以直接kill -9 这两个进程而不需要做备份

这种设计使storm集群具有令人难以置信的稳定行，即无耦合

 

Worker

Supervisor会监听分配给它那台机器的工作，根据需要启动/关闭工作进程，这个工作进程就是worker

每一个worker都会占用工作节点的一个端口，这个端口可以在storm.yarm中配置。

一个topology可能会在一个或者多个工作进程里面执行，每个工作进程执行整个topology的一部分，所以一个运行的topology由运行在很多机器上的很多工作进程组成。

Task任务

每一个Spout和Bolt会被当作很多task在整个集群里面执行。默认情况下每一个task对应到一个线程（Executor），这个线程用来执行这个task，而stream grouping则是定义怎么从一堆task发射tuple到另外一堆task。

配置Configuration

storm里面有一堆参数可以配置来调整nimbus, supervisor以及正在运行的topology的行为， 一些配置是系统级别的， 一些配置是topology级别的。所有有默认值的配置的默认配置是配置在default.xml里面的。你可以通过定义个storm.xml在你的classpath里面来覆盖这些默认配置。并且你也可以在代码里面设置一些topology相关的配置信息  – 使用StormSubmitter。当然，这些配置的优先级是: default.xml < storm.xml < TOPOLOGY-SPECIFIC配置。

 

原文：https://blog.csdn.net/qq_39162838/article/details/81112779 
参考资料：https://www.w3cschool.cn/apache_storm/apache_storm_applications.html