Flink被比作Spark，在我看来，这是一个错误的比较，因为它将窗口事件处理系统与微批处理相比较；同样，将Flink比作Samza对我来说也没有多大意义。在这两种情况下，它将实时事件处理策略与批处理事件处理策略进行了比较，即使在Samza的情况下是在较小的“规模”下。但我想知道Flink和Storm的比较，Storm在概念上似乎更相似。
我发现这个（幻灯片4）记录了Flink的“可调整延迟”这一主要区别。另一个暗示似乎是Slicon Angle的一篇文章，该文章建议Flink更好地集成到Spark或HadoopMR世界中，但没有提及或引用任何实际细节。最后，Fabian Hueske自己在一次采访中指出，“与apachestorm相比，Flink的流分析功能提供了一个高级API，并使用了一个更轻量级的容错策略来提供精确的一次处理保证。”
所有这些对我来说都有点少，我不太明白重点。
免责声明：我是ApacheFlink的提交者和PMC成员，只熟悉Storm的高级设计，不熟悉其内部结构。
apacheflink是一个用于统一流和批处理的框架。Flink的运行时本机支持这两个域，因为并行任务之间的流水线数据传输包括流水线 shuffle。记录会立即从生产任务传送到接收任务（在缓冲区中收集以进行网络传输之后）。可以选择使用阻塞数据传输来执行批处理 job。
apachespark是一个还支持批处理和流处理的框架。Flink的batchapi看起来非常相似，它与Spark解决了相似的用例，但在内部结构上有所不同。对于 streaming，这两个系统都遵循非常不同的方法（小批量与 streaming），这使得它们适合不同类型的应用程序。我想说比较Spark和Flink是有效和有用的，但是Spark并不是Flink最相似的流处理引擎。
说到最初的问题，apachestorm是一个没有批处理功能的数据流处理器。实际上，Flink的流水线引擎内部看起来有点类似于Storm，即Flink的并行任务的接口类似于Storm的bolt。Storm和Flink的共同点是，他们的目标是通过流水线数据传输实现低延迟流处理。不过，与Storm相比，Flink提供了更高级的API。Flink的datastreamapi提供了Map、GroupBy、Window和Join等函数，而不是用一个或多个读卡器和采集器实现bolt的功能。在使用Storm时，很多功能都必须手动实现。另一个区别是处理语义。Storm保证至少处理一次，而Flink只提供一次。提供这些处理保证的实现有很大的不同。Storm使用的是记录级别的确认，而Flink使用的是Chandy Lamport算法的变体。简言之，数据源定期向数据流中注入标记。每当一个操作符收到这样的标记时，它就检查它的内部状态。当所有数据 sink接收到一个标记时，将提交该标记（以及之前处理过的所有记录）。在失败的情况下，所有sources操作符在看到最后一个提交的标记时都将重置为其状态，并继续处理。这种标记 checkpoints方法比Storm的记录级确认更轻量级。这个幻灯片集和相应的谈话讨论了Flink的流处理方法，包括容错、 checkpoints和状态处理。
Storm还提供了一个名为Trident的高级API。然而，三叉戟是基于小批量，因此更类似于 spark比 Flink。
Flink的可调整延迟指的是Flink将记录从一个任务发送到另一个任务的方式。我之前说过，Flink使用流水线数据传输，一旦产生记录就转发。为了提高效率，这些记录被收集在一个缓冲区中，一旦缓冲区满了或达到某个时间阈值，缓冲区就会通过网络发送。此阈值控制记录的延迟，因为它指定了记录在缓冲区中不被发送到下一个任务的最长时间。但是，不能用它来硬保证记录从进入程序到离开程序所需的时间，因为这还取决于任务内的处理时间和网络传输次数等。
