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

Apache Flink是用于统一流和批处理的框架。由于并行任务之间的管道数据传输（包括管道随机播放），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时，必须手动实现许多此功能。另一个区别是处理语义。Storm保证了至少一次处理，而Flink提供了一次。提供这些处理保证的实现方式相差很多。尽管Storm使用记录级确认，但是Flink使用Chandy-Lamport算法的变体。简而言之，数据源会定期将标记插入到数据流中。每当操作员收到此类标记时，它都会检查其内部状态。当所有数据接收器都收到一个标记时，该标记（以及之前已处理的所有记录）都将被提交。如果发生故障，当所有源操作员看到最后提交的标记时，它们将重置为其状态，并继续进行处理。这种标记检查点方法比Storm的记录级确认更轻便。这个 数据源定期将标记插入数据流中。每当操作员收到此类标记时，它都会检查其内部状态。当所有数据接收器都收到一个标记时，该标记（以及之前已处理的所有记录）都将被提交。如果发生故障，当所有源操作员看到最后提交的标记时，它们将重置为其状态，并继续进行处理。这种标记检查点方法比Storm的记录级确认更轻便。这个 数据源定期将标记插入数据流中。每当操作员收到此类标记时，它都会检查其内部状态。当所有数据接收器都收到一个标记时，该标记（以及之前已处理的所有记录）都将被提交。如果发生故障，当所有源操作员看到最后提交的标记时，它们将重置为其状态，并继续进行处理。这种标记检查点方法比Storm的记录级确认更轻便。这个 当看到最后提交的标记并继续处理时，所有源操作员将重置为其状态。这种标记检查点方法比Storm的记录级确认更轻便。这个 当看到最后提交的标记并继续处理时，所有源操作员将重置为其状态。这种标记检查点方法比Storm的记录级确认更轻便。这个幻灯片集和相应的讨论讨论了Flink的流处理方法，包括容错，检查点和状态处理。

Storm还提供了一次仅称为Trident的高级API。但是，Trident基于迷你批处理，因此与Flink相比更类似于Spark。

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

回答2：

添加到Fabian Hueske的答案中：

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

背压：当不同的运营商以不同的速度运行时，Flink的流运行时表现良好，因为尽管网络层管理缓冲池，但下游运营商对上游运营商的背压却很好。

用户定义的状态：Flink允许程序在您的操作员中维护自定义状态。该状态实际上可以参与容错性的检查点，从而为自定义用户定义状态提供一次精确的保证。请参见操作员内部用户定义状态机的此示例，该示例机与数据流一起始终被检查点检查。

流窗口：流窗口和窗口聚合是分析数据流的关键构建块。Flink带有功能强大的窗口系统，该系统支持多种类型的窗口。