flinkspark对比（flink 和 spark）

本篇文章给大家谈谈flinkspark对比，以及flink 和 spark对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、Apache Flink和Apache Spark有什么异同？它们的发展前景分别怎样
• 2、Spark和Flink的区别?
• 3、Apache Flink现在在大数据处理方面能够和Apache Spark分庭抗礼么
• 4、Storm，Spark，Flink对比

Apache Flink和Apache Spark有什么异同？它们的发展前景分别怎样

1、Spark在SQL上的优化，尤其是DataFrame到DataSet其实是借鉴的Flink的。Flink最初一开始对握森SQL支持得就更好。

2、Spark的cache in memory在Flink中是由框架自己判断的，而不是用户来指定的，因为Flink对数据的处理不像Spark以RDD为单位，就是一种细粒度的处理，对段颤亩内存的规划更好。

3、Flink原来用Java写确实很难看，现在也在向Spark靠拢，Scala的支持也越来越好。不管怎么说，二者目前都是洞模在相互吸收。

PS：听大师兄说，其实Flink一开始确实做得比Spark要好，但是没人家会宣传，投的会议也没有Spark好，也就不温不火了。我们组都准备转向Flink了，确实挺看好Flink的。华为不是还战略性投资Flink吗，Flink还是挺不错的。

[img]

Spark和Flink的区别?

Flink 和 Spark 都是基于内存计算、支持实时/批处理等多种计算模式的统一框架

Spark的技术理念是使用微批来模拟流的计算,基于Micro-batch,数据流以时间为单位被切分为一个个批次,通过分布式数据誉颂集RDD进行批量处理,是一种伪实时。

而Flink是基于事件驱动的，它是一个面向流的处理框架, Flink基于每个事件一行一行地流式处理，是真正的流式计算. 另外他也可以基于流来模拟批进行计算实现批处理,所以他在技术上具有更好的扩展性,未来可能会成为一个统一的大数据处理引擎

因为他们技术理念的不同,也就导致了性能相关的指标的差别,spark是基于微批的,而且流水线优化做的很好,所以说他的吞入量是最大的,但是付出了延迟的代价,它的延迟是秒级;而Flink是基于事件的,消息逐条处理,而且他的容错机制很轻量级,所以他改虚做能在兼顾高吞吐量的同时又有很低的延迟,它的延迟能够达到毫秒级;

SparkStreaming只支持处理时间, 折中地使用processing time来近似地实现event time相关的业务。显然，使用processing time模拟event time必然会产生一些误差， 特别是在产生数据堆积的时候，误差则更明显，甚至导致计算结果不可用

Structured streaming 支持处理时间和事件时间，同时支持 watermark 机制处理滞后数据

Flink 支持三种时间机制：事件时间，注入时间，处理时间，同时支持 watermark 机核衡制处理迟到的数据,说明Flink在处理乱序大实时数据的时候,优势比较大

其实和Kafka结合的区别还是跟他们的设计理念有关,SparkStreaming是基于微批处理的,所以他采用DirectDstream的方式根据计算出的每个partition要取数据的Offset范围,拉取一批数据形成Rdd进行批量处理,而且该Rdd和kafka的分区是一一对应的;

Flink是真正的流处理,他是基于事件触发机制进行处理,在KafkaConsumer拉取一批数据以后,Flink将其经过处理之后变成,逐个Record发送的事件触发式的流处理

另外,Flink支持动态发现新增topic或者新增partition,而SparkStreaming和0.8版本的kafka结合是不支持的,后来跟0.10版本的kafka结合的时候,支持了,看了源码;

Apache Flink现在在大数据处理方面能够和Apache Spark分庭抗礼么

我们是否还需要另外一个新的数据处理引擎？当我第一次听到flink的时候这是我是非常怀疑的。在大早此铅数据领域，现在已经不缺少数据处理框架了，但是没有一个框架能够完全满足不同的处理需求。自从Apache spark出现后，貌似已经成为当今把大部分的问题解决得最好的框架了，所以我对另外一款解决类似问题的框架持有很强烈的怀疑态度。

