背景

目前在开源市场上已经有了多款实时流式大数据的处理工具，最值得关注的还属Storm与Spark Streaming。这两套方案都归属于Apache基金会。这两种技术的核心区别在于它们处理数据的方式。Storm 并行化任务计算，而 Spark Streaming是Spark上的一个流式处理框架。两款工具在功能方面有一部分交集，但也各自拥有着不同的特性与市场定位。

Apache Storm

介绍

Storm是由Twitter开源的分布式、高容错的实时处理系统，它的出现令持续不断的流计算变得容易，弥补了Hadoop批处理所不能满足的实时要求。Storm常用于在实时分析、在线机器学习、持续计算、分布式远程调用和ETL等领域。利用Storm可以很容易做到可靠地处理无限的数据流，像Hadoop批量处理大数据一样，Storm可以实时处理数据。Storm简单，可以使用任何编程语言。

特点

Storm有如下特点：

编程简单：开发人员只需要关注应用逻辑，而且跟Hadoop类似，Storm提供的编程原语也很简单高性能，低延迟：可以应用于广告搜索引擎这种要求对广告主的操作进行实时响应的场景。分布式：可以轻松应对数据量大，单机搞不定的场景可扩展：随着业务发展，数据量和计算量越来越大，系统可水平扩展容错：单个节点挂了不影响应用消息不丢失：保证消息处理

Storm概念

拓扑(Topologies)：storm分布式计算结构称为topology(拓扑)由stream,spout,bolt组成。spout代表一个storm拓扑中的数据入口，连接到数据源，将数据转化为一个个tuple，并发射tuple ，stream是由无限制个tuple组成的序列。tuple为storm的核心数据结构，是包含了一个或多个键值对的列表。

Tuple(元组)：元组是Storm提供的一个轻量级的数据格式，可以用来包装你需要实际处理的数据。元组是一次消息传递的基本单元。一个元组是一个命名的值列表，其中的每个值都可以是任意类型的。元组是动态地进行类型转化的--字段的类型不需要事先声明。在Storm中编程时，就是在操作和转换由元组组成的流。通常，元组包含整数，字节，字符串，浮点数，布尔值和字节数组等类型。要想在元组中使用自定义类型，就需要实现自己的序列化方式。

Streams（消息流）：流是Storm中的核心抽象。一个流由无限的元组序列组成，消息流是一个没有边界的tuple序列，而这些tuples会被以一种分布式的方式并行创建和处理。每个tuple可以包含多列，字段类型可以是：integer, long, short, byte, string, double, float, boolean和byte array。你还可以自定义类型 — 只要你实现对应的序列化器。

Spouts（消息源）：Spouts是topology消息生产者。Spout从一个外部源(消息队列)读取数据向topology发出tuple。消息源Spouts可以是可靠的也可以是不可靠的。一个可靠的消息源可以重新发射一个处理失败的tuple， 一个不可靠的消息源Spouts不会。Spout类的方法nextTuple不断发射tuple到topology，storm在检测到一个tuple被整个topology成功处理的时候调用ack, 否则调用fail。 storm只对可靠的spout调用ack和fail。

Bolts（消息处理者）：消息处理逻辑被封装在bolts里面，Bolts可以做很多事情：过滤， 聚合， 查询数据库等。Bolts可以简单的做消息流的传递。复杂的消息流处理往往需要很多步骤， 从而也就需要经过很多Bolts。第一级Bolt的输出可以作为下一级Bolt的输入。而Spout不能有一级。 Bolts的主要方法是execute（死循环）连续处理传入的tuple，成功处理完每一个tuple调用OutputCollector的ack方法，以通知storm这个tuple被处理完成了。当处理失败时，可以调fail方法通知Spout端可以重新发送该tuple。

Tasks（任务）：每个Spout和Bolt会以多个任务(Task)的形式在集群上运行。每个任务对应一个执行线程，流分组定义了如何从一组任务(同一个Bolt)发送元组到另外一组任务(另外一个Bolt)上。

Component（组件）：组件(component)是对Bolt和Spout的统称

