Flink被与Spark相比较，但我认为这是错误的比较，因为它将一个窗口事件处理系统与微批处理进行比较；同样，将Flink与Samza进行比较对我来说也没有太多意义。在这两种情况下，它比较了实时和批处理事件处理策略，即使在Samza的情况下规模更小。但我想知道Flink与Storm相比如何，因为后者在概念上更加相似。
我发现 this（第四张幻灯片）记录了Flink的主要区别为“可调节延迟”。另一个提示来自Slicon Angle的一篇文章，建议Flink更好地集成到Spark或HadoopMR世界中，但没有提及或引用任何实际细节。最后，Fabian Hueske本人在一次采访中指出，“与Apache Storm相比，Flink的流分析功能提供了高级API，并使用更轻量级的容错策略，以提供精确的处理保证。”免责声明：我是Apache Flink的贡献者和PMC成员，只熟悉Storm的高级设计，不了解其内部。
Apache Flink是一个统一的流处理和批处理框架。由于并行任务之间的管道数据传输（包括管道随机洗牌），Flink的运行时原生支持这两个领域。记录会立即从生产任务发送到接收任务（在缓冲区进行网络传输后）。可以使用阻塞数据传输可选地执行批处理作业。
Apache Spark也是一个支持批处理和流处理的框架。Flink的批处理API看起来与Spark相似，解决了类似的用例，但在内部实现上有所不同。对于流处理，两个系统采用非常不同的方法（小批量 vs. 流式处理），这使它们适用于不同类型的应用程序。我认为比较Spark和Flink是有效和有用的，但Spark并不是最相似的流处理引擎。
就原始问题而言，Apache Storm是一种没有批处理功能的数据流处理器。实际上，Flink的管道引擎在内部看起来有点类似于Storm，即Flink的并行任务接口类似于Storm的bolt。Storm和Flink之间的共同点是它们通过管道化数据传输来实现低延迟的流处理。但是，与Storm相比，Flink提供了更高级别的API。Flink的DataStream API提供了Map、GroupBy、Window和Join等函数，而不是使用一个或多个读取器和收集器来实现bolts的功能，这些功能在使用Storm时必须手动实现。另一个区别是处理语义。Storm保证至少一次处理，而Flink提供确切一次处理。给出这些处理保证的实现有很大的不同。虽然Storm使用记录级确认，但Flink使用Chandy-Lamport算法的变体。简而言之，数据源会定期将标记注入到数据流中。每当运算符接收到这样的标记时，它都会对其内部状态进行检查点。当所有数据汇接收到一个标记时，该标记（以及之前处理过的所有记录）就被提交了。如果发生故障，所有源运算符都将重置为它们看到最后一个已提交标记时的状态，并继续处理。这种标记-检查点方法比Storm的记录级确认更轻量级。这个幻灯片集和相应的演讲讨论了Flink的流处理方法，包括容错性、检查点和状态处理。
Storm还提供了一种称为Trident的确切一次、高级别API。然而，Trident基于小批量，因此更类似于Spark而不是Flink。
Flink的可调节性延迟是指Flink将记录从一个任务发送到另一个任务的方式。前面我提到过，Flink使用管道式数据传输，一旦记录产生就立即转发。为了效率，这些记录被收集在缓冲区中，当缓冲区已满或达到某个时间阈值时才通过网络发送。该阈值控制记录的延迟时间，因为它指定了记录在缓冲区内等待发送到下一个任务的最长时间。然而，它无法用于对进入和离开程序的记录所需时间提供强硬保证，因为这还取决于任务内部的处理时间和网络传输次数等其他方面。
补充Fabian Hueske的答案：
Flink相对于Storm还有以下优点：
背压控制：Flink的流式运行时会很好地处理不同算子以不同速度运行的情况，因为下游算子通过网络层管理的缓冲池非常好地控制上游算子的背压。
用户定义状态：Flink允许程序在算子中维护自定义的状态。该状态实际上可以参与容错检查点，为自定义用户定义状态提供精确一次保证。请参阅此示例，其中包含一个用户定义状态机算子，它与数据流一起被持续检查点。
流式窗口：流式窗口和窗口聚合是分析数据流的关键构建块。Flink带有一个相当强大的窗口系统，支持多种类型的窗口。
免责声明：我是Cloudera的员工，这是Storm和（即将推出的）Flink的主要支持者之一。
已经提出了许多好的技术观点。以下是一些亮点的非常简短的总结：
Cloudera最近宣布停用Storm（在HDP中）。同时，Flink被宣布为其继任者。
因此，如果您在使用Storm方面有用例，它们当然将继续工作。但是对于新的用例，我建议尝试Flink或其他流处理引擎。
addSpolt()/addBolt()）。