不过因为好奇，我花费了数个星期在尝试了解flink。一开始仔细看了flink的几个例子，感觉和spark非常类似，心理就倾向于认为flink又是一个模仿spark的框架。但是随着了解的深入，这些API体现了一些flink的新奇的思路，这些思路还是和spark有着比较明显的区别的。我对这些思路有些着迷了，所以花费了更多的时间在这上面。

flink中的很多思路，例如内存管理，dataset API都已经出现在spark中并且已经证明 这些思路是非常靠谱的。所以，深入了解flink也许可以帮助我们分布式数据处理的未来之路是怎样的

在后面的文章里，我会把自己作为一个spark开发者对flink的第一感受写出来。因为我已经在spark上干了2年多了，但是只在flink上接触了2到3周，所以必然存在一些bias，所以大家也带着怀疑和批判的角度来看这篇文章吧。

Apache Flink是什么

flink是一款新的大数据处理引擎，目标是统一不同来源的数据处理。这个目标看起来和spark和类似。没错，flink也在尝试解决spark在解决的问题。这两套系统都在尝试建立扒并一个统一的平台陆好可以运行批量，流式，交互式，图处理，机器学习等应用。所以，flink和spark的目标差别并不大，他们最主要的区别在于实现的细节。

后面我会重点从不同的角度对比这两者。

Apache Spark vs Apache Flink

1.抽象 Abstraction

spark中，对于批处理我们有RDD,对于流式，我们有DStream，不过内部实际还是RDD.所以所有的数据表示本质上还是RDD抽象。

后面我会重点从不同的角度对比这两者。在flink中，对于批处理有DataSet，对于流式我们有DataStreams。看起来和spark类似，他们的不同点在于：

一）DataSet在运行时是表现为运行计划(runtime plans)的

在spark中，RDD在运行时是表现为java objects的。通过引入Tungsten，这块有了些许的改变。但是在flink中是被表现为logical plan(逻辑计划)的，听起来很熟悉？没错，就是类似于spark中的dataframes。所以在flink中你使用的类Dataframe api是被作为第一优先级来优化的。但是相对来说在spark RDD中就没有了这块的优化了。

flink中的Dataset，对标spark中的Dataframe，在运行前会经过优化。

在spark 1.6，dataset API已经被引入spark了，也许最终会取代RDD 抽象。

二）Dataset和DataStream是独立的API

在spark中，所有不同的API，例如DStream，Dataframe都是基于RDD抽象的。但是在flink中，Dataset和DataStream是同一个公用的引擎之上两个独立的抽象。所以你不能把这两者的行为合并在一起操作，当然，flink社区目前在朝这个方向努力()，但是目前还不能轻易断言最后的结果。

2.内存管理

一直到1.5版本，spark都是试用java的内存管理来做数据缓存，明显很容易导致OOM或者gc。所以从1.5开始，spark开始转向精确的控制内存的使用，这就是tungsten项目了

flink从第一天开始就坚持自己控制内存试用。这个也是启发了spark走这条路的原因之一。flink除了把数据存在自己管理的内存以外，还直接操作二进制数据。在spark中，从1.5开始，所有的dataframe操作都是直接作用在tungsten的二进制数据上。

3.语言实现

spark是用scala来实现的，它提供了Java，Python和R的编程接口。

flink是java实现的，当然同样提供了Scala API

所以从语言的角度来看，spark要更丰富一些。因为我已经转移到scala很久了，所以不太清楚这两者的java api实现情况。

4.API

spark和flink都在模仿scala的collection API.所以从表面看起来，两者都很类似。下面是分别用RDD和DataSet API实现的word count

// Spark wordcount

object WordCount {

def main(args: Array[String]) {

val env = new SparkContext("local","wordCount")

val data = List("hi","how are you","hi")

val dataSet = env.parallelize(data)

val words = dataSet.flatMap(value = value.split("\\s+"))

val mappedWords = words.map(value = (value,1))

val sum = mappedWords.reduceByKey(_+_)

println(sum.collect())

}

}

