引言随着大数据时代的到来，大数据产品层出不穷。 最近我们也做了关于Apache Flink的研究，这是一个在业界非常流行的大数据产品。今天就来参考一下吧。 Apache flink(以下简称flink)是一个分布式开源数据解决方案框架，旨在提供‘一站式’。 听起来像火花吗？是的，他们都想为客户提供统一的计算平台。 虽然目标很相似，但flink在实现上与spark有很大不同。flink是面向流的解决方案框架，输入在flink中是无界的，流数据在flink中是一等公民。 说到这里，大家一定觉得flink和storm有些相似，确实如此。 那么有了spark和storm这样成熟的计算框架，为什么flink还会有一席之地呢？今天我们就从流量解决方案的角度，对flink和这两个框架做一点分析比较。 1.本文流程框架的实现方法。本文中流程框架的实现方法分为两类。 第一种是原生流，引擎中的所有数据到达后会立即求解，一个接一个(提示:狭义的说是一个接一个，但有时流引擎会缓存少量数据提高性能然后一次性求解)，其中storm和flink就是代表。 第二种是基于微批量，将数据流切割成小批量，然后由引擎逐个解决。 这些批次一般以时间划分，单位通常是‘秒’，其中典型代表就是spark。无论是老的spark DStream还是2.0之后推出的spark结构化流，都是这样的解决机制；另一个基于微批的实现是风暴三叉戟，是风暴三叉戟更高级别的概括。因为批量是单位，所以少量的Stormtrident解决方案变得简单高效。 二、流量框架对比flink与spark、storm的关键指标从流量解决方案的角度，我们会重点关注以下几点，后续的对比会主要基于这几点:功能性)——能否处理好流量解决方案功能的痛点，比如事件时间、乱序数据等？ 容错)——故障后是否恢复到故障前的状态，输出一致的结果；另外，容错成本越低越好，因为它直接影响性能。 吞吐量和延迟)-一个与性能相关的指标。从某种意义上说，高吞吐量和低延迟是不可兼得的，但是一个好的流引擎应该能够兼顾高吞吐量和低延迟 功能1事件时间&操作1.1事件时间事件时间——指的是数据或事件的真实发生时间，比如客户点击网页时产生的一个点击事件的数据，点击时间就是这个数据固有的事件时间。 处理时间——指的是计算框架解决这块数据的时间。 (关于时间的具体定义，请参考http://t.cn/RaTnsdy. flink文档 )spark DStream和之前版本的storm 1.0经常以折中的方式使用处理时间，近似实现事件时间相关的服务。 显然，用处理时间来模拟事件时间，必然会产生少量误差，特别是当出现数据积累时，误差更加显著，甚至计算结果无法使用。 在使用事件时间时，自然要处理网络延迟等因素造成的数据迟到或乱序的问题。 为了解决这个问题，spark、storm和flink参考Streaming 102(http://t . cn/RbQCUmJ)引入了水印和延迟的概念。 水印:是引擎解决事件的时间进度，代表一种状态，一般随着数据中事件时间的增加而增加。 例如，如果水印(T)指示整个流的事件时间解决方案进度已经达到T，并且时间是有序的，则流式传输不应接收时间戳t' < T数据，而仅接收时间戳t' >: = t数据 如果你收到一个时间戳t' < T的数据，那么这个数据就晚了。 潜伏期:表示对迟到的容忍度。在迟到容差范围内的数据也将参与计算，超出部分将被丢弃。 1.2Window操作下面主要比较spark结构化流和flink在使用Window操作中事件时间的解决机制上的区别。 Flink首先我们结合图表来看一下flink。时间轴从左到右增加。 当水印WM在时间窗口的区间内，即WM ∈ [start，end]时，事件时间落在窗口内的事件时间乱序数据将被接受；随着WM的增大，超出窗口结束时间，但不超出可容忍的延时时间范围，即WM ∈ (window _ end，window _ end+latency)，乱序数据仍可接受。只有当WM超过window _ end+latency，即WM ∈( window _ end+latency，∞)时，才会丢弃后期数据。 FI中水印的计算也很灵活。可以选择内置(比如最大时间戳)，也可以通过集成接口自己设置。 此外，客户可以选择定期升级水印或由事件触发。 Spark首先，spark中的水印是通过最后一批的最大时间戳减去延迟得到的，即watermark = max(最后一批时间戳)-Latency。 当数据的事件时间大于水印时，数据将被接受，否则无论数据属于哪个窗口都将被丢弃。 详情请参考spark文档(http://t.cn/RaTnvVQ)。 我们来比较一下两者在实现细节上的区别:①延迟定义:在spark中，①延迟定义为数据的事件时间与水印的比较结果，当数据的事件时间<水印时，数据被丢弃；Flink只在水印>:Window _ end+latency，数据会被丢弃。 ②水印升级:spark中的水印是上一批中的最大事件时间，有延迟；在flink中，可以为每个数据同步更新水印。 ③窗口触发:flink中的窗口计算会触发一次或多次，watermark >: = window_end中第一次是立即触发(主火)，后面是后期数据到达后的增量触发。 Spark只会在水印(包括延时)过了window_end之后才会被触发。虽然计算结果一度正确，但触发比flink至少延迟了一个延时。 从以上三点可以看出，flink在设计事件时间求解模型上更胜一筹:水印实时计算高，输出延迟低，对后期数据的接受不像spark那样受限。 而且flink提供的窗口编程模型非常灵活。它不仅支持spark和storm没有的会话窗口，而且只需要实现提供的WindowAssigner、Trigger和Evictor就可以创建符合自己业务逻辑的窗口，非常强大。 2 SQL API目前相比spark，flink对流式SQL的支持还比较初级。 在最新的1.2版本中，只支持选择、投影、Union和Tumble，不支持聚合、连接、Top N和排序。 计划中的1.3版本将支持窗口聚合(sum，max，min，avg)，但仍不支持Distinct。 与flink相比，最新版本的spark结构化流仅不支持Top N和Distinct。 3 kafka源码集成flink与kafka非常兼容，支持kafka 0.8、0.9、0.10；相反，spark结构化流只支持kafka0.10版本0.10或更高版本。 4与静态数据的互操作spark底层对静态批量数据和流数据有一个公共的rdd，两者完美兼容，互操作。 但是flink中的数据集和数据流是完全独立的，不能直接交互。 此外，flink还可以运行storm的拓扑，带来了很强的可移植性。 另一个有趣的特性是，您可以自由调整作业延迟和吞吐量之间的权衡关系。例如，需要高吞吐量的程序可以牺牲延迟来获得更大的吞吐量。 容错)spark依靠检查点机制来实现容错。只要批处理在doCheckpoint操作之前挂起，就会完全重新计算批处理。 Spark可以保证计算过程的精确一次(不包括sink的精确一次) Storm的容错是通过ack机制实现的，每个bolt或spout在完成一条数据后都会向acker bolt发送一条ack消息。 当这一块数据被所有节点解算后，会收到所有节点的ack，这样一块数据解算成功。 Storm可以保证数据不会丢失，但是只能实现一次atlast的语义。 另外，由于每一条数据都需要ack，容错的开销非常大。 Stortrident基于微批处理实现恰好一次语义。 Flink使用Chandy-Chandy-Lamport算法做异步分布式快照，本质上是一个检查点。 如下图所示，flink定期在溪流中插入障碍物。这些屏障将数据分成几个小部分。当屏障流向一个操作符时，操作符会立即检查屏障对应的一小部分数据，并将屏障传递给下游(检查点操作是异步的，不会中断数据的求解)，直到所有的sink操作符都完成了自己的检查点，一个完整的检查点才算完成。 出现故障时，flink将从最新的完整检查点恢复。 Flink的检查点机制非常轻量级，barrier不会中断流，检查点操作是异步的。 其次，相对于storm需要ack每一条数据，flink做的是小批量的检查点，容错的成本相对要低很多。 最重要的是flink的检查点机制可以保证恰好一次。 而吞吐量延迟(through puts & Latency)1 .1吞吐量)spark是微批量级别的计算，各种优化做的很好，它的吞吐量puts是最大的。 但需要提到的是，有状态计算(如updateStateByKey操作符)需要额外的rdd来维护状态，导致开销大，对吞吐量影响大。 Storm的容错机制需要ack每一条数据，所以容错开销对吞吐量影响很大，吞吐量甚至可以下降70%。 Stortrident基于微批量实施，吞吐量适中。 Flink的容错机制是轻量级的，对吞吐量put的影响很小。此外，它在图和调度方面有少量的优化机制，这使得flink实现了高吞吐量。 下图是flink官网给出的storm和flink的基准。我们可以看到，storm开启ack容错机制后，吞吐量明显下降。 而flink的吞吐量在检查点开启和关闭时变化不大，可见flink的容错机制真的不贵。 对比官网的基准，我们还进行了吞吐量测试。实测结果显示，flink的吞吐量是storm的3.5倍，解除kafka集群和flink集群的带宽瓶颈后，flink本身的吞吐量提高了1.6倍。 1.2延迟)spark是基于微批处理实现的，微批处理提高了吞吐量，但代价是延迟。 一般火花的潜伏期是秒级。 Storm是原生流的实现，可以轻松实现几十毫秒的延迟，其延迟是几个框架中最低的。 Stortrident是基于微批量实现的，延迟高。 Flink也是原生流的实现，同样可以实现数百毫秒的延迟。 下图由flink官网给出，并与storm的延迟基准进行了对比。 Storm可以实现平均延迟小于5毫秒，而flink的平均延迟也小于30毫秒。 两者99%的数据都是在55毫秒的延迟内解决的，非常优秀。 三。综合比较spark、storm和flink的功能、容错性和性能(汇总如下图)可知，flink是一个设计良好的框架，功能强大，性能优异。 此外，它还有几个不错的设计，比如出色的内存管理和流量控制。 但是flink目前成熟度不高，还存在很多问题。比如SQL支持比较初级；你不能像暴风一样不中止任务就动态调整资源；它不能像spark一样提供流和静态数据之间的良好交互。 对于这些问题，flink社区还在积极跟进。相信在更多公司和贡献者的共同努力下，flink会发展的越来越好。