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，并使用更轻量级的容错策略来提供exactly-once处理保证。”
所有这些对我来说都有点稀疏，我不太明白这一点。 有人可以解释一下 Storm 中的流处理有哪些问题是由 Flink 解决的吗？ Hueske 所说的 API 问题及其“更轻量级的容错策略”指的是什么？
最佳答案
免责声明:我是 Apache Flink 提交者和 PMC 成员，只熟悉 Storm 的高层设计，而不熟悉其内部结构。
Apache Flink 是一个统一流和批处理的框架。由于并行任务之间的管道数据传输(包括管道洗牌)，Flink 的运行时本身就支持这两个领域。记录立即从生成任务传送到接收任务(在收集到缓冲区以进行网络传输之后)。可以选择使用阻塞数据传输来执行批处理作业。
Apache Spark 是一个还支持批处理和流处理的框架。 Flink 的批处理 API 看起来与 Spark 非常相似，并且解决的用例与 Spark 相似，但内部结构有所不同。对于流式处理，两个系统都遵循非常不同的方法(小批量与流式处理)，这使得它们适用于不同类型的应用程序。我想说比较 Spark 和 Flink 是有效且有用的，但是 Spark 并不是与 Flink 最相似的流处理引擎。
回到最初的问题，Apache Storm 是一个没有批处理功能的数据流处理器。事实上，Flink 的流水线引擎内部看起来与 Storm 有点相似，即 Flink 并行任务的接口(interface)与 Storm 的 Bolt 类似。 Storm 和 Flink 的共同点是它们的目标是通过管道数据传输实现低延迟流处理。然而，与 Storm 相比，Flink 提供了更高级别的 API。 Flink 的 DataStream API 不是通过一个或多个读取器和收集器来实现 Bolt 的功能，而是提供 Map、GroupBy、Window 和 Join 等功能。使用 Storm 时，许多此类功能必须手动实现。另一个区别是处理语义。 Storm 保证至少一次处理，而 Flink 提供精确一次。提供这些处理保证的实现有很大不同。 Storm 使用记录级确认，而 Flink 使用 Chandy-Lamport 算法的变体。简而言之，数据源定期将标记注入(inject)数据流中。每当运算符(operator)收到这样的标记时，它就会检查其内部状态。当所有数据接收器接收到标记时，该标记(以及之前已处理过的所有记录)都会被提交。如果发生故障，所有源运算符(operator)都会重置为看到最后提交的标记时的状态，并继续处理。这种标记检查点方法比 Storm 的记录级确认更轻量。这个slide set以及相应的talk讨论 Flink 的流处理方法，包括容错、检查点和状态处理。
Storm 还提供了一个名为 Trident 的一次性高级 API。然而，Trident 基于小批量，因此与 Spark 比 Flink 更相似。
Flink 的可调延迟是指 Flink 将记录从一个任务发送到另一个任务的方式。我之前说过，Flink 使用管道式数据传输并在记录生成后立即转发记录。为了提高效率，这些记录被收集在缓冲区中，一旦缓冲区已满或达到某个时间阈值，就会通过网络发送。此阈值控制记录的延迟，因为它指定记录在缓冲区中保留而不发送到下一个任务的最长时间。但是，它不能用于硬性保证记录从进入程序到离开程序所需的时间，因为这还取决于任务内的处理时间和网络传输次数等。
关于apache-storm - Flink 和 Storm 之间的主要区别是什么？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/30699119/