https://zhuanlan.zhihu.com/p/68206953
Apache Flink是新一代通用大数据处理引擎,旨在统一不同的数据负载。 听起来像Apache Spark吗? 是的。 Flink正试图解决Spark试图解决的同样问题。 这两个系统都旨在构建单一平台,可以在其中运行批处理,流媒体,交互式,图形处理,机器学习等。因此,Flink与Spark的意识形态中介没有太大差别。 但它们在实施细节方面确实存在很大差异。
下面比较Spark和Flink的不同。 一些方法在两个框架中都是相同的,而有些方法有很大不同。
1.抽象
在Spark中,对于批处理,有RDD抽象和DStream用于流式传输,这是内部RDD本身。因此,在Spark下面代表的所有数据都使用RDD抽象来表示。
在Flink中,为批处理数据集提供了数据集抽象,为流应用程序提供了DataStream。它们听起来与RDD和DStreams非常相似,但它们不是。
差异是以下几点:
在Spark中,RDD在运行时表示为java对象。随着project Tungsten的推出,它有点变化。但在Apache Flink中,数据集被表示为一个逻辑计划。这听起来很熟悉吗?是的,它们就像Spark中的Dataframe。所以在Flink中可以像使用优化器优化的一等公民那样获得像api这样的Dataframe。但是在Spark RDD之间不做任何优化。
Flink的数据集就像Spark的Dataframe API,在执行之前进行了优化。
在Spark 1.6中,数据集API被添加到spark中,这可能最终取代RDD抽象。
在Spark中,所有不同的抽象,如DStream,Dataframe都建立在RDD抽象之上。但在Flink中,Dataset和DataStream是基于顶级通用引擎构建的两个独立抽象。虽然它们模仿了类似的API,但是在DStream和RDD的情况下,无法将它们组合在一起。尽管在这方面有一些努力,但最终结果还不够明确。
不能将DataSet和DataStream组合在一起,如RDD和DStreams。
因此,虽然Flink和Spark都有类似的抽象,但它们的实现方式不同。
直到Spark 1.5,Spark使用Java堆来缓存数据。虽然项目开始时更容易,但它导致了内存不足(OOM)问题和垃圾收集(gc)暂停。因此,从1.5开始,Spark进入定制内存管理,称为project tungsten。
Flink从第一天起就开始定制内存管理。实际上,这是Spark向这个方向发展的灵感之一。不仅Flink将数据存储在它的自定义二进制布局中,它确实直接对二进制数据进行操作。在Spark中,所有数据帧操作都直接在Spark 1.5的project tungsten二进制数据上运行。
在JVM上执行自定义内存管理可以提高性能并提高资源利用率。
Spark在Scala中实现。它提供其他语言的API,如Java,Python和R。
Flink是用Java实现的。它确实提供了Scala API。
因此,与Flink相比,Spark中的选择语言更好。在Flink的一些scala API中,java抽象也是API的。这会有所改进,因为已经使scala API获得了更多用户。
Spark和Flink都模仿scala集合API。所以从表面来看,两者的API看起来非常相似。
// 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())
}
}
Apache Spark将流式处理视为快速批处理。 Apache Flink将批处理视为流处理的特殊情况。这两种方法都具有令人着迷的含义。
两种不同方法的差异或含义:
Apache Flink提供事件级处理,也称为实时流。它与Storm模型非常相似。
Spark只有不提供事件级粒度的最小批处理(mini-batch)。这种方法被称为近实时。
Spark流式处理是更快的批处理,Flink批处理是有限的流处理。
虽然大多数应用程序都可以近乎实时地使用,但很少有应用程序需要事件级实时处理。这些应用程序通常是Storm流而不是Spark流。对于他们来说,Flink将成为非常有趣的选择。
运行流处理作为更快批处理的优点之一是,我们可以在两种情况下使用相同的抽象。 Spark非常支持组合批处理和流数据,因为它们都使用RDD抽象。
在Flink的情况下,批处理和流式传输不共享相同的API抽象。因此,尽管有一些方法可以将基于历史文件的数据与流相结合,但它并不像Spark那样干净。
在许多应用中,这种能力非常重要。在这些应用程序中,Spark代替Flink流式传输。
由于最小批处理的性质,Spark现在对窗口的支持非常有限。允许根据处理时间窗口批量处理。
与其他任何系统相比,Flink提供了非常灵活的窗口系统。 Window是Flink流API的主要焦点之一。它允许基于处理时间、数据时间和无记录等的窗口。这种灵活性使Flink流API与Spark相比非常强大。
截至目前,最活跃的Spark库之一是spark-sql。 Spark提供了像Hive一样的查询语言和像DSL这样的Dataframe来查询结构化数据。它是成熟的API并且在批处理中广泛使用并且很快将在流媒体世界中使用。
截至目前,Flink Table API仅支持DSL等数据帧,并且仍处于测试阶段。有计划添加sql接口,但不确定何时会落在框架中。
目前为止,Spark与Flink相比有着不错的SQL故事。
Spark数据源API是框架中最好的API之一。数据源API使得所有智能资源如NoSQL数据库,镶木地板,优化行列(Optimized Row Columnar,ORC)成为Spark上的头等公民。此API还提供了在源级执行谓词下推(predicate push down)等高级操作的功能。
Flink仍然在很大程度上依赖于map / reduce InputFormat来进行数据源集成。虽然它是足够好的提取数据API,但它不能巧妙地利用源能力。因此Flink目前落后于目前的数据源集成技术。
Spark最受关注的功能之一就是能够有效地进行机器学习。在内存缓存和其他实现细节中,它是实现机器学习算法的真正强大的平台。
虽然ML算法是循环数据流,但它表示为Spark内部的直接非循环图。通常,没有分布式处理系统鼓励循环数据流,因为它们变得难以理解。
但是Flink对其他人采取了一些不同的方法。它们在运行时支持受控循环依赖图(cyclic dependence graph)。这使得它们与DAG表示相比以非常有效的方式表示ML算法。因此,Flink支持本机平台中的迭代,与DAG方法相比,可实现卓越的可扩展性和性能。
Apache Spark来自Map / Reduce时代,它将整个计算表示为数据作为文件集合的移动。这些文件可能作为磁盘上的阵列或物理文件驻留在内存中。这具有非常好的属性,如容错等。
但是Flink是一种新型系统,它将整个计算表示为流处理,其中数据有争议地移动而没有任何障碍。这个想法与像akka-streams这样的新的反应流系统非常相似。
Flink像批处理这样的部分已经投入生产,但其他部分如流媒体,Table API仍在不断发展。这并不是说在生产中就没人使用Flink流。
与Flink相比,Spark是一个非常成熟和完整的框架,但Flink确实带来了非常有趣的想法,如自定义内存管理,数据集API等。 Spark社区正在认识它并将这些想法融入到Spark中。 所以从这个意义上来说,Flink正在将大数据处理完全提升到下一个层次。