Flink及Storm、Spark主流流框架⽐较
引⾔
随着⼤数据时代的来临，⼤数据产品层出不穷。我们最近也对⼀款业内⾮常⽕的⼤数据产品 - Apache Flink做了调研，今天与⼤家分享⼀下。Apache Flink(以下简称flink) 是⼀个旨在提供‘⼀站式’ 的分布式开源数据处理框架。是不是听起来很像spark？没错，两者都希望提供⼀个统⼀功能的计算平台给⽤户。虽然⽬标⾮常类似，但是flink在实现上和spark存在着很⼤的区别，flink是⼀个⾯向流的处理框架，输⼊在flink中是⽆界的，流数据是flink中的头等公民。说到这⾥，⼤家⼀定觉得flink和storm有⼏分相似，确实是这样。那么有spark和storm这样成熟的计算框架存在，为什么flink还能占有⼀席之地呢？今天我们就从流处理的⾓度将flink和这两个框架进⾏⼀些分析和⽐较。
1 本⽂的流框架基于的实现⽅式
本⽂涉及的流框架基于的实现⽅式分为两⼤类。第⼀类是Native Streaming，这类引擎中所有的data在到来的时候就会被⽴即处理，⼀条接着⼀条（HINT：狭隘的来说是⼀条接着⼀条，但流引擎有时会为提⾼性能缓存⼀⼩部分data然后⼀次性处理），其中的代表就是storm和flink。第⼆种则是基于Micro-batch，数据流被切分为⼀个⼀个⼩的批次，然后再逐个被引擎处理。这些batch⼀般是以时间为单位进⾏切分，单位⼀般是‘秒‘，其中的典型代表则是spark了，不论是⽼的spark DStream还是2.0以后推出的spark structur
ed streaming都是这样的处理机制；另外⼀个基于Micro-batch实现的就是storm trident，它是对storm的更⾼层的抽象，因为以batch为单位，所以storm trident的⼀些处理变的简单且⾼效。
2 流框架⽐较的关键指标
从流处理的⾓度将flink与spark和storm这两个框架进⾏⽐较，会主要关注以下⼏点，后续的对⽐也主要基于这⼏点展开：
• 功能性（Functionality）- 是否能很好解决流处理功能上的痛点 , ⽐如event time和out of order data。
• 容错性（Fault Tolerance） - 在failure之后能否恢复到故障之前的状态，并输出⼀致的结果；此外容错的代价也是越低越好，因为其直接影响性能。 • 吞吐量(throughputs)& 延时(latency) - 性能相关的指标，⾼吞吐和低延迟某种意义上是不可兼得的，但好的流引擎应能兼顾⾼吞吐&低延时。
功能性（Functionality）
01 Event time&Window Operation
spark DStream和storm 1.0以前版本往往都折中地使⽤processing time来近似地实现event time相关的业务。显然，使⽤processing time模拟event time必然会产⽣⼀些误差，特别是在产⽣数据堆积的时候，误差则更明显，甚⾄导致计算结果不可⽤。
watermark: 是引擎处理事件的时间进度，代表⼀种状态，⼀般随着数据中的event time的增长⽽增长。⽐如 watermark(t)代表整个流的event time处理进度已经到达t，时间是有序的，那么streaming不应该会再收到timestamp t’ < t的数据，⽽只会接受到timestamp t’ >= t的数据。如果收到⼀条timestamp t’ < t的数据，那么就说明这条数据是迟到的。
lateness: 表⽰可以容忍迟到的程度，在lateness可容忍范围内的数据还会参与计算，超过的会被丢弃。
2.Window 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,∞)，迟到的数据将会被丢弃。
fiink中watermark的计算也⽐较灵活，可以选择build-in的（如最⼤时间戳），也可以通过继承接⼝⾃定
义实现。此外，⽤户可以选择周期性更新或者事件触发更新watermark。
下⾯来⽐较⼀下两者实现细节上的不同：
①lateness定义: 在spark中，迟到被定义为data的event time和watermark的⽐较结果，当data的event time < watermark时，data被丢弃；flink中只有在watermark > window_end + lateness的时候，data才会被丢弃。
②watermark更新: spark中watermark是上个batch中的max event time，存在延迟；⽽在flink中是可以做到每条数据同步更新watermark。
③window触发: flink中window计算会触发⼀次或多次，第⼀次在watermark >= window_end后⽴刻触发（main fire），接着会在迟到数据到来后进⾏增量触发。spark只会在watermark（包含lateness）过了window_end之后才会触发，虽然计算结果⼀次性正确，但触发⽐flink起码多了⼀个lateness的延迟。
上⾯三点可见flink在设计event time处理模型还是较优的：watermark的计算实时性⾼，输出延迟低，⽽且接受迟到数据没有spark那么受限。不光如此，flink提供的window programming模型⾮常的灵活，不但⽀持spark、storm没有的session window，⽽且只要实现其提供的WindowAssigner、Trigger、Evictor就能创造出符合⾃⾝业务逻辑的window，功能⾮常强⼤。
02 SQL API
⽬前flink相⽐spark，对streaming sql的⽀持还是⽐较初级的。在当前最新1.2版本中，仅⽀持Selection、Projection、Union、Tumble，不⽀持Aggregation、 Join、Top N、 Sort。计划中1.3版本将⽀持 Window Aggregation(sum、max、 min、avg), 但依然不⽀持Distinct。相⽐flink，当前最新版本的spark structured streaming仅仅不⽀持Top N、Distinct。
03  Kafka Source Integration
flink对于kafka的兼容性⾮常好，⽀持kafka 0.8、0.9、0.10；相反，spark structured streaming只⽀持kafka0.10或更⾼版本。
hadoop与spark的区别与联系
04  Interoperation with Static Data
spark底层对static batch data和streaming data有共同的rdd抽象，完美兼容互操作。⽽flink中DataSet 和 DataStream是完全独⽴的，不可以直接交互。
此外，flink还可以运⾏storm的topology，带来较强的移植性。另外⼀个有趣的功能是可以⾃由调整job latency and throughputs的取舍关系，⽐如需要high throughputs的程序可以牺牲latency来获得更⼤的throughputs。
容错性（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内处理完成，表现都很优秀。
3 总结
综合对⽐spark、storm和flink的功能、容错和性能（总结如下图）
不难发现， flink是⼀个设计良好的框架，它不但功能强⼤，⽽且性能出⾊。此外它还有⼀些⽐较好设计，
⽐如优秀的内存管理和流控。但是，flink⽬前成熟度较低，还存在着不少问题，⽐如 SQL⽀持⽐较初级；⽆法像storm⼀样在不停⽌任务的情况下动态调整资源；不能像spark⼀样提供很好的streaming和static data的交互操作等。对于这些问题，flink社区还在积极的跟进，相信在更多公司和贡献者的共同努⼒下，flink会发展的越来越好。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。