Apache storm Flink和Storm的主要区别是什么？

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

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

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

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

ApacheFlink是一个用于统一流和批处理的框架。Flink的运行时本机支持这两个域，因为并行任务之间的流水线数据传输包括流水线洗牌。记录会立即从生产任务发送到接收任务（在缓冲区中收集以进行网络传输之后）。可以选择使用阻塞数据传输来执行批处理作业

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

说到最初的问题，ApacheStorm是一个没有批处理功能的数据流处理器。事实上，Flink的流水线引擎内部看起来有点类似于Storm，即Flink的并行任务的接口类似于Storm的螺栓。Storm和Flink的共同点是，他们的目标是通过流水线数据传输实现低延迟流处理。然而，与Storm相比，Flink提供了更高级的API。Flink的DataStream API提供了Map、GroupBy、Window和Join等函数，而不是通过一个或多个读卡器和采集器实现Bolt的功能。在使用Storm时，许多此功能必须手动实现。另一个区别是处理语义。Storm保证至少处理一次，而Flink只提供一次。提供这些处理保证的实现差别很大。Storm使用记录级别的确认，而Flink使用Chandy Lamport算法的变体。简言之，数据源定期向数据流中注入标记。每当操作员收到这样的标记时，它都会检查其内部状态。当所有数据接收器接收到标记时，将提交该标记（以及之前处理过的所有记录）。如果出现故障，所有源操作符将重置为看到最后提交的标记时的状态，并继续处理。这种标记检查点方法比Storm的记录级确认更轻量级。本文和相应的文章讨论了Flink的流处理方法，包括容错、检查点和状态处理

Storm还提供了一个名为Trident的一次性高级API。然而，三叉戟是基于小批量，因此更类似于火花比弗林克

---

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

对Fabian Hueske的答案补充：

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

• 背压：当不同的运营商以不同的速度运行时，Flink的流媒体运行时表现良好，因为下游运营商通过网络层的管理缓冲池很好地背压上游运营商

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

• 流窗口：流窗口和窗口聚合是分析数据流的关键构建块。Flink附带了一个非常强大的窗口系统，支持多种类型的窗口

---

基于我对风暴和弗林克的经验。我觉得这些工具可以用不同的方法解决相同的问题。@Stepha提到的Flink的每个特征