storm 初识

Storm是什么？

Storm是一个分布式的实时流处理框架。

“实时”怎么理解？

“实时”一般指的是near real-time（近实时），即系统对特定事件处理的响应时间对终端用户没有明显的延迟，通常响应时间为毫秒级别。对于Storm来说，实时（sub-second time，亚秒级）和近实时（几秒或几分钟，具体取决于使用的场景）都是可能的。

什么是流处理？它和批处理的区别是什么？

流处理指的是将数据看做流，持续不断的数据形成了数据流，当最新的数据到来时，就立刻处理并返回处理结果。它的处理过程都是在内存中进行的，通常不会对数据做持久化存储。

它和批处理的区别在于批处理是先存储再处理，而流处理则直接处理。

详见这篇文章http://blog.csdn.net/qiruiduni/article/details/50481031的“大数据的处理模式部分”。

相关概念

• Topology
  Topology可以把它看做一棵树，树的每个节点为一个task，也可以看做是Spout或Bolt，图中节点之间连接线可以看做为流（Stream）。Topology和Hadoop中的Job很类似，都可以看做一个业务作业。
  
• Tuple
  在Topology中，节点之间传输数据以Tuple（元组）的形式发送的，它是Storm的主要数据结构，可以把它看做一个有序的值列表，每个value都有相应的名称，像这样的结构：[name1="value1", name="value2"]，value的类型是动态的，不需要声明指定，但是Storm需要知道怎么序列化这些value值，默认，Storm知道怎么序列化一些基本的数据类型，如String、byte array等。如果要使用其他的类型，需要实现序列化，并为该类型注册一个序列化器。
• Stream
  Topology中，节点之间的连线就可看做为Stream，它是一个无限的Tuple序列。
• Spout
  Spout是Topology中的源，它负责从一个外部的数据源读取数据并发送Tuple给下一个节点。它可以监听一个消息队列、监听一个数据库的变化等，它不对数据做任何处理，仅是读取并发送。
• Bolt
   Bolt是Topology中的工作节点，它接收Tuple作为输入，并对Tuple做一些计算或转换（过滤、聚合、合并），然后把处理结果以一个Tuple发出（也可以不发出）。
• Stream Grouping
  Stream grouping定义了Tuple是如何在Spout和Bolt之间传输分发的，分发的形式主要有以下几种：
  • Shuffle Grouping
    Shuffle Grouping将Tuple随机（random）分发给Bolts，这种分发方式可以保证每个bolt能够接收到大致相等的Tuple数量，但并保证是绝对完全相等的。通常适用于不须关心数据是怎么分发给Bolt的情景。
  • Fields Grouping
    Fields grouping保证对于特定的field name的值总是能够被发送到同一个Bolt实例。
  • All Grouping
  • Global Grouping
  • Custom Grouping
  • ....

Storm 的可靠性

Storm的可靠性是指Storm有能力能够保证一个Message（Tuple）能够被Topology中的节点完全处理。

那么，“完全处理”该怎么理解？

一个Tuple从Spout发出，会导致下游多个bolt的Tuple发出，就形成了一个Tuple Tree，从Spout发出的Tuple称为树根root，Tuple每经过一个节点都会被打上一个“已处理”的标记，直到最后一个叶子节点成功完成处理，然后会调用一个ack()回执方法，通知Storm该Tuple已完全处理。如果在某个节点处理时发生错误或异常，将会调用fail()方法，通知该Tuple处理失败，然后Storm会重放（replay）该Tuple，以确保该Tuple被完全处理。整个过程无论是成功处理，还是失败重新处理，都被理解为完全处理。

实际是怎么工作的？

实际Storm通过一个Acker（锚定）组件，来追踪Tuple Tree 中Tuple的状况。每一个从Spout流出的Tuple都会被打上一个锚定（Anchoring），如果成功处理，就会调用ack()方法向Storm报告已完全处理，如果出现异常，就会调用fail()方法，通知Storm重新（replay）处理。然后Tuple流入到下游的bolt，也是按同样的方式来处理Tuple。

