流计算框架Apache Storm核心概念、架构设计
一、Apache Storm 是什么？
Apache Storm 是Twitter免费、开源的分布式实时计算系统，擅长处理海量数据，适用于数据实时处理而非批处理。
MapReduce框架主要解决的是静态数据的批量处理，即MapReduce 框架处理的是已存储到位的数据；但是流计算系统在启动是，一般数据并没有完全到位，而是源源不断地流入。批处理系统一般重视数据处理的吞吐量；流处理系统则更加关注数据处理的延时，希望流入的数据越快处理越好；
开发人员可以基于开源流处理框架Storm，快速搭建一套健壮的、易用的实时流处理系统。
二、Apache Storm核心概念
要了解Storm，首先要了解Storm的设计思想和核心概念。Nimbus：Storm集群主节点，负责资源分配和任务调度。我们提交任务和停止任务都是在Nimbus上操作的。一个Storm集群只有一个Nimbus节点。Supervisor：Storm集群工作节点，接受Nimbus分配任务，管理所有Worker。Worker：工作进程，每个工作进程中都有多个Task。Task：任务，每个Spout和Bolt都是一个任务，每个任务都是一个线程。Topology：计算拓扑，包含了应用程序的逻辑。Stream：消息流，关键抽象，是没有边界的Tuple序列。Spout：消息流的源头，Topology的消息生产者。Bolt：消息处理单元，可以过滤、聚合、查询数据库。Stream grouping：消息分发策略，一共6种，定义每个Bolt接受何种输入。Reliability：可靠性，Storm保证每个Tuple都会被处理。
Spout、Stream、Tuple 三者之间的关系
Storm Topology
Spout、Bolt、Tuple 三者之间的关系
Stream Grouping - 消息分发策略，用来告知Topology 如何在2个组件之间（如Spout和Bolt之间，或者不同的Bolt之间）进行Tuple的传送，
1. Shuffle Grouping ：随机分组，尽量均匀分布到下游Bolt中。
将流分组定义为混排。这种混排分组意味着来自Spout的输入将混排，或随机分发给此Bolt中的任务。shuffle grouping对各个task的tuple分配的比较均匀。
2. Fields Grouping ：按字段分组，按数据中field值进行分组；相同field值的Tuple被发送到相同的Task。
这种grouping机制保证相同field值的tuple会去同一个task，这对于WordCount来说非常关键，如果同一个单词不去同一个task，那么统计出来的单词次数就不对了。如果按照user-id分组，则tuple中有相同user-id的将分发给同一个task。
3. All grouping ：广播分发。
广播发送， 对于每一个tuple将会分发到每一个bolt中处理。
4. Global grouping ：全局分组，tuple被分配到一个Bolt中的一个Task，实现事务性的Topology。
Stream中的所有的tuple都会发送给同一个bolt任务处理，所有的tuple将会发送给拥有最小task_id的bolt任务处理。
5. None grouping ：不分组。
不关注并行处理负载均衡策略时使用该方式，目前等同于shuffle grouping，另外storm将会把bolt任务和他的上游提供数据的任务安排在同一个线程下。
6. Direct grouping ：直接分组，或者指定分组。
由tuple的发送单元直接决定tuple将发射给那个bolt，一般情况下是由接收tuple的bolt决定接收哪个bolt 发送的Tuple。这是一种比较特别的分组方法，用这种分组意味着消息的发送者指定由消息接收者的哪个task处理这个消息。 只有被声明为Direct Stream的消息流可以声明这种分组方法。而且这种消息tuple必须使用emitDirect方法来发送。消息处理者可以通过TopologyContext来获取处理它的消息的taskid (OutputCollector.emit方法也会返回taskid)。
三、Apache Storm 架构设计
Storm运行方式和Hadoop有点类似：在Hadoop上运行的是MapReduce作业；在Storm上运行的是Topology；
一个MapReduce作业最终会完成计算并结束运行，而一个Topology将持续处理消息，直到人为终止。
Storm集群采用Master-Worker的节点方式，其中Master节点运行名为：Nimbus的后台程序（类似Hadoop中的JobTracker），负责在集群范围内分发代码、为Worker分配任务和监测故障。
而每个Worker节点运行名为：Supervisor的后台程序，负责监听分配给它所在机器的工作，即根据Nimbus分配的任务来决定启动或停止Worker进程。
Storm 集群架构设计如下图所示。
Storm 采用Zookeeper来作为分布式协调组件，负责Nimbus和多个Supervisor之间的所有协调工作。
Nimbus后台进程和Supervisor后台进程都是快速失败（Fail-fast）和无状态（Stateless）的，Master节点并没有直接和Worker节点通信，而是借助Zookeeper将状态信息存放在Zookeeper中或本地磁盘中，以便节点故障时进行快速恢复。
Storm的工作流程如下图所示。
（1）客户端提交Topology到Storm集群（Nimbus）；
（2）Nimbus将分配给Supervisor的任务写入Zookeeper；
（3）Supervisor从Zookeeper中获取分配的任务（Task），并启动Worker进程；
（4）Worker进程执行具体的任务；
四、Storm和Spark Streaming比较
Storm和Spark Streaming的最大区别在于：Storm可以实现毫秒级响应；Spark Streaming无法实现毫秒级的流计算；
Spark Streaming无法实现毫秒级的流计算，是因为其将流数据按批处理窗口大小（通常在0.5-2s之间），分解为一系列批处理作业，在这个过程中会产生多个Spark作业，且每一段数据的处理都会经过Spark DAG图分解、任务调度过程，因此无法实现毫秒级响应。
Storm出来的单位是Tuple，只需要极小的延迟。
