Flink和斯托姆的主要区别是什么?

nzkunb0c  于 2021-06-24  发布在  Flink
关注(0)|答案(4)|浏览(352)

flink被比作spark,在我看来,spark是一个错误的比较,因为它将窗口事件处理系统与微批处理相比较;同样地,把Flink和桑扎作比较对我来说也没有多大意义。在这两种情况下,它将实时事件处理策略与批处理事件处理策略进行了比较,即使在samza的情况下是在较小的“规模”下。但我想知道flink和storm的比较,storm在概念上似乎更相似。
我发现这个(幻灯片4)记录了flink的“可调整延迟”这一主要区别。另一个暗示似乎是slicon angle的一篇文章,该文章建议flink更好地集成到spark或hadoopmr世界中,但没有提及或引用任何实际细节。最后,fabian hueske自己在一次采访中指出,“与apachestorm相比,flink的流分析功能提供了一个高级api,并使用了一个更轻量级的容错策略来提供精确的一次处理保证。”
所有这些对我来说都有点少,我不太明白重点。有人能解释一下flink到底解决了storm中流处理的哪些问题吗?hueske所指的api问题和他们的“更轻量级的容错策略”是什么?

vyswwuz2

vyswwuz21#

免责声明:我是cloudera的员工,storm and(soon)flink的主要支持者。

功能性

已经提出了许多好的技术要点。一个非常简短的亮点总结:
flink和storm都可以处理每个事件
storm似乎不支持开箱即用的事件时间
storm并没有将sql支持从实验阶段提升出来

非功能性

许多客户发现storm(太)难用
storm的采用速度减慢了,而flink社区现在似乎比storm更为活跃
flink仍有一些需要改进的地方(例如,有文档记录的例子),但总体而言,它已经在你可能想到的几乎每个领域都得到了改进

结论

cloudera最近宣布了对storm(在hdp中)的贬低。同时,Flink被宣布为其继任者。
所以,如果你有关于storm的用例,它们当然会继续工作。但对于新的用例,我会研究flink或其他流媒体引擎。

wnvonmuf

wnvonmuf2#

费边·休斯克的回答是:
flink在storm上也有以下改进:
背压:当不同的运营商以不同的速度运行时,flink的流运行时表现良好,因为下游运营商很好地背压上游运营商,尽管网络层管理缓冲池。
用户定义状态:flink允许程序在操作符中维护自定义状态。该状态实际上可以参与容错检查点,为自定义用户定义的状态提供一次准确的保证。请看这个在操作符中用户定义的状态机的例子,它与数据流一起被一致地检查点。
流窗口:流窗口和窗口聚合是分析数据流的关键构建块。flink提供了一个非常强大的窗口系统,支持多种类型的窗口。

jmp7cifd

jmp7cifd3#

免责声明:我是ApacheFlink的提交者和pmc成员,只熟悉storm的高级设计,不熟悉其内部结构。
apacheflink是一个用于统一流和批处理的框架。flink的运行时本机支持这两个域,因为并行任务之间的流水线数据传输包括流水线洗牌。记录会立即从生产任务传送到接收任务(在缓冲区中收集以进行网络传输之后)。可以选择使用阻塞数据传输来执行批处理作业。
apachespark是一个还支持批处理和流处理的框架。flink的batchapi看起来非常相似,它与spark解决了相似的用例,但在内部结构上有所不同。对于流媒体,这两个系统都遵循非常不同的方法(小批量与流媒体),这使得它们适合不同类型的应用程序。我想说比较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算法的变体。简言之,数据源定期向数据流中注入标记。每当一个操作符收到这样的标记时,它就检查它的内部状态。当所有数据接收器接收到一个标记时,将提交该标记(以及之前处理过的所有记录)。在失败的情况下,所有sources操作符在看到最后一个提交的标记时都将重置为其状态,并继续处理。这种标记检查点方法比storm的记录级确认更轻量级。这个幻灯片集和相应的谈话讨论了flink的流处理方法,包括容错、检查点和状态处理。
storm还提供了一个名为trident的高级api。然而,三叉戟是基于小批量,因此更类似于Spark比Flink。
flink的可调整延迟指的是flink将记录从一个任务发送到另一个任务的方式。我之前说过,flink使用流水线数据传输,一旦产生记录就转发。为了提高效率,这些记录被收集在一个缓冲区中,一旦缓冲区满了或达到某个时间阈值,缓冲区就会通过网络发送。此阈值控制记录的延迟,因为它指定了记录在缓冲区中不被发送到下一个任务的最长时间。但是,不能用它来硬保证记录从进入程序到离开程序所需的时间,因为这还取决于任务内的处理时间和网络传输次数等。

niwlg2el

niwlg2el4#

根据我对风暴和Flink的经验。我觉得这些工具可以用不同的方法解决同一个问题。@stephan ewen提到的flink的每一个特性都可以通过storm和内部api(即spolts和bolts)以及trident api来匹配。有人说trident是迷你批处理风格,而我认为大多数与状态相关或聚合的复杂应用程序只能依赖于窗口风格的批处理。所以我只列出了一些主要的区别,没有说哪一个更好。
开发风格。flink中面向计算的(例如,可链运算符)与面向数据流的(例如。, addSpolt()/addBolt() )在Storm中。
高级api。flink中的功能(如Map、窗口、加入流媒体级别)与storm中的原生窗口和三叉戟。
保证消息处理(gmp)。i、 例如,正好一次)。flink中带有两阶段提交连接器(如kafkaconsumer)的检查点与storm中带有外部状态机或三叉戟的元组树。
容错性。Flink的标记检查站和风暴中的记录水平确认。
内部架构。flink中的简单抽象和相对并行性(例如,每个线程的插槽与cpu内核一起考虑)与storm中的多层抽象(例如,每个jvm的插槽作为管理器中的工作线程,每个管理器可以有多个工作线程)之比。

相关问题