对于Bolt中的Tuple的可靠性有两种形式：隐式（implicit）和显示（explicit），这两种形式主要和bolt的实现有关，如果bolt使用的是BaseBasicBolt实现，那么Storm会自动为Tuple打上Anchoring，并且自动通知Storm对Tuple的处理情况。对于BaseBasicBolt的实现通常适用于比较简单的情况，对于较复杂的（如：聚合、流入多个Stream），通常要用BaseRichBolt实现来显示打上Anchoring，如：outputCollector.emit(tuple, new Values(order))，如果没有显示指定，该Tuple不会被加入Tuple tree，在该Tuple失败时，也不会通知Storm。同样ack/fail时也要显示指定。

对于Spout来说，每一个发出的Tuple都有一个对应的messageId，如果没有设定messageId，Storm将不会对Tuple进行追踪。同样，一个可靠的（reliable）数据源也是至关重要的，因为对一个不可靠的数据源来说，它发送的消息是不可replay的。

可靠性程度级别：

• At-most-once processing
• At-least-once processing
• Exactly-once processing

总的来说，Storm的可靠性需要满足以下四个方面：

1. 可靠的数据来源。
2. 一个带有Anchoring的Tuple Stream。
3. 在Tuple处理成功或失败时，Topology能够得到通知（ack）。
4. 一个具有容错性（fault-tolerant）的Storm集群。

Storm的容错性

Storm 集群

一个Storm集群包含两种类型的节点：master node和worker node，master node只有一个，它运行一个称之为Nimbus的守护进程。剩下的其它节点就是worker node节点了，每个worker节点都运行着一个称之为Supervisor的守护进程。

Master 节点主要负责分发代码、给worker 节点分配task、监控失败节点以及运行Storm UI等。

Worker 节点主要负责监听分配的任务、启动/停止worker进程等。

下图为Storm集群中各个组件及各个组件的相应职责：

       

Storm集群依赖于ZooKeeper，通过ZooKeeper来协调Nimbus和各个Supervisor的交互，并保存每个Nimbus和Supervisor的交互状态。如下图：

1、An executor is a thread of execution within a JVM. A task is an instance of a spout or bolt running within that thread of execution

2、replaying always starts at the spout

Storm调优

对系统优化，向来都是一个比较艰巨的任务，但Storm提供了一个能够快速找出应用瓶颈的工具：Storm UI，通过它可以看到Storm的运行状况，包括每个Topology运行状态的统计、Topology的配置信息、每个Spout、Bolt的运行状况的统计以及相关的错误信息等。

对于Storm的调优，通常主要从两个方面来调整：并行和延迟。

并行

对Bolt来说，主要观察Storm UI的Bolt栏的“Capacity”列，该列显示了每个Bolt在特定时间窗口内处理Tuple所花费的时间百分比，如果某些列值接近于1，表明该Bolt在“满负荷”工作，就可以把它认为一个瓶颈，解决这个瓶颈的方式就是增加这个Bolt的并行度。

对Spout来说，主要控制数据流入Topology的流速，即控制Spout的并行度。可从两个方面设置：1）、spout的数量  2）、每个Spout允许保留Tuple的最大数量，即未确认（unacked）的Tuple数量。对于第2点，是通过Spout的一个概念max spout pending来设置的，它允许我们控制Spout的摄取率，当在有大量数据涌入Topology时，可以保证Topology不会崩溃，它就像在Topology前面筑起了一座大坝。当然不设置它，数据仍是会继续流入Topology的。

延迟

对于延迟，分为外部和内部原因造成的延迟，外部原因主要体现在网络的延迟、GC造成的延迟、低效查询数据库的延迟、读取磁盘寻道造成的延迟等几方面。内部原因主要体现在和数据相关引起的延迟，比如对某个失败的Tuple反复的重试等。对于外部原因，可以考虑增加网络的吞吐量、优化JVM设置，降低GC的次数等，对于内部原因，可以对一些坏数据、错误异常等做相关处理。