Stream Grouping(流分组）：定义拓扑的时候，一部分工作是指定每个Bolt应该消费哪些流。流分组定义了一个流在一个消费它的Bolt内的多个任务(task)之间如何分组。流分组跟计算机网络中的路由功能是类似的，决定了每个元组在拓扑中的处理路线。策略包含Shuffle grouping（随机分组）、Fields grouping（按字段分组）、All grouping（全复制分组）、Globle grouping（全局分组）、None grouping（不分组）、Direct grouping（指向型分组）、Local or shuffle grouping（本地或随机分组）。

Reliability(可靠性)：Storm保证了拓扑中Spout产生的每个元组都会被处理。Storm是通过跟踪每个Spout所产生的所有元组构成的树形结构并得知这棵树何时被完整地处理来达到可靠性。每个拓扑对这些树形结构都有一个关联的“消息超时”。如果在这个超时时间里Storm检测到Spout产生的一个元组没有被成功处理完，那Sput的这个元组就处理失败了，后续会重新处理一遍。

Workers(工作进程)：拓扑以一个或多个Worker进程的方式运行。每个Worker进程是一个物理的Java虚拟机，执行拓扑的一部分任务。例如，如果拓扑的并发设置成了300，分配了50个Worker，那么每个Worker执行6个任务(作为Worker内部的线程）。Storm会尽量把所有的任务均分到所有的Worker上。

Storm模型

Storm实现了一个数据流(data flow)的模型，在这个模型中数据持续不断地流经一个由很多转换实体构成的网络。一个数据流的抽象叫做流(stream)，流是无限的元组(Tuple)序列。元组就像一个可以表示标准数据类型（例如int，float和byte数组）和用户自定义类型（需要额外序列化代码的）的数据结构。每个流由一个唯一的ID来标示的，这个ID可以用来构建拓扑中各个组件的数据源。在Storm中，设计的实时计算图称为toplogy，将其以集群方式运行，其主节点会在工作节点之间分发代码并执行，在一个topology中，数据是在spout之间传递，它发射数据流作为不可变的key-value匹配集合，这种key-value配对值称为tuple，bolt是用来转换这些流如count计数或filter过滤等，bolt它们自己也可选择发射数据到其它流处理管道下游的bolt。

Spark Streaming

介绍

Spark Streaming 是 Spark 核心 API 的一个扩展，可以实现高吞吐量的、具备容错机制的实时流数据的处理。核心思想是把流式处理转化为“微批处理”，即以时间为单位切分数据流，每个切片内的数据对应一个RDD，进而采用Spark引擎进行快速计算。正是由于Spark Streaming采用了微批处理方式，因此只能将其作为近实时处理系统，而不是严格意义上的实时流式处理。Spark Streaming 对流式数据做了进一步抽象，它将流式数据批处理化，每一批数据被抽象成RDD，这样流式数据变成了流式的RDD序列，这便是Dstream，Spark Streaming 在Dstream上定义了一系列操作，主要分两类：transformation和output，其中一个transformation操作能够将一个Dstream变换成另一个Dstream，而output操作可产生一个或一组结果，并将输出到指定外部系统中。SparkStreaming类似于ApacheStorm，用于流式数据的处理。根据官方文档介绍，Spark Streaming有高吞吐量和容错能力强等特点。SparkSteaming支持的数据输入源很多，例如Kafka、Flume、Twitter、ZeroMQ和简单的TCP套接字等等。数据输入后可以用Spark的高度抽象源语如：map、reduce、join、window等进行运算。而结果也能保存在很多地方，如HDFS，数据库等。另外SparkStreaming也能和MLib（机器学习）以及Graphx完美融合。

特点

易用性：Spark Streaming支持Java、Python、Scala等编程语言，可以像编写离线程序一样编写实时计算的程序。

容错性:Spark Streaming在没有额外代码和配置的情况下，可以恢复丢失的数据。对于实时计算来说，容错性至关重要。首先要明确一下Spak中RDD的容错机制，即每一个RDD都是个不可变的分布式可重算的数据集，它记录着确定性的操作继承关系(lineage)，所以只要输入数据是可容错的，那么任意一个RDD的分区(Partition)出错或不可用，都可以使用原始输入数据经过转换操作重新计算得到。

易整合性:Spark Streaming可以在Spark上运行，并且还允许重复使用相同的代码进行批处理。也就是说，实时处理可以与离线处理相结合，实现交互式的查询操作。

概念

离散流（DStream）：这是Spark Streaming对内部持续的实时数据流的抽象描述，即我们处理的一个实时数据流，在Spark Streaming中对应于一个DStream 实例。

批数据（batch data）：这是化整为零的第一步，将实时流数据以时间片为单位进行分批，将流处理转化为时间片数据的批处理。随着持续时间的推移，这些处理结果就形成了对应的结果数据流了。

时间片或批处理时间间隔（ batch interval）：这是人为地对流数据进行定量的标准，以时间片作为我们拆分流数据的依据。一个时间片的数据对应一个RDD实例。

窗口长度（window length）：一个窗口覆盖的流数据的时间长度。必须是批处理时间间隔的倍数

滑动时间间隔：前一个窗口到后一个窗口所经过的时间长度。必须是批处理时间间隔的倍数，默认同批处理时间间隔

Input DStream :一个input DStream是一个特殊的DStream，将Spark Streaming连接到一个外部数据源来读取数据。

模型

Spark Streaming是核心Spark的一个拓展，并不是像Storm一次处理流，而是将它们分成片段，变成小批量时间间隔处理，Spark抽象一个持续的数据流称为DStream(离散流)，一个DStream是RDD(弹性分布式数据集的简称)的微批次 micro-batch，RDD是分布式集合能够并行地被任何函数操作，也可以通过一个滑动窗口的数据(窗口计算)进行变换。

总结

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

处理模型以及延迟

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

容错和数据保证

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

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

实现和编程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中交互查询。这就减少了单独编写流批量处理程序和历史数据处理程序。

生产支持

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

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

集群管理集成

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

​

推荐阅读

Apache hive vs. impala 大数据生态系统中的SQL分析引擎之争

HTTP vs. MQTT 物联网通信协议对比

Cassandra vs. HBase 列式数据库对比

Spring Cloud vs. Apache Dubbo 微服务框架对比