// Flink wordcount

object WordCount {

def main(args: Array[String]) {

val env = ExecutionEnvironment.getExecutionEnvironment

val data = List("hi","how are you","hi")

val dataSet = env.fromCollection(data)

val words = dataSet.flatMap(value = value.split("\\s+"))

val mappedWords = words.map(value = (value,1))

val grouped = mappedWords.groupBy(0)

val sum = grouped.sum(1)

println(sum.collect())

}

}

不知道是偶然还是故意的，API都长得很像，这样很方便开发者从一个引擎切换到另外一个引擎。我感觉以后这种Collection API会成为写data pipeline的标配。

Steaming

spark把streaming看成是更快的批处理，而flink把批处理看成streaming的special case。这里面的思路决定了各自的方向，其中两者的差异点有如下这些：

实时 vs 近实时的角度

flink提供了基于每个事件的流式处理机制，所以可以被认为是一个真正的流式计算。它非常像storm的model。

而spark，不是基于事件的粒度，而是用小批量来模拟流式，也就是多个事件的集合。所以spark被认为是近实时的处理系统。

Spark streaming 是更快的批处理，而Flink Batch是有限数据的流式计算。

虽然大部分应用对准实时是可以接受的，但是也还是有很多应用需要event level的流式计算。这些应用更愿意选择storm而非spark streaming，现在，flink也许是一个更好的选择。

流式计算和批处理计算的表示

spark对于批处理和流式计算，都是用的相同的抽象：RDD，这样很方便这两种计算合并起来表示。而flink这两者分为了DataSet和DataStream，相比spark，这个设计算是一个糟糕的设计。

对 windowing 的支持

因为spark的小批量机制，spark对于windowing的支持非常有限。只能基于process time，且只能对batches来做window。

而Flink对window的支持非常到位，且Flink对windowing API的支持是相当给力的，允许基于process time,data time,record 来做windowing。

我不太确定spark是否能引入这些API，不过到目前为止，Flink的windowing支持是要比spark好的。

Steaming这部分flink胜

SQL interface

目前spark-sql是spark里面最活跃的组件之一，Spark提供了类似Hive的sql和Dataframe这种DSL来查询结构化数据，API很成熟，在流式计算中使用很广，预计在流式计算中也会发展得很快。

至于flink，到目前为止，Flink Table API只支持类似DataFrame这种DSL，并且还是处于beta状态，社区有计划增加SQL 的interface，但是目前还不确定什么时候才能在框架中用上。

所以这个部分，spark胜出。

Data source Integration

Spark的数据源 API是整个框架中最好的，支持的数据源包括NoSql db,parquet,ORC等，并且支持一些高级的操作，例如predicate push down

Flink目前还依赖map/reduce InputFormat来做数据源聚合。

这一场spark胜

Iterative processing

spark对机器学习的支持较好，因为可以在spark中利用内存cache来加速机器学习算法。

但是大部分机器学习算法其实是一个有环的数据流，但是在spark中，实际是用无环图来表示的，一般的分布式处理引擎都是不鼓励试用有环图的。

但是flink这里又有点不一样，flink支持在runtime中的有环数据流，这样表示机器学习算法更有效而且更有效率。

这一点flink胜出。

Stream as platform vs Batch as Platform

Spark诞生在Map/Reduce的时代，数据都是以文件的形式保存在磁盘中，这样非常方便做容错处理。

Flink把纯流式数据计算引入大数据时代，无疑给业界带来了一股清新的空气。这个idea非常类似akka-streams这种。

成熟度

目前的确有一部分吃螃蟹的用户已经在生产环境中使用flink了，不过从我的眼光来看，Flink还在发展中，还需要时间来成熟。

结论

目前Spark相比Flink是一个更为成熟的计算框架，但是Flink的很多思路很不错，Spark社区也意识到了这一点，并且逐渐在采用Flink中的好的设计思路，所以学习一下Flink能让你了解一下Streaming这方面的更迷人的思路。

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的功能、容错和性能（总结如下图）

关于flinkspark对比和flink 和 spark的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。