Storm笔记

Hadoop与storm对比：

Hadoop：

1） 优点：吞吐量大，自动容错，在海量数据处理上得到广泛应用。

2） 缺点：不擅长实时计算，天然为批处理而生，高延迟，响应缓慢，运维复杂。

Storm：

1）优点：低延迟，高性能，分布式，运维简单，可扩展，高度容错（一个节点挂了，不能影响整体应用） ，无数据丢失，  消息不丢失   容易在上面开发应用程序

多语言（提交部分还是要用Java实现）

 

Mapreduce：

      坏处：慢

      好处：稳定

 

数据来源：

   hadoop：HDFS的T级别或者是PB级别的海量数据（历史数据）

   Storm：实时新增的某一笔数据（实时的数据）一般跟kafka做对接

 

处理过程：

   hadoop（Mapreduce）：

          map阶段   -》  reduce阶段

   Storm  Spout（数据源）  Bolt（处理逻辑）

是否有结束：

   hadoop：无论如何最后还是有结束的

   Storm：在不出错误的情况下，是没有结束的

 

处理速度：

   hadoop：设计的目标就是为了处理海量数据的（TB级，PB级的数据）

           处理数据速度较慢

   Storm：为了处理某一笔新增的数据，所以可以做到很快就处理完。

 

应用场景：

   hadoop：不讲究时效性的项目上面

   Storm：只需要处理新增数据，需要讲究时效性！！

 

 ===================================================

  Mapreduce1：

      Jobtracker

      TaskTracker

 

Hadoop中MapReduce两种组件：

Mapreduce1:

      用来处理批处理作业的

      有一个主节点叫Jobtracker，从节点叫TaskTracker

      我们提交任务提交给Jobtracker，Jobtracker把任务分配给TaskTracker

      提交任务的交Job

      任务运行的时候，任务类型有map 任务和reduce任务

Storm:

      用来处理实时作业的

      有一个主节点叫Nimbus， 从节点叫Supervisor  这两种组件没有状态，nimbus把任务状态和心跳信息都保存在zookeeper上，提交的代码资源都在本地机器的硬盘上。

 

storm的架构：

  是主从式的架构，主节点叫Nimbus,从节点叫Supervisor

  nimbus  和 Supervisor之间是不直接进行沟通联系的。

  Nimbus:

     1) 提交任务提交给Nimbus，Nimbus要把这些任务分配给

         Supervisor。Nimbus 把任务信息发送到zookeeper的znode上。

         Supervisor是通过去监控相对应的znode节点的信息

 

    2）通过去监控zookeeper的某个znode，就知道整个集群Supervisor的情况。

  Supervisor:

     1）启动了以后去zookeeper上去注册。把信息写到某个znode上。

     2）获取到任务情况，去运行程序。

      

  zookeeper:

     在nimbus 和  Supervisor 之间协调。

 

     这种架构模式，值得我们借鉴！！

 

Nimbus负责在集群里发送代码，分配工作给机器，并且监控状态。全局只有一个。

Supervisor会监听分配给它那台机器的工作，根据需要启动/关闭工作进程Worker。每一个要运行storm的机器上都要部署一个，并且机器的配置设定上面分配的槽位数。 Zookeeper是storm重点依赖的外部资源。Nimbus和supervisor甚至实际运行的Worker都是把心跳保存在zookeeper上的。Nimbus也是根据zookeeper上的心跳和认为运行状况，进行调度和任务分配的。

      我们提交任务提交给Nimbus，Nimbus把任务分配给Supervisor

      提交的任务叫topology

      任务运行的时候，任务类型有spout任务和bolt任务。

Topology处理的最小的消息单位是一个Tuple，也就是一个任意对象的数组。

·        Topology由Spout和Bolt构成。Spout是发出Tuple的结点。Bolt可以随意订阅某个Spout或者Bolt发出的Tuple。Spout和Bolt都统称为component。

Nimbus只有一个（JStorm  ninmbus HA）

 

Topology的提交流程图：


  Storm数据交互图:可以看出两个模块Nimbus和Supervisor之间没有直接交互。状态都是保存在Zookeeper上。Worker之间通过ZeroMQ传送数据。

有些地方做得还是不太好，例如，底层使用的ZeroMQ不能控制内存使用(下个release版本，引入了新的消息机制使用netty代替ZeroMQ），多语言支持更多是噱头，Nimbus还不支持HA。但是，就像当年的Hadoop那样，很多公司选择它是因为它是唯一的选择。而这些先期使用者，反过来促进了Storm的发展。

我们只需要实现每个分析的过程，而Storm帮我们把消息的传送和接受都完成了。更加激动人心的是，你只需要增加某个Bolt的并行度就能够解决掉某个结点上的性能瓶颈。

需要知道Storm不是一个完整的解决方案。使用Storm你需要加入消息队列做数据入口，考虑如何在流中保存状态，考虑怎样将大问题用分布式去解决。解决这些问题的成本可能比增加一个服务器的成本还高。但是，一旦下定决定使用了Storm并解决了那些恼人的细节，你就能享受到Storm给你带来的简单，可拓展等优势了。

 

Supervisor默认端口号为4个   可以提供4份slot资源   跟CPU核数一样