Flink及Storm、Spark主流流框架比较，到底谁会更厉害？

一：本文的流框架基于的实现方式

本文涉及的流框架基于的实现方式分为两大类。第一类是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的一些处理变的简单且高效。

Flink及Storm、Spark主流流框架比较，到底谁会更胜一筹？

二： 流框架比较的关键指标

从流处理的角度将flink与spark和storm这两个框架进行比较，会主要关注以下几点，后续的对比也主要基于这几点展开：

功能性(Functionality)- 是否能很好解决流处理功能上的痛点 , 比如event time和out of order data。

容错性(Fault Tolerance) - 在failure之后能否恢复到故障之前的状态，并输出一致的结果;此外容错的代价也是越低越好，因为其直接影响性能。 • 吞吐量(throughputs)& 延时(latency) - 性能相关的指标，高吞吐和低延迟某种意义上是不可兼得的，但好的流引擎应能兼顾高吞吐&低延时。

功能性(Functionality)

1 Event time&Window Operation

1.1Event time• event time - 指数据或者事件真正发生时间 , 比如用户点击网页时产生一条点击事件的数据，点击时间就是这条数据固有的event time。 • processing time - 指计算框架处理这条数据的时间。 (具体关于时间的定义可以参看flink文档 http://t.cn/RaTnsdy。)

spark DStream和storm 1.0以前版本往往都折中地使用processing time来近似地实现event time相关的业务。显然，使用processing time模拟event time必然会产生一些误差， 特别是在产生数据堆积的时候，误差则更明显，甚至导致计算结果不可用。

在使用event time时，自然而然需要解决由网络延迟等因素导致的迟到或者乱序数据的问题。为了解决这个问题， spark、storm及flink都参考streaming 102 (http://t.cn/RbQCUmJ)引入了watermark和lateness的概念。

watermark: 是引擎处理事件的时间进度，代表一种状态，一般随着数据中的event time的增长而增长。比如 watermark(t)代表整个流的event time处理进度已经到达t， 时间是有序的，那么streaming不应该会再收到timestamp t’ < t的数据，而只会接受到timestamp t’ >= t的数据。 如果收到一条timestamp t’ < t的数据， 那么就说明这条数据是迟到的。

lateness: 表示可以容忍迟到的程度，在lateness可容忍范围内的数据还会参与计算，超过的会被丢弃。

1.2Window Operation

下面主要比较在使用window的操作中，spark structured streaming 和flink对event time处理机制的不同。

flink 首先，我们结合图来看flink， 时间轴从左往右增大。当watermark WM处于时 间窗口区间内时，即WM ∈ [start, end] , event time落在窗口范围内的任何乱序数据都会被接受;随着WM的增长并超过了窗口的结束时间，但还未超过可容忍的lateness时间范围，即WM ∈ (window_end,window_end+ lateness]， 这时乱序数据仍然可以被接受; 只有当WM超过 window_end+lateness, 即WM ∈ (window_end+ lateness, ∞)， 迟到的数据将会被丢弃。