大数据处理框架之Strom：认识storm

Storm是分布式实时计算系统，用于数据的实时分析、持续计算，分布式RPC等。

（备注：5种常见的大数据处理框架：· 仅批处理框架：Apache Hadoop；· 仅流处理框架：Apache Storm 和 Apache Samza；· 混合框架：Apache Spark 和 Apache Flink）

水龙头出来的是水滴 不是水流柱说明单个数据量小，可是接二连三的，后面水滴加闪电 表示处理迅速。

 

1、storm架构结构

2、Strom和Hadoop 分类对比

二者应用场景不一样：
Storm：进程、线程常驻内存运行，数据不进入磁盘，数据经过网络传递，所以处理的单个数据大小不能过大。
MapReduce：为TB、PB级别数据设计的批处理计算框架。

3、Storm和Spark Streaming

Storm：纯流式处理，专门为流式处理设计，数据传输模式更为简单，不少地方也更为高效，并非不能作批处理，它也能够来作微批处理，来提升吞吐;
Spark Streaming：微批处理，将RDD作的很小来用小的批处理来接近流式处理，基于内存和DAG能够把处理任务作的很快;

storm是一个独立的框架，sparkstreaming是spark家族中一员，在大多数大数据应用场景下 使用sparkstreaming用的多一些；在独立的应用场景下 使用strom便可

 

4、Storm计算模型

系统角色组件

　　Nimbus：即Storm的Master，负责资源分配和任务调度。一个Storm集群只有一个Nimbus。
　　Supervisor：即Storm的Slave，负责接收Nimbus分配的任务，管理全部Worker，一个Supervisor节点中包含多个Worker进程。
　　Worker：工做进程，每一个工做进程中都有多个Task。
　　Task：任务，在 Storm 集群中每一个 Spout 和 Bolt 都由若干个任务（tasks）来执行。每一个任务都与一个执行线程相对应。

 

应用名称组件

　　Topology：计算拓扑，有向的工做流程图（DAG），Storm 的拓扑是对实时计算应用逻辑的封装，它的做用与 MapReduce 的任务（Job）很类似，区别在于 MapReduce 的一个 Job 在获得结果以后总会结束，而拓扑会一直在集群中运行，直到你手动去终止它。拓扑还能够理解成由一系列经过数据流（Stream Grouping）相互关联的 Spout 和 Bolt 组成的的拓扑结构。

组件接口

(1)Spout-数据源：

拓扑中数据流的来源。通常会从指定外部的数据源读取元组（Tuple）发送到拓扑（Topology）中;
一个Spout能够发送多个数据流（Stream）;
可先经过OutputFieldsDeclarer中的declare方法声明定义的不一样数据流，发送数据时经过SpoutOutputCollector中的emit方法指定数据流Id（streamId）参数将数据发送出去
Spout中最核心的方法是nextTuple，该方法会被Storm线程不断调用、主动从数据源拉取数据，再经过emit方法将数据生成元组（Tuple）发送给以后的Bolt计算;

(2)Bolt-数据流处理组件：

拓扑中数据处理均有Bolt完成。对于简单的任务或者数据流转换，单个Bolt能够简单实现；更加复杂场景每每须要多个Bolt分多个步骤完成
一个Bolt能够发送多个数据流（Stream）
可先经过OutputFieldsDeclarer中的declare方法声明定义的不一样数据流，发送数据时经过SpoutOutputCollector中的emit方法指定数据流Id（streamId）参数将数据发送出去
Bolt中最核心的方法是execute方法，该方法负责接收到一个元组（Tuple）数据、真正实现核心的业务逻辑

 (3)tuple-元组：

storm使用tuple来做为它的数据模型。每一个tuple是一堆值，每一个值有一个名字，而且每一个值能够是任何类型， 在个人理解里面一个tuple能够看做一个没有方法的java对象。整体来看，storm支持全部的基本类型、字符串以及字节数组做为tuple的值类 型。你也可使用你本身定义的类型来做为值类型， 只要你实现对应的序列化器(serializer)。

Tuple原本应该是一个Key-Value的Map，因为各个组件间传递的tuple的字段名称已经事先定义好了，因此Tuple只须要按序填入各个Value，因此就是一个Value List。

一个Tuple表明数据流中的一个基本的处理单元，例如一条cookie日志，它能够包含多个Field，每一个Field表示一个属性。

 

(4)Stream：

数据流（Streams）是 Storm 中最核心的抽象概念。一个数据流指的是在分布式环境中并行建立、处理的一组元组（tuple）的无界序列。数据流能够由一种可以表述数据流中元组的域（fields）的模式来定义。一个没有边界的、源源不断的、连续的Tuple序列就组成了Stream。

 

(5)Stream grouping-数据分发策略：

为拓扑中的每一个 Bolt 的肯定输入数据流是定义一个拓扑的重要环节。数据流分组定义了在 Bolt 的不一样任务（tasks）中划分数据流的方式。在 Storm 中有八种内置的数据流分组方式。

(5.1)Shuffle Grouping 
随机分组，随机派发stream里面的tuple，保证每一个bolt task接收到的tuple数目大体相同。
轮询，平均分配 
(5.2)Fields Grouping
按字段分组，好比，按"user-id"这个字段来分组，那么具备一样"user-id"的 tuple 会被分到相同的Bolt里的一个task， 而不一样的"user-id"则可能会被分配到不一样的task。 
(5.3)All Grouping
广播发送，对于每个tuple，全部的bolts都会收到 
(5.4)Global Grouping
全局分组，把tuple分配给task id最低的task 。
(5.5)None Grouping
不分组，这个分组的意思是说stream不关心到底怎样分组。目前这种分组和Shuffle grouping是同样的效果。 有一点不一样的是storm会把使用none grouping的这个bolt放到这个bolt的订阅者同一个线程里面去执行（将来Storm若是可能的话会这样设计）。 
(5.6)Direct Grouping
指向型分组， 这是一种比较特别的分组方法，用这种分组意味着消息（tuple）的发送者指定由消息接收者的哪一个task处理这个消息。只有被声明为 Direct Stream 的消息流能够声明这种分组方法。并且这种消息tuple必须使用 emitDirect 方法来发射。消息处理者能够经过 TopologyContext 来获取处理它的消息的task的id (OutputCollector.emit方法也会返回task的id)  
(5.7)Local or shuffle grouping
本地或随机分组。若是目标bolt有一个或者多个task与源bolt的task在同一个工做进程中，tuple将会被随机发送给这些同进程中的tasks。不然，和普通的Shuffle Grouping行为一致
(5.8)customGrouping
自定义，至关于mapreduce那里本身去实现一个partition同样。

(6)Reliability：可靠性。Storm 能够经过拓扑来确保每一个发送的元组都能获得正确处理。经过跟踪由 Spout 发出的每一个元组构成的元组树能够肯定元组是否已经完成处理。每一个拓扑都有一个“消息延时”参数，若是 Storm 在延时时间内没有检测到元组是否处理完成，就会将该元组标记为处理失败，并会在稍后从新发送该元组。

备注：在0.90版本之前默认使用zeroMQ作底层通讯，以后的版本默认适用Netty。

 

5、storm应用场景

一、异步处理

客户端提交数据进行结算，并不会等待数据计算结果，好比逐条处理（ETL）、统计分析（计算PV、UV、访问热点 以及 某些数据的聚合、加和、平均等，客户端提交数据以后，计算完成结果存储到Redis、HBase、MySQL或者其余MQ当中，客户端并不关心最终结果是多少）

二、同步处理

客户端提交数据请求以后，马上取得计算结果并返回给客户端，好比DRPC