如何选择Apache Spark和Apache Flink

2024-05-04 23:08

1. 如何选择Apache Spark和Apache Flink

我们是否还需要另外一个新的数据处理引擎?当我第一次听到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社区目前在朝这个方向努力(https://issues.apache.org/jira/browse/FLINK-2320),但是目前还不能轻易断言最后的结果。
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这方面的更迷人的思路。

如何选择Apache Spark和Apache Flink

2. 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结合的时候,支持了,看了源码;

3. 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的支持也越来越好。不管怎么说,二者目前都是在相互吸收。

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

4. 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还是挺不错的。

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

  flink是一个类似spark的“开源技术栈”,因为它也提供了批处理,流式计算,图计算,交互式查询,机器学习等。
  flink
也是内存计算,比较类似spark,但是不一样的是,spark的计算模型基于RDD,将流式计算看成是特殊的批处理,他的DStream其实还是
RDD。而flink吧批处理当成是特殊的流式计算,但是批处理和流式计算的层的引擎是两个,抽象了DataSet和DataStream。
  flink在性能上也标新很好,流式计算延迟比spark少,能做到真正的流式计算,而spark只能是准流式计算。而且在批处理上,当迭代次数变多,flink的速度比spark还要快,所以如果flink早一点出来,或许比现在的Spark更火。

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

6. flink和spark对比

1、技术理念不同:Spark的技术理念是使用微批来模拟流的计算,基于Micro-batch,数据流以时间为单位被切分为一个个批次,通过分布式数据集RDD进行批量处理,是一种伪实时。而Flink是基于事件驱动,它是一个面向流的处理框架, Flink基于每个事件一行一行地流式处理,是真正的流式计算。 另外他也可以基于流来模拟批进行计算实现批处理,在技术上具有更好的扩展性。
  
 2、时间机制:SparkStreaming只支持处理时间, 折中地使用processing time来近似地实现event time相关的业务。使用processing time模拟event time必然会产生一些误差, 特别是在产生数据堆积的时候,误差则更明显,甚至导致计算结果不可用,Structured streaming 支持处理时间和事件时间,同时支持 watermark 机制处理滞后数据Flink 支持三种时间机制:事件时间、注入时间、处理时间、同时支持 watermark 机制处理迟到的数据,说明Flink在处理乱序大实时数据的时候,优势比较大。

7. flink和spark对比

技术理念不同:Spark的技术理念是使用微批来模拟流的计算,基于Micro-batch,数据流以时间为单位被切分为一个个批次,通过分布式数据集RDD进行批量处理,是一种伪实时。而Flink是基于事件驱动,它是一个面向流的处理框架,Flink基于每个事件一行一行地流式处理,是真正的流式计算。             
                 1、技术理念不同:Spark的技术理念是使用微批来模拟流的计算,基于Micro-batch,数据流以时间为单位被切分为一个个批次,通过分布式数据集RDD进行批量处理,是一种伪实时。而Flink是基于事件驱动,它是一个面向流的处理框架, Flink基于每个事件一行一行地流式处理,是真正的流式计算。 另外他也可以基于流来模拟批进行计算实现批处理,在技术上具有更好的扩展性。
  2、时间机制:SparkStreaming只支持处理时间, 折中地使用processing time来近似地实现event time相关的业务。使用processing time模拟event time必然会产生一些误差, 特别是在产生数据堆积的时候,误差则更明显,甚至导致计算结果不可用,Structured streaming 支持处理时间和事件时间,同时支持 watermark 机制处理滞后数据Flink 支持三种时间机制:事件时间、注入时间、处理时间、同时支持 watermark 机制处理迟到的数据,说明Flink在处理乱序大实时数据的时候,优势比较大。

flink和spark对比

最新文章
热门文章
推荐阅读