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

fnl*_*fnl 131 apache-storm apache-flink flink-streaming

Flink已被比作Spark,正如我所看到的那样,它是错误的比较,因为它将窗口事件处理系统与微批处理进行比较; 同样,将Flink与Samza进行比较对我来说没有多大意义.在这两种情况下,它都会比较实时与批量事件处理策略,即使在Samza的情况下规模较小的"规模".但我想知道Flink与Storm的比较,它在概念上看起来与它更相似.

我发现这个(幻灯片#4)将主要区别记录为Flink的"可调延迟".另一个提示似乎是Slicon Angle的一篇文章,该文章表明Flink更好地集成到Spark或HadoopMR世界中,但没有提及或引用实际细节.最后,Fabian Hueske 在接受采访时指出:"与Apache Storm相比,Flink的流分析功能提供了一个高级API,并使用更轻量级的容错策略来提供一次性处理保证."

这对我来说有点稀疏,我不太清楚.有人可以通过Flink解释Storm中的流处理是什么问题(??)?什么是Hueske所指的API问题及其"更轻量级的容错策略"?

Fab*_*ske 200

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

Apache Flink是统一流和批处理的框架.由于并行任务之间的流水线数据传输(包括流水线shuffle),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时必须手动实现许多此功能.另一个区别是处理语义.风暴保证至少一次处理,而Flink只提供一次.给出这些处理保证的实现有很大不同.虽然Storm使用记录级别的确认,但Flink使用了Chandy-Lamport算法的变体.简而言之,数据源会定期将标记注入数据流.每当操作员接收到这样的标记时,它就会检查其内部状态.当所有数据接收器都接收到标记时,将提交标记(以及之前已处理的所有记录).如果发生故障,所有源操作员在看到最后一个提交的标记并且继续处理时将重置为其状态.这种标记检查点方法比Storm的记录级别确认更轻量级.这个幻灯片集和相应的讨论讨论了Flink的流处理方法,包括容错,检查点和状态处理.

Storm还提供了一个名为Trident的一次性高级API.然而,Trident基于迷你批次,因此更像Spark而不是Flink.

Flink的可调延迟是指Flink将记录从一个任务发送到另一个任务的方式.我之前说过,Flink使用流水线数据传输并在生成后立即转发记录.为了提高效率,这些记录被收集在一个缓冲区中,该缓冲区在满载或满足特定时间阈值时通过网络发送.此阈值控制记录的延迟,因为它指定记录在未发送到下一个任务的情况下保留在缓冲区中的最长时间.但是,它不能用于确保记录从进入程序到离开程序所花费的时间,因为这还取决于任务内的处理时间和网络传输的数量等.

  • 当然,我扩展了我的答案并讨论了可调延迟.如果您有其他问题,请与我们联系. (6认同)
  • 非常感谢你!如果我再次打扰你,可能有一个开放点:这个"可调延迟"问题是什么?考虑到不同的应用领域在这方面会有不同的要求,这似乎非常相关.你能解释一下这意味着什么吗,至少在Flink方面? (2认同)
  • Flink 有趣且巨大的优势是能够使用更高级别的 API 运行 Apache Beam。它是 Beam 最丰富、最完整的跑步者之一。 (2认同)

Ste*_*wen 47

添加到Fabian Hueske的答案:

Flink还通过以下方式改进了Storm:

  • 背压:当不同的运营商以不同的速度运行时,Flink的流运行时表现良好,因为虽然网络层管理缓冲池,但下游运营商对上游运营商的反压非常好.

  • 用户定义的状态:Flink允许程序在您的操作员中维护自定义状态.该状态实际上可以参与容错的检查点,为自定义用户定义的状态提供一次性保证.请参阅操作员内部用户定义的状态机的示例,该状态机始终与数据流一起检查点.

  • 流式Windows:流式窗口和窗口聚合是分析数据流的关键构建块.Flink配备了一个非常强大的窗口系统,支持多种类型的窗口.

  • 关于你的第一点,Storm在1.0的背压下表现良好(2016年4月发布) (2认同)

Den*_*din 6

免责声明:我是 Cloudera 的员工,Storm 和(很快)Flink 的主要支持者。

功能性

已经介绍了很多好的技术点。一个非常简短的亮点摘要:

  • Flink 和 Storm 都可以做 per-event 处理
  • Storm 似乎不支持开箱即用的事件时间
  • Storm 尚未将 SQL 支持从实验阶段解除

非功能性

  • 许多客户发现 Storm(太)难以使用
  • Storm 的采用速度放缓,Flink 社区现在似乎比 Storm 更活跃
  • Flink 仍有一些追赶工作要做(例如记录在案的示例),但总体而言,它几乎在您可能想到的每个领域都赶上了

结论

Cloudera 最近宣布弃用 Storm(在 HDP 中)。同时,Flink 被宣布为其继任者。

因此,如果您在 Storm 中有用例,它们当然会继续工作。但是对于新用例,我会研究 Flink 或其他流媒体引擎。