流框架基于的实现方式分为两大类。
第一类是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会发展的越来越好。
参考