flink为什么这么火

在实时计算里，最出名的是几个框架应该就是spark streaming 、storm和flink ,最近两年各大互联网大厂纷纷切到flink，为什么？为什么这么火？

一个表格告诉你！

1.在模型上，storm 和 flink 都是实时流，来一条处理一条，而spark streaming 是一个微批次处理，数据流被切分成一个个小的批次，一般单位是秒级。

2.在功能上，flink 支持事件时间(event time),spark streaming 及 strom 1.0以前的版本都是不支持的，都是使用processing time 作为时间统计，这样就会产生误差，特别是数据堆积的时候，误差就更明显。在使用event time时，自然而然需要解决由网络延迟等因素导致的迟到或者乱序数据的问题。为了解决这个问题， spark、storm及flink 引入watermark与lateness。

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

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

3.在窗口操作上也是很大优势

    3.1lateness定义: 在spark中，迟到被定义为data的event time和watermark的比较结果，当data的event time < watermark时，data被丢弃;flink中只有在watermark > window_end + lateness的时候，data才会被丢弃。

    3.2 watermark更新: spark中watermark是上个batch中的max event time,即watermark = Max(last batch timestamps) - lateness，存在延迟;而在flink中是可以做到每条数据同步更新watermark。

    3.3window触发: flink中window计算会触发一次或多次，第一次在watermark >= window_end后立刻触发(main fire)，接着会在迟到数据到来后进行增量触发。spark只会在watermark(包含lateness)过了window_end之后才会触发，虽然计算结果一次性正确，但触发比flink起码多了一个lateness的延迟。

    flink 的watermark的计算实时性高，输出延迟低，而且接受迟到数据没有spark那么受限。不光如此，flink提供的window programming模型非常的灵活，不但支持spark、storm没有的session window，而且只要实现其提供的WindowAssigner、Trigger、Evictor就能创造出符合自身业务逻辑的window，功能非常强大。

4.SQL API 支持，Flink SQL 目前发展成熟，目前主流大厂都在搭建flink 实时数仓平台，实现sql化开发，减少学习成本，使数仓童鞋更专注与业务本身。

5.容错性上，flink使用Chandy-Chandy-Lamport Algorithm 来做Asynchronous Distributed Snapshots(异步分布式快照)，其本质也是checkpoint。如下图，flink定时往流里插入一个barrier(隔栏)，这些barriers把数据分割成若干个小的部分，当barrier流到某个operator时，operator立即会对barrier对应的一小部分数据做checkpoint并且把barrier传给下游(checkpoint操作是异步的，并不会打断数据的处理)，直到所有的sink operator做完自己checkpoint后，一个完整的checkpoint才算完成。当出现failure时，flink会从最新完整的checkpoint点开始恢复。flink的checkpoint机制非常轻量，barrier不会打断streaming的流动，而且做checkpoint操作也是异步的。  

    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，所以容错的开销很大。

6.延迟性上，spark基于微批次实现，延迟性高。一般spark的latency是秒级别的。storm与flink，是完全实时流实现，也可以达到毫秒级别的延迟。

7.吞吐量上，spark 吞吐量是最大的，但对于有状态计算(如updateStateByKey算子)需要通过额外的rdd来维护状态，导致开销较大，对吞吐量影响也较大，storm的ack机制开销很大，会使下降甚至可以达到70%，而flink的容错机制较为轻量，对吞吐量影响较小。