1.4　流计算框架对比

当前大数据领域主流的流式计算框架有Apache Storm、Spark Streaming、Apache Flink三种。通常将Apache Storm称为第一代流式计算框架，Spark Streaming称为第二代流式计算框架，现在又出现了一种优秀的第三代实时计算框架Apache Flink，这三种计算框架的区别如表1-1所示。

1．模型

Native：原生流处理。指输入的数据一旦到达，就立即进行处理，一次处理一条数据，如图1-7所示。

Micro-Batching：微批流处理。把输入的数据按照预先定义的时间间隔（例如1秒钟）分成短小的批量数据，流经流处理系统进行处理，如图1-8所示。

Storm和Flink使用的是原生流处理，一次处理一条数据，是真正意义的流处理；而Spark Streaming实际上是通过批处理的方式模拟流处理，一次处理一批数据（小批量）。

2．API

Storm只提供了组合式的基础API，而Spark Streaming和Flink都提供了封装后的高阶函数，例如map()、filter()，以及一些窗口函数、聚合函数等，使用这些函数可以轻松处理复杂的数据，构建并行应用程序。

3．处理次数

在流处理系统中，对数据的处理有3种级别的语义：At-Most-Once（最多一次）、At-Least-Once（至少一次）、Exactly-Once（仅一次）。

·　At-Most-Once：每条数据最多被处理一次，会有丢失数据的可能。

·　At-Least-Once：每条数据至少被处理一次，保证数据不会丢失，但数据可能会被重复处理。

·　Exactly-Once：每条数据仅被处理一次，不会丢失数据，也不会重复处理。

由此可见，衡量一个流处理系统能力的关键是Exactly-Once。

Storm实现了At-Least-Once，可以对数据至少处理一次，但不能保证仅处理一次，这样就会导致数据重复处理的问题，因此针对计数类的需求可能会产生一些误差；Spark Streaming和Flink都实现了Exactly-Once，可以保证对数据仅处理一次，即每个记录将被精确处理一次，数据不会丢失，并且不会重复处理。

4．容错

由于流处理系统的许多作业都是7×24小时运行的，不断有输入的数据，因此容错性比批处理系统更难实现。一旦因为网络等原因导致节点宕机，流处理系统应该具备从这种失败中快速恢复的能力，并从上一个成功的状态重新处理。

Storm通过使用ACK（确认回执，即数据接收方接收到数据后要向发送方发送确认回执，以此来保证数据不丢失）机制来确认每一条数据是否被成功处理，当处理失败时，则重新发送数据。这样很容易做到保证所有数据均被处理，没有遗漏，但这种方式不能保证数据仅被处理一次，因此存在同一条数据重复处理的情况。

由于Spark Streaming是微批处理，不是真正意义上的流处理，其容错机制的实现相对简单。Spark Streaming中的每一批数据成为一个RDD（Resilient Distributed Dataset，分布式数据集）。RDD Checkpoint（检查点）机制相当于对RDD数据进行快照，可以将经常使用的RDD快照到指定的文件系统中，例如HDFS。当机器发生故障导致内存或磁盘中的RDD数据丢失时，可以快速从快照中对指定的RDD进行恢复。

Flink的容错机制是基于分布式快照实现的，通过CheckPoint机制保存流处理作业某些时刻的状态，当任务异常结束时，默认从最近一次保存的完整快照处恢复任务。关于Flink的Checkpoint机制，在4.13.1节将详细讲解。

5．状态

流处理系统的状态管理是非常重要的，Storm没有实现状态管理，Spark Streaming和Flink都实现了状态管理。通过状态管理可以把程序运行中某一时刻的数据结果保存起来，以便于后续的计算和故障的恢复。

6．延迟

由于Storm和Flink是接收到一条数据就立即处理，因此数据处理的延迟很低；而Spark Streaming是微批处理，需要形成一小批数据才会处理，数据处理的延迟相对偏高。

7．吞吐量

Storm的吞吐量相对来说较低，Spark Streaming和Flink的吞吐量则比较高。较高的吞吐量可以提高资源利用率，减小系统开销。

总的来说，Storm非常适合任务量小且延迟要求低的应用，但要注意Storm的容错恢复和状态管理都会降低整体的性能水平。如果你要使用Lambda架构，并且要集成Spark的各种库，那么Spark Streaming是一个不错的选择，但是要注意微批处理的局限性以及延迟问题。Flink可以满足绝大多数流处理场景，提供了丰富的高阶函数，并且也针对批处理场景提供了相应的API，是非常有前景的一个项目。