Spark与Flink：对比与分析

2019独角兽企业重金招聘Python工程师标准>>>

Spark是一种快速、通用的计算集群系统，Spark提出的最主要抽象概念是弹性分布式数据集(RDD)，它是一个元素集合，划分到集群的各个节点上，可以被并行操作。用户也可以让Spark保留一个RDD在内存中，使其能在并行操作中被有效的重复使用。Flink是可扩展的批处理和流式数据处理的数据处理平台，设计思想主要来源于Hadoop、MPP数据库、流式计算系统等，支持增量迭代计算。

原理

Spark 1.4特点如下所示。

1. Spark为应用提供了REST API来获取各种信息，包括jobs、stages、tasks、storage info等。
2. Spark Streaming增加了UI，可以方便用户查看各种状态，另外与Kafka的融合也更加深度，加强了对Kinesis的支持。
3. Spark SQL（DataFrame）添加ORCFile类型支持，另外还支持所有的Hive metastore。
4. Spark ML/MLlib的ML pipelines愈加成熟，提供了更多的算法和工具。
5. Tungsten项目的持续优化，特别是内存管理、代码生成、垃圾回收等方面都有很多改进。
6. SparkR发布，更友好的R语法支持。

图1 Spark架构图

图2 Flink架构图

图3 Spark生态系统图

Flink 0.9特点如下所示。

https://github.com/apache/flink

1. DataSet API 支持Java、Scala和Python。
2. DataStream API支持Java and Scala。
3. Table API支持类SQL。
4. 有机器学习和图处理（Gelly）的各种库。
5. 有自动优化迭代的功能，如有增量迭代。
6. 支持高效序列化和反序列化，非常便利。
7. 与Hadoop兼容性很好。

图4 Flink生态系统图

分析对比

性能对比

首先它们都可以基于内存计算框架进行实时计算，所以都拥有非常好的计算性能。经过测试，Flink计算性能上略好。

测试环境：

1. CPU：7000个；
2. 内存：128GB；
3. 版本：Hadoop 2.3.0，Spark 1.4，Flink 0.9
4. 数据：800MB，8GB，8TB；
5. 算法：K-means：以空间中K个点为中心进行聚类，对最靠近它们的对象归类。通过迭代的方法，逐次更新各聚类中心的值，直至得到最好的聚类结果。
6. 迭代：K=10，3组数据

图5 迭代次数（纵坐标是秒，横坐标是次数）

总结：Spark和Flink全部都运行在Hadoop YARN上，性能为Flink > Spark > Hadoop(MR)，迭代次数越多越明显，性能上，Flink优于Spark和Hadoop最主要的原因是Flink支持增量迭代，具有对迭代自动优化的功能。

流式计算比较

它们都支持流式计算，Flink是一行一行处理，而Spark是基于数据片集合（RDD）进行小批量处理，所以Spark在流式处理方面，不可避免增加一些延时。Flink的流式计算跟Storm性能差不多，支持毫秒级计算，而Spark则只能支持秒级计算。

与Hadoop兼容

计算的资源调度都支持YARN的方式

数据存取都支持HDFS、HBase等数据源。

Flink对Hadoop有着更好的兼容，如可以支持原生HBase的TableMapper和TableReducer，唯一不足是现在只支持老版本的MapReduce方法，新版本的MapReduce方法无法得到支持，Spark则不支持TableMapper和TableReducer这些方法。

SQL支持

都支持，Spark对SQL的支持比Flink支持的范围要大一些，另外Spark支持对SQL的优化，而Flink支持主要是对API级的优化。

计算迭代

delta-iterations，这是Flink特有的，在迭代中可以显著减少计算，图6、图7、图8是Hadoop(MR)、Spark和Flink的迭代流程。

图6 Hadoop（MR）迭代流程

图7 Spark迭代流程

图8 Flink迭代流程

Flink自动优化迭代程序具体流程如图9所示。

图9 Flink自动优化迭代程序具体流程

社区支持

Spark社区活跃度比Flink高很多。

总结

Spark和Flink都支持实时计算，且都可基于内存计算。Spark后面最重要的核心组件仍然是Spark SQL，而在未来几次发布中，除了性能上更加优化外（包括代码生成和快速Join操作），还要提供对SQL语句的扩展和更好地集成。至于Flink，其对于流式计算和迭代计算支持力度将会更加增强。无论是Spark、还是Flink的发展重点，将是数据科学和平台API化，除了传统的统计算法外，还包括学习算法，同时使其生态系统越来越完善。

 

我们是否还需要另外一个新的数据处理引擎？当我第一次听到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这方面的更迷人的思路

 

转载于:https://my.oschina.net/hblt147/blog/2246902