Storm（一）分布式实时大数据处理框架

Storm介绍

Storm是Twitter开源的分布式实时大数据处理框架，最早开源于github，从0.9.1版本之后，归于Apache社区，被业界称为实时版Hadoop。随着越来越多的场景对Hadoop的MapReduce高延迟无法容忍，比如网站统计、推荐系统、预警系统、金融系统(高频交易、股票)等等，大数据实时处理解决方案（流计算）的应用日趋广泛，目前已是分布式技术领域最新爆发点，而Storm更是流计算技术中的佼佼者和主流。

为什么用storm？

Apache Storm是一个免费的开源分布式实时计算系统。Apache Storm使得可靠地处理无界数据流变得很容易，就像Hadoop处理批处理一样，它可以进行实时处理。Apache Storm很简单，可以与任何编程语言一起使用，而且使用起来很有趣!
Apache Storm有很多用例:实时分析、在线机器学习、连续计算、分布式RPC、ETL等等。Apache Storm速度很快:一个基准测试将它的速度控制在每秒处理每个节点超过100万个元组。它是可扩展的，容错，保证哟。

Storm的核心组件

• Nimbus：即Storm的Master，负责资源分配和任务调度。一个Storm集群只有一个Nimbus。
• Supervisor：即Storm的Slave，负责接收Nimbus分配的任务，管理所有Worker，一个Supervisor节点中包含多个Worker进程。
• Worker：工作进程，每个工作进程中都有多个Task。
• Task：任务，在 Storm 集群中每个 Spout 和 Bolt 都由若干个任务（tasks）来执行。每个任务都与一个执行线程相对应。
• Topology：计算拓扑，Storm 的拓扑是对实时计算应用逻辑的封装，它的作用与 MapReduce 的任务（Job）很相似，区别在于MapReduce 的一个 Job在得到结果之后总会结束，而拓扑会一直在集群中运行，直到你手动去终止它。拓扑还可以理解成由一系列通过数据流（StreamGrouping）相互关联的 Spout 和 Bolt 组成的的拓扑结构。
• Stream：数据流（Streams）是 Storm中最核心的抽象概念。一个数据流指的是在分布式环境中并行创建、处理的一组元组（tuple）的无界序列。数据流可以由一种能够表述数据流中元组的域（fields）的模式来定义。
• Spout：数据源（Spout）是拓扑中数据流的来源。一般 Spout会从一个外部的数据源读取元组然后将他们发送到拓扑中。根据需求的不同，Spout既可以定义为可靠的数据源，也可以定义为不可靠的数据源。一个可靠的Spout能够在它发送的元组处理失败时重新发送该元组，以确保所有的元组都能得到正确的处理；相对应的，不可靠的 Spout就不会在元组发送之后对元组进行任何其他的处理。一个 Spout可以发送多个数据流。
• Bolt：拓扑中所有的数据处理均是由 Bolt完成的。通过数据过滤（filtering）、函数处理（functions）、聚合（aggregations）、联结（joins）、数据库交互等功能，Bolt几乎能够完成任何一种数据处理需求。一个 Bolt 可以实现简单的数据流转换，而更复杂的数据流变换通常需要使用多个 Bolt并通过多个步骤完成。 Stream grouping：为拓扑中的每个 Bolt的确定输入数据流是定义一个拓扑的重要环节。数据流分组定义了在 Bolt 的不同任务（tasks）中划分数据流的方式。在 Storm中有八种内置的数据流分组方式。
• Reliability：可靠性。Storm 可以通过拓扑来确保每个发送的元组都能得到正确处理。通过跟踪由 Spout发出的每个元组构成的元组树可以确定元组是否已经完成处理。每个拓扑都有一个“消息延时”参数，如果 Storm在延时时间内没有检测到元组是否处理完成，就会将该元组标记为处理失败，并会在稍后重新发送该元组。

storm特征

• 官网 http://storm.apache.org/
• Storm是个实时的、分布式以及具备高容错的计算系统
  • Storm进程常驻内存
  • Storm数据不经过磁盘，在内存中处理
    
• 架构
  • Nimbus
  • Supervisor
  • Worker
• 编程模型
  • DAG （Topology）
  • Spout
  • Bolt
• 数据传输
  • ZMQ（twitter早期产品）：ZeroMQ 开源的消息传递框架，并不是一个MessageQueue
  • Netty：Netty是基于NIO的网络框架，更加高效。（之所以Storm 0.9版本之后使用Netty，是因为ZMQ的license和Storm的license不兼容。）
• 高可靠性
  - 异常处理
  - 消息可靠性保障机制(ACK)
• 可维护性
  • StormUI 图形化监控接口
• 流式处理
  • （异步 与 同步）客户端提交数据进行结算，并不会等待数据计算结果
  • 逐条处理:例：ETL（数据清洗）extracted transform load
  • 统计分析:例：
    • 计算PV、UV、访问热点 以及 某些数据的聚合、加和、平均等.
    • 客户端提交数据之后，计算完成结果存储到Redis、HBase、MySQL或者其他MQ当中，客户端并不关心最终结果是多少。
      
• 实时请求
  • 实时请求应答服务（同步）
  • Drpc
  • 实时请求处理
    例：图片特征提取
    

Storm 架构设计与Hadoop架构对比

storm与MapReduce区别

• Storm：进程、线程常驻内存运行，数据不进入磁盘，数据通过网络传递。
• MapReduce：为TB、PB级别数据设计的批处理计算框架。
  

storm与Spark Streaming区别

• Storm：纯流式处理

  • 专门为流式处理设计
  • 数据传输模式更为简单，很多地方也更为高效
  • 并不是不能做批处理，它也可以来做微批处理，来提高吞

• Spark Streaming：微批处理

  • 将RDD做的很小来用小的批处理来接近流式处理
  • 基于内存和DAG可以把处理任务做的很快

Storm计算模式

Storm程序再Storm集群中运行的示例图如下:

Topology - DAG有向无环图的实现

• 对于Storm实时计算逻辑的封装
• 即，由一系列通过数据流相互关联的Spout、Bolt所组成的拓扑结构
• 生命周期：此拓扑只要启动就会一直在集群中运行，直到手动将其kill，否则不会终止（区别于MapReduce当中的Job，MR当中的Job在计算执行完成就会终止）

具体流程是怎么走，可以通过查看下面这张图来进行了解。
示例图:

图片有三种模式，解释如下:
第一种比较简单，就是由一个Spout获取数据，然后交给一个Bolt进行处理;
第二种稍微复杂点，由一个Spout获取数据，然后交给一个Bolt进行处理一部分，然后在交给下一个Bolt进行处理其他部分。
第三种则比较复杂，一个Spout可以同时发送数据到多个Bolt，而一个Bolt也可以接受多个Spout或多个Bolt，最终形成多个数据流。但是这种数据流必须是有方向的，有起点和终点，不然会造成死循环，数据永远也处理不完。就是Spout发给Bolt1，Bolt1发给Bolt2，Bolt2又发给了Bolt1,最终形成了一个环状。

• Tuple – 元组

  • Stream中最小数据组成单元

• Stream – 数据流

  • 从Spout中源源不断传递数据给Bolt、以及上一个Bolt传递数据给下一个Bolt，所形成的这些数据通道即叫做Stream
  • Stream声明时需给其指定一个Id（默认为Default）
  • 实际开发场景中，多使用单一数据流，此时不需要单独指定StreamId
    

• Spout – 数据源

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

• Bolt – 数据流处理组件

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

• Stream Grouping – 数据流分组（即数据分发策略）
  

Storm 任务提交流程

Storm 本地目录树

Storm Zookeeper目录树