为什么需要flink（Storm，Spark，Flink对比）

本文目录

• Storm，Spark，Flink对比
• flink 并行度

Storm，Spark，Flink对比

一、容错性（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使用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操作也是异步的。其次，相比storm需要ack每条data，flink做的是small batch的checkpoint，容错的代价相对要低很多。最重要的是flink的checkpoint机制能保证exactly once。

二、吞吐量和延迟（Throughputs& Latency）

01 吞吐量（throughputs）

spark是mirco-batch级别的计算，各种优化做的也很好，它的throughputs是最大的。但是需要提一下，有状态计算（如updateStateByKey算子）需要通过额外的rdd来维护状态，导致开销较大，对吞吐量影响也较大。

storm的容错机制需要对每条data进行ack，因此容错开销对throughputs影响巨大，throughputs下降甚至可以达到70%。storm trident是基于micro-batch实现的，throughput中等。

flink的容错机制较为轻量，对throughputs影响较小，而且拥有图和调度上的一些优化机制，使得flink可以达到很高 throughputs。

下图是flink官网给出的storm和flink的benchmark，我们可以看出storm在打开ack容错机制后，throughputs下降非常明显。而flink在开启checkpoint和关闭的情况下throughputs变化不大，说明flink的容错机制确实代价不高。对比官网的benchmark，我们也进行了throughputs的测试，实测结果是flink throughputs是storm的3.5倍，而且在解除了kafka集群和flink集群的带宽瓶颈后，flink自身又提高了1.6倍。

02 延迟（latency）

spark基于micro-batch实现，提高了throughputs，但是付出了latency的代价。一般spark的latency是秒级别的。

storm是native streaming实现，可以轻松的达到几十毫秒级别的latency，在几款框架中它的latency是最低的。storm trident是基于micro-batch实现的，latency较高。

flink也是native streaming实现，也可以达到百毫秒级别的latency。

下图是flink官网给出的和storm的latency对比benchmark。storm可以达到平均5毫秒以内的latency，而flink的平均latency也在30毫秒以内。两者的99%的data都在55毫秒latency内处理完成，表现都很优秀。

三、 总 结

综合对比spark、storm和flink的功能、容错和性能（总结如下图）

flink 并行度

Flink 作为一套分布式执行框架，计算资源可以不断的扩展。
不同的任务类型，可以控制需要的计算资源。在flink整个runtime的模型中
并行度是一个很重要的概念，通过设置并行度可以为认为分配合理的计算资源，
做到资源的合理配置。

整个flink的架构简单的说是 中心控制（jobManager）+ 多点分布执行（taskManager）
弹性的资源分配主要来自于taskManager的有效管理和配置。

在启动flink 之前，在核心的配置文件里面，需要指定两个参数。
taskmanager.numberOfTaskSlots 和 parallelism.default。

首先需要明白slot的概念。对于 taskManager，他其实是一个 JVM 程序。
这个JVM 可以同时执行多个task，每个task 需要使用本机的硬件资源。
slot 的属于 jvm 管理的 一些列资源卡槽。 每个slot 只能执行一个task。
每个slot分配有固定的内存资源，但是不做cpu的隔离。 JVM管理一个 slot的pool，
用来执行相应的task。taskmanager.numberOfTaskSlots = 10，则理论上可以同时执行10个子任务。

那么对于1个5节点，numberOfTaskSlots= 6的集群来说，那么就有30个slot可以使用。
对于具体的一个job来说，他会贪婪的使用所有的 slot吗？
使用多少slot 是由parallelism.default 决定的。如果是 5， 那么对于一个job 他最多同时使用5个slot。
这个配置对于多job平台的集群是很有必要的。

那么给定一个stream api 编写的flink 程序，被分解的task是否和map 到slot 上执行的呢？
flink 有几个经典的graph， stream-api对应的stream_graph-》 job_graph-》execution_graph-》物理执行图。
execution_graph 基本就决定了如何分布执行。
我们知道一个 stream-api, 主要有 source, operate, sink 这几部分。那么我们可以从source开始看 并行的控制。

source 有并行source和 非并行。我们主要看并行，想类似与kafka 这种生成消费者模式的数据源，能够 并行消费source是非常重要的。
所以可以看到kafka，FlinkKafkaConsumerBase《T》 extends RichParallelSourceFunction《T》，可以充分利用并行度，大大提高吞吐量。
对应到具体的物理执行上，就是多个 source task 任务执行，他们属于一个kafka group同时消费 不同的partition。
对于parallelSource，默认使用cpu 核心做并行度。我们可以通过api进行设置。

接下来是 operate，每个operate都可以设置parallel，如果没有设置将会使用其他层次的设置，比如env，flink.conf中的配置，parallelism.default。
比如 source. map1().map2().grouby(key).sink()
这样一个程序，默认，source和 map1，map2有同样的parallel，上游的output 可以直接one-one forwarding.
在flink 的 优化中，甚至可以把这些 one-one 的operate 合成一个，避免转发，线程切换，网络通信开销。
对于groupby 这样的算子，则属于另外的一类。上游的output 需要 partion 到下游的不同的节点，而不能做位一个chain。

由于operate可以设置独自的parallel，如果与上游不一致。上游的output必然需要某种partion策略来 rebalnce数据。kafka有很多策略来处理这个细节。
对于partion放在专门的章节来说明。
对于sink，则可以理解位一个特定的operate，目前看没什么特殊处理逻辑。