Storm介绍及与Spark Streaming对比

Cooker 大资料

大 数 据

专注于前沿大资料案例资讯

1 Storm介绍

Storm是由Twitter开源的分散式、高容错的实时处理系统，它的出现令持续不断的流计算变得容易，弥补了Hadoop批处理所不能满足的实时要求。Storm常用于在实时分析、线上机器学习、持续计算、分散式远端呼叫和ETL等领域。

在Storm的丛集里面有两种节点：控制节点(Master Node)和工作节点(Worker Node)。控制节点上面执行一个名为Nimbus的程序,它用于资源分配和状态监控；每个工作节点上面执行一个Supervisor的程序，它会监听分配给它所在机器的工作，根据需要启动/关闭工作程序。Storm丛集架构如下图所示：

图 1 Storm丛集架构

Storm丛集中每个元件具体描述如下：

l Nimbus：负责在丛集里面传送程式码，分配工作给机器并且监控状态，在丛集中只有一个，作用类似Hadoop里面的JobTracker。

l ZooKeeper：Storm重点依赖的外部资源，Nimbus、Supervisor和Worker等都是把心跳资料储存在ZooKeeper上，Nimbus也是根据ZooKeeper上的心跳和任务执行状况进行排程和任务分配的。

l Supervisor：在执行节点上，监听分配的任务，根据需要启动或关闭工作程序Worker。每一个要执行Storm的机器上都执行一个Supervisor，并且按照机器的配置设定上面分配的槽位数。

l Worker：在Supervisor上建立的一个JVM例项，Worker中执行Executor，而Executor作为Task执行的容器。

l Executor：执行时Task所在的直接容器，在Executor中执行Task的处理逻辑。一个或多个Executor例项可以执行在同一个Worker程序中，一个或多个Task可以运行于同一个Executor中；在Worker程序并行的基础上，Executor可以并行，进而Task也能够基于Executor实现平行计算

l Task：Spout/Bolt在执行时所表现出来的实体，都称为Task，一个Spout/Bolt在执行时可能对应一个或多个Spout Task或Bolt Task，与实际在编写Topology时进行配置有关。在Storm0.8之后，Task不再与物理执行绪对应，同一个Spout Task或Bolt Task可能会共享一个物理执行绪，该执行绪称为Executor。

Storm提交执行的程式称为Topology，它处理的最小的讯息单位是一个Tuple，也就是一个任意物件的阵列。Topology由Spout和Bolt构成，Spout是发出Tuple的结点，Bolt可以随意订阅某个Spout或者Bolt发出的Tuple。下图是一个Topology设计的逻辑图的例子:

图 2 Topology设计的逻辑图

l Topology： Topology概念类似于Hadoop中的MapReduce作业，是一个用来编排、容纳一组计算逻辑元件（Spout、Bolt）的物件（Hadoop MapReduce中一个作业包含一组Map任务、Reduce任务），这一组计算元件可以按照DAG图的方式编排起来（通过选择Stream Groupings来控制资料流分发流向），从而组合成一个计算逻辑更加负责的物件，那就是Topology。一个Topology执行以后就不能停止，它会无限地执行下去，除非手动干预（显式执行bin/storm kill）或意外故障（如停机、整个Storm丛集挂掉）让它终止。

l Spout： Spout是一个Topology的讯息生产的源头，Spout是一个持续不断生产讯息的元件，例如，它可以是一个Socket Server在监听外部Client连线并发送讯息、可以是一个讯息伫列（MQ）的消费者、可以是用来接收Flume Agent的Sink所传送讯息的服务，等等。Spout生产的讯息在Storm中被抽象为Tuple，在整个Topology的多个计算元件之间都是根据需要抽象构建的Tuple讯息来进行连线，从而形成流。

l Bolt：Storm中讯息的处理逻辑被封装到Bolt元件中，任何处理逻辑都可以在Bolt里面执行，处理过程和普通计算应用程序没什么区别，只是需要根据Storm的计算语义来合理设定一下元件之间讯息流的宣告、分发和连线即可。Bolt可以接收来自一个或多个Spout的Tuple讯息，也可以来自多个其它Bolt的Tuple讯息，也可能是Spout和其它Bolt组合传送的Tuple讯息。

l Stream Grouping：Storm中用来定义各个计算元件（Spout和Bolt）之间流的连线、分组和分发关系。Storm定义了如下7种分发策略：Shuffle Grouping（随机分组）、Fields Grouping（按字段分组）、All Grouping（广播分组）、Global Grouping（全域性分组）、Non Grouping（不分组）、Direct Grouping（直接分组）、Local or Shuffle Grouping（本地/随机分组），各种策略的具体含义可以参考Storm官方文件、比较容易理解。

在Storm中可以通过元件简单序列或者组合多种流操作处理资料：

l Storm元件简单序列

这种方式是最简单最直观的，只要我们将Storm的元件（Spout或Bolt）序列起来即可实现，只需要了解编写这些元件的基本方法即可。在实际应用中，如果我们需要从某一个数据源连续地接收讯息，然后顺序地处理每一个请求，就可以使用这种序列方式来处理。如果说处理单元的逻辑非常复杂，那么就需要处理逻辑进行分离，属于同一类操作的逻辑封装到一个处理元件中，做到各个元件之间弱耦合。

