流框架基于的实现方式分为两大类。
第一类是Native Streaming,这类引擎中所有的data在到来的时候就会被立即处理,一条接着一条(HINT: 狭隘的来说是一条接着一条,但流引擎有时会为提高性能缓存一小部分data然后一次性处理),其中的代表就是storm和flink。
第二种则是基于Micro-batch,数据流被切分为一个一个小的批次, 然后再逐个被引擎处理。这些batch一般是以时间为单位进行切分,单位一般是‘秒‘,其中的典型代表则是spark了,不论是老的spark DStream还是2.0以后推出的spark structured streaming都是这样的处理机制;另外一个基于Micro-batch实现的就是storm trident,它是对storm的更高层的抽象,因为以batch为单位,所以storm trident的一些处理变的简单且高效。
功能性(Functionality)
01 Event time&Window Operation
1.Event time• event time - 指数据或者事件真正发生时间 , 比如用户点击网页时产生一条点击事件的数据,点击时间就是这条数据固有的event time。
• processing time - 指计算框架处理这条数据的时间。
flink在设计event time处理模型还是较优的:watermark的计算实时性高,输出延迟低,而且接受迟到数据没有spark那么受限。不光如此,flink提供的window programming模型非常的灵活,不但支持spark、storm没有的session window,而且只要实现其提供的WindowAssigner、Trigger、Evictor就能创造出符合自身业务逻辑的window,功能非常强大。
02 SQL API
目前flink相比spark,对streaming sql的支持还是比较初级的
03 Kafka Source Integration
flink对于kafka的兼容性非常好,支持kafka 0.8、0.9、0.10;相反,spark structured streaming只支持kafka0.10或更高版本。
04 Interoperation with Static Data
spark底层对static batch data和streaming data有共同的rdd抽象,完美兼容互操作。而flink中DataSet 和 DataStream是完全独立的,不可以直接交互。
此外,flink还可以运行storm的topology,带来较强的移植性
容错性(Fault Tolerance)
spark依赖checkpoint机制来进行容错,只要batch执行到doCheckpoint操作前挂了,那么该batch就会被完整的重新计算。spark可以保证计算过程的exactly once(不包含sink的exactly once)。
storm的容错通过ack机制实现,每个bolt或spout处理完成一条data后会发送一条ack消息给acker bolt。当该条data被所有节点都处理过后,它会收到来自所有节点ack, 这样一条data处理就是成功的。storm可以保证数据不丢失,但是只能达到at least once语义。此外,因为需要每条data都做ack,所以容错的开销很大。storm trident是基于micro¬batched实现了exactly once语义
flink的checkpoint机制非常轻量,barrier不会打断streaming的流动,而且做checkpoint操作也是异步的。其次,相比storm需要ack每条data,flink做的是small batch的checkpoint,容错的代价相对要低很多。最重要的是flink的checkpoint机制能保证exactly once。
不难发现, flink是一个设计良好的框架,它不但功能强大,而且性能出色。此外它还有一些比较好设计,比如优秀的内存管理和流控。但是,flink目前成熟度较低,还存在着不少问题,比如 SQL支持比较初级;无法像storm一样在不停止任务的情况下动态调整资源;不能像spark一样提供很好的streaming和static data的交互操作等。对于这些问题,flink社区还在积极的跟进,相信在更多公司和贡献者的共同努力下,flink会发展的越来越好。
参考