流式计算引擎对比

基于行的 Storm 和基于微批处理的 Spark Streaming。我们将从编程模型、一致性语义、编程语言、吞吐率与延迟等方面进行对比。

1、编程模型

Storm 采用了 Tuple 数据模型，并在此基础上实现了 Spout/Bolt 编程模型，用户可实现任意多个的 Bolt 完成计算。Spark Streaming 则构建在 Spark core 之上，将流式数据进一步抽象成 DStream，允许用户重用 RDD API 的同时引入了更丰富的编程接口，比如窗口函数、状态管理函数等。相比于 Storm, Spark Streaming 编程模型的灵活性更高，用户编写程序更加简便。

2、一致性语义

一致性语义是指相同数据被传递或处理的次数，它可划分为以下三种：

• at most once：即至多被处理一次，这意味着数据可能有丢失，一般不会在生产环境中使用。

• at least once：即至少被处理一次，这意味着数据可能被处理多次，这是最常用的一致性语义，其实现开销最小，但用户需要在业务逻辑层处理好重复数据。

• exactly once：即正好被处理一次，这是最理想的情况，但由于真实环境中服务故障、网络超时等问题的存在，实现一个通用的支持“exactly once”的系统是非常困难的。

Storm 基于 acker 框架实现了“at least once”一致性语义；而 Spark Streaming 采用了批处理方式处理数据，在不考虑失败重试和推测执行情况下，能够实现“exactly once”一致性语义。但由于实际生产环境中，总存在故障重试问题，所以“Kafka + Spark Streaming”架构本身无法保证“exactly once”，不过，用户可在实现逻辑中保证函数具有幂等性来达到这一目标。

3、编程语言

Storm 借助 Thrift 能够很容易地支持主流语言的程序设计，包括 Java、Python、C++、PHP 等，而 Spark Streaming 目前仅支持 Scala、Java、Python 和 R 四种语言。

4、吞吐率与延迟

吞吐率和延迟是一对此消彼长的指标，一般而言，一个系统具有很高的吞吐率，则意味着它的数据处理延迟也很高，反之亦然。Storm 选择了低延迟作为首要目标，它能做到毫秒级延迟，但吞吐率很低，而 Spark Streaming 正好相反，它的吞吐率是 Storm 几倍甚至几十倍，但数据处理延迟最低只能做到秒级。