图 3 Storm元件简单序列

l Storm组合多种流操作

Storm支援流聚合操作，将多个元件的资料汇聚到同一个处理元件来统一处理，可以实现对多个Spout元件通过流聚合到一个Bolt元件（Sout到Bolt的多对一、多对多操作），也可以实现对多个Bolt通过流聚合到另一个Bolt元件（Bolt到Bolt的多对一、多对多操作）。

图 4 Storm组合多种流操作

下图是Topology的提交流程图：

图 5 Topology的提交流程图

1. 客户端通过Nimbus的界面上传程式jar包到Nimbus的Inbox目录中，上传结束后，通过提交方法向Nimbus提交一个Topology。

2. Nimbus接收到提交Topology的命令后，对接收到的程式jar包进行序列化，把序列化的结果放到Nimbus节点的stormdist目录中，同时把当前Storm执行的配置生成一个stormconf.ser档案也放到该目录中。静态的资讯设定完成后，通过心跳资讯分配任务到机器节点。在设定Topology所关联的Spouts和Bolts时，可以同时设定当前Spout和Bolt的Executor数目和Task数目，预设情况下，一个Topology的Task的总和与Executor的总和一致。之后，系统根据Worker的数目，尽量平均的分配这些Task的执行。其中Worker在哪个Supervisor节点上执行是由Storm本身决定的。

3. 任务分配好之后，Nimbus节点会将任务的资讯提交到ZooKeeper丛集，同时在ZooKeeper丛集中会有Worker分派节点，这里储存了当前Topology的所有Worker程序的心跳资讯。

4. Supervisor节点会不断的轮询ZooKeeper丛集，在ZooKeeper的分派节点中储存了所有Topology的任务分配资讯、程式码储存目录和任务之间的关联关系等，Supervisor通过轮询此节点的内容，来领取自己的任务，启动Worker程序执行。

5. 一个Topology执行之后，就会不断的通过Spout来发送Stream流，通过Bolt来不断的处理接收到的资料流。

2 Spark Streaming与Storm比较

Storm和Spark Streaming都是分散式流处理的开源框架，但是它们之间还是有一些区别的，这里将进行比较并指出它们的重要的区别。

1. 处理模型以及延迟

虽然这两个框架都提供可扩充套件性(Scalability)和可容错性(Fault Tolerance),但是它们的处理模型从根本上说是不一样的。Storm处理的是每次传入的一个事件，而Spark Streaming是处理某个时间段视窗内的事件流。因此，Storm处理一个事件可以达到亚秒级的延迟，而Spark Streaming则有秒级的延迟。

2. 容错和资料保证

在容错资料保证方面的权衡方面，Spark Streaming提供了更好的支援容错状态计算。在Storm中，当每条单独的记录通过系统时必须被跟踪，所以Storm能够至少保证每条记录将被处理一次，但是在从错误中恢复过来时候允许出现重复记录，这意味着可变状态可能不正确地被更新两次。而Spark Streaming只需要在批处理级别对记录进行跟踪处理，因此可以有效地保证每条记录将完全被处理一次，即便一个节点发生故障。虽然Storm的 Trident library库也提供了完全一次处理的功能。但是它依赖于事务更新状态，而这个过程是很慢的，并且通常必须由使用者实现。

简而言之,如果你需要亚秒级的延迟，Storm是一个不错的选择，而且没有资料丢失。如果你需要有状态的计算，而且要完全保证每个事件只被处理一次，Spark Streaming则更好。Spark Streaming程式设计逻辑也可能更容易，因为它类似于批处理程式，特别是在你使用批次(尽管是很小的)时。

3. 实现和程式设计API

Storm主要是由Clojure语言实现，Spark Streaming是由Scala实现。如果你想看看这两个框架是如何实现的或者你想自定义一些东西你就得记住这一点。Storm是由BackType和 Twitter开发，而Spark Streaming是在UC Berkeley开发的。

Storm提供了Java API，同时也支援其他语言的API。 Spark Streaming支援Scala和Java语言(其实也支援Python)。另外Spark Streaming的一个很棒的特性就是它是在Spark框架上执行的。这样你就可以想使用其他批处理程式码一样来写Spark Streaming程式，或者是在Spark中互动查询。这就减少了单独编写流批量处理程式和历史资料处理程式。

4. 生产支援

Storm已经出现好多年了，而且自从2011年开始就在Twitter内部生产环境中使用，还有其他一些公司。而Spark Streaming是一个新的专案，并且在2013年仅仅被Sharethrough使用(据作者了解)。

Storm是 Hortonworks Hadoop资料平台中流处理的解决方案，而Spark Streaming出现在 MapR的分散式平台和Cloudera的企业资料平台中。除此之外，Databricks是为Spark提供技术支援的公司，包括了Spark Streaming。

5. 丛集管理整合

尽管两个系统都执行在它们自己的丛集上，Storm也能执行在Mesos，而Spark Streaming能执行在YARN 和 Mesos上。