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

Question

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

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

对我来说，这一切都有点稀疏，我不太清楚。 有人可以通过Flink解释Storm中的流处理是什么问题（？？）？什么是Hueske所指的API问题及其“更轻量级的容错策略”？

Answer 1

免责声明：我是Apache Flink提交者和PMC成员，只熟悉Storm的高级设计，而不是内部设计。

Apache Flink是统一流和批处理的框架。由于并行任务之间的流水线数据传输（包括流水线shuffle），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时必须手动实现许多此功能。另一个区别是处理语义。风暴保证至少一次处理，而Flink只提供一次。给出这些处理保证的实现有很大不同。虽然Storm使用记录级别的确认，但Flink使用了Chandy-Lamport算法的变体。简而言之，数据源会定期将标记注入数据流。每当操作员接收到这样的标记时，它就会检查其内部状态。当所有数据接收器都接收到标记时，将提交标记（以及之前已处理的所有记录）。如果发生故障，所有源操作员在看到最后一个提交的标记并且继续处理时将重置为其状态。这种标记检查点方法比Storm的记录级确认更轻量级。这个slide set和相应的talk讨论了Flink的流处理方法，包括容错，检查点和状态处理。

Storm还提供了一个名为Trident的一次性高级API。然而，Trident基于迷你批次，因此更像Spark而不是Flink。

Flink的可调延迟是指Flink将记录从一个任务发送到另一个任务的方式。我之前说过，Flink使用流水线数据传输并在生成后立即转发记录。为了提高效率，这些记录被收集在一个缓冲区中，该缓冲区在满载或满足特定时间阈值时通过网络发送。此阈值控制记录的延迟，因为它指定记录在未发送到下一个任务的情况下保留在缓冲区中的最长时间。但是，它不能用于确保记录从进入程序到离开程序所需的时间，因为这还取决于任务中的处理时间和网络传输的数量等。

Answer 2

补充Fabian Hueske的答案：

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

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

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

• 流式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或其他流引擎。