Flink和Storm之间的主要区别是什么？

Question

Flink是compared to Spark，在我看来，这是错误的比较，因为它将窗口事件处理系统与微批处理进行了比较；同样，将Flink与Samza进行比较对我来说也没有太大意义。在这两种情况下，它都会比较实时事件和批处理事件处理策略，即使在Samza情况下，即使规模较小。但是我想知道Flink与Storm的比较，Storm在概念上似乎与它更相似。

我发现this（幻灯片4）将主要区别记录为Flink的“可调延迟”。另一个提示似乎是Slicon Angle的一篇文章，暗示Flink可以更好地集成到Spark或HadoopMR世界中，但是没有提及或引用任何实际细节。最后，Fabian Hueske亲自指出in an interview：“与Apache Storm相比，Flink的流分析功能提供了高级API，并使用了更轻量级的容错策略来提供一次精确的处理保证。”

这对我来说有点稀疏，我不太明白这一点。有人可以解释一下Flink完全解决了Storm中流处理的哪些问题吗？ API问题及其“更轻量级的容错策略”指的是Hueske指的是什么？

Answer 1

Disclaimer：我是Apache Flink提交者和PMC成员，并且仅熟悉Storm的高级设计，而不是其内部。

Apache Flink是用于统一流和批处理的框架。由于并行任务之间的管道数据传输（包括管道随机播放），Flink的运行时本机支持两个域。记录从生产任务立即发送到接收任务（在收集到网络传输的缓冲区中之后）。批处理作业可以选择使用阻止数据传输来执行。

Apache Spark是一个还支持批处理和流处理的框架。 Flink的批处理API看起来非常相似，并且解决了与Spark类似的用例，但是内部结构有所不同。对于流传输，两个系统都采用非常不同的方法（迷你批处理与流传输），这使它们适用于不同类型的应用程序。我会说比较Spark和Flink是有效和有用的，但是，Spark不是与Flink最相似的流处理引擎。

来到最初的问题，Apache Storm是一个没有批处理功能的数据流处理器。实际上，Flink的流水线引擎在内部看起来有点类似于Storm，即Flink并行任务的接口类似于Storm的螺栓。 Storm和Flink的共同点在于，它们旨在通过流水线式数据传输来实现低延迟流处理。但是，与Storm相比，Flink提供了更高级的API。 Flink的DataStream API并未提供具有一个或多个阅读器和收集器的螺栓功能，而是提供了诸如Map，GroupBy，Window和Join之类的功能。使用Storm时，必须手动实现许多此功能。另一个区别是处理语义。 Storm保证了至少一次处理，而Flink提供了一次。提供这些处理保证的实现方式相差很多。尽管Storm使用记录级确认，但是Flink使用Chandy-Lamport算法的变体。简而言之，数据源会定期将标记插入到数据流中。每当操作员收到此类标记时，它都会检查其内部状态。当所有数据接收器都收到一个标记时，该标记（以及之前已处理的所有记录）都将被提交。如果发生故障，当所有源操作员看到最后提交的标记时，它们将重置为其状态，并继续进行处理。这种标记检查点方法比Storm的记录级确认更轻便。 slide set和相应的talk讨论了Flink的流处理方法，包括容错，检查点和状态处理。

Storm还提供了一次仅称为Trident的高级API。但是，Trident是基于迷你批处理的，因此与Flink相比更类似于Spark。

Flink的可调延迟是指Flink将记录从一个任务发送到另一任务的方式。我之前说过，Flink使用流水线数据传输并在产生记录后立即转发记录。为了提高效率，这些记录收集在一个缓冲区中，一旦缓冲区满或达到某个时间阈值，该缓冲区就会通过网络发送。此阈值控制记录的延迟，因为它指定了记录将保留在缓冲区中而不发送到下一个任务的最长时间。但是，它不能用来为记录从进入到离开程序所花费的时间提供严格的保证，因为这还取决于任务中的处理时间以及网络传输的数量。

Answer 2

添加到Fabian Hueske的答案中：

Flink还通过以下方式对Storm进行了改进：

• 背压：当不同的运营商以不同的速度运行时，Flink的流运行时表现良好，因为尽管网络层管理缓冲池，但下游运营商对上游运营商的背压却非常好。

• 用户定义状态：Flink允许程序在您的操作员中维护自定义状态。该状态实际上可以参与容错性的检查点，从而为自定义用户定义状态提供一次精确的保证。请参见操作员内部用户定义的状态机的this example，该状态机与数据流一起被一致检查点。

• Streaming Windows：流窗口和窗口聚合是分析数据流的关键构建块。 Flink带有一个功能强大的窗口系统，该系统支持多种类型的窗口。

Answer 3

根据我对Storm和Flink的经验。我觉得这些工具可以用不同的方法解决相同的问题。 @Stephan Ewen提到的Flink的每个功能都可以通过Storm与内部API（即spolts和bolts）和Trident API进行匹配。有人声称Trident是微型批处理样式，而我认为大多数与状态相关或聚合的复杂应用程序只能依赖于具有窗口样式的批处理。因此，我只是在这里列出一些主要区别，而没有说哪个更好。

• 开发风格。在Flink中面向计算（例如，可链接运算符）与在Storm中面向数据流（例如addSpolt()/addBolt()）。
• 高级API。 Flink与本机窗口以及Storm中的Trident中的功能（例如，地图，窗口，流式连接中的联接）。
• 保证消息处理（GMP，即一次精确地一次）]。在Flink中带有两阶段提交连接器（例如，KafkaConsumer）的检查点与在外部状态机或Storm中的Trident中的元组树。
• 容错。 Flink中的标记检查点与Storm中的记录级别ACK。
• 内部架构。 Flink中的简单抽象和相对并行度（例如，与CPU内核一起考虑的每个线程的插槽）与Storm中的多层抽象（例如，每个JVM在主管中的工人的插槽，每个主管可以有很多工人）。

Answer 4

免责声明：我是Cloudera的雇员，Cloudera是Storm和（很快）Flink的主要支持者。

功能

已经提出了许多好的技术要点。重点摘要非常简短：

• Flink和Storm都可以执行每个事件的处理
• 风暴似乎不支持事件时间开箱即用
• 暴风雨还没有使SQL支持脱离实验阶段

非功能

• [许多客户发现Storm（太）难以使用
• 风暴的采用速度放慢了，现在Flink社区似乎比Storm更活跃
• Flink仍有一些工作要做（例如，已记录的示例），但总的来说，它已经在您可能想到的几乎每个领域都迎头赶上了

结论

Cloudera最近宣布弃用Storm（在HDP中）。同时，Flink被宣布为其继任者。

因此，如果您遇到了很多用例，它们当然将继续起作用。但是对于新的用例，我会研究Flink或其他流引擎。