免责声明:我是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使用流水线数据传输,一旦产生记录就转发。为了提高效率,这些记录被收集在一个缓冲区中,一旦缓冲区满了或达到某个时间阈值,缓冲区就会通过网络发送。此阈值控制记录的延迟,因为它指定了记录在缓冲区中不被发送到下一个任务的最长时间。但是,不能用它来硬保证记录从进入程序到离开程序所需的时间,因为这还取决于任务内的处理时间和网络传输次数等。