Flink VS Spark

        前几周我出于好奇花了一些时间研究了下flink。当我一看到标准示例就马上发现他和Spark其中一个例子很像。因而我认为这只是模仿实现了spark功能的另外一个框架。可是随着我研究的深刻，愈来愈清晰地发觉，有些藏匿在这个看起来很类似的API后的一些新颖的想法使得flink区别于spark。我被这些想法吸引了，而且花愈来愈多的时间搞懂和探索。

        许多flink的想法像自定义内存管理，dataset API都已经在Spark中实现了，而且被证实是很不错的。因此搞明白flink能够帮助咱们搞清楚将来分布式数据处理方面的趋势信息。

        在这篇博客中我尝试做为一名spark开发者来阐述我对于Apche flink的第一印象。这个审视是我做为一名从事Spark开发2年而仅花了2-3周的时间玩了玩Apache flink的人的一些我的看法。因此带着批判的思惟看待我如今作的事吧～

        什么是Apache Flink？

        Apache Flink是新一代的大数据处理引擎，他致力于统一不一样数据载入。他听起来像是Apache Spark吗？确实是。Flink尝试去定位Spark尝试去解决的课题。这两个系统都是向着创建单一平台，在这个平台上能够运行诸如批处理，流式，交互计算，图计算，机器学习等。因此flink和Spark的思想体系是很接近的。可是他们在实现的细节方面有着很大的区别。                

        Apache Spark VS Apache Flink

        1  抽象概念

        在Spark里，咱们使用RDD抽象模型来运行批处理，使用DStream来建立流计算任务，这些都是RDD自己带有的。因此咱们在Spark中展现的全部的数据都使用了RDD。

        在flink中，咱们使用Dataset抽象模型来运行批处理，使用DataStreams建立流应用。他们听起来比较像RDD和DStreams但其实不一样。不一样点表如今：

• Dataset做为运行时的计划体现

        在spark中RDD在运行时阶段被看成java对象。经过Tungsten的介绍，他的变化是微乎其微的。而Apache flink的Dataset是做为逻辑计划执行的。听着熟悉吗？是的，他们就像是Spark中的dataframes。因此在flink中你能够将Dataframe像API同样使用，做为使用优化器优化过的一等类公民。可是在Spark RDD中没有任何这样的优化存在。

        flink里的Dataset就像是在执行前优化了的Spark Dataframe API。

        在spark 1.6中，dataset API才加入spark，这也将会最终取代RDD。

• Dataset和DataStream是独立的API

        在Spark中像DStream和Dataframe都是创建在RDD抽象基础之上的。可是在flink中，Dataset和DataStream是创建在

        咱们不能将DataSet和DataStreams结合起来，像RDD和DStreams同样。

        故即便flink和spark拥有差很少的抽象组件，他们的实现仍是有很大差别的。

        2  内存管理

        直到spark1.5，Spark才开始使用Java堆来缓存数据。尽管对于一个项目来讲很容易开始，但结果不是报OOM错误就是gc中止了。因此自从1.5以来，spark步入自定义内存管理阶段，这个项目叫作tangsten。

        Flink总有一天也会自定义内存管理。实际上他仍是Spark往这个方向迈进的一个灵感。不只flink将他的数据存储在自定义的二进制格式中，他直接操做二进制数据。在spark中，自从1.5开始，全部的dataframe操做都是直接在tungsten二进制数据中执行的。

        在JVM上的自定义内存管理有更好的表现和更好的资源利用率。

        3  实现语言

        Spark是用Scala实现的。他也提供其余语言的APIs，这些语言有Java，Python和R。而Flink是用Java实现的。他有提供Scala的API。

        因此语言方面的选择Spark要优于flink。虽然在一些flink的scala API里，是用java实现的抽象。我认为当有更多用户的时候这一点将会获得改善。我对于Spark和Flink中的java API没有太多想法，由于我早已经转向了Scala。

        4  API

        Spark和Flink有着类似的scala集合API。因此从表面上看两个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有助于在两个框架中轻易地切换。好像在不久的未来集合API将会成为建立数据通道的标准API。甚至是Scala的发明人，Martin Odersky都认同了这个事实。

        5  流

        Apache Spark将流视为快速的批处理工具。而Apache flink将批处理视为流处理的特殊情形。 这两种都有着优雅的实现方式。不过两种接近的实现的不一样点在于

• 实时VS准实时

        Apache flink提供基于事件的处理，也叫作实时流处理。这很像Storm模型。

        而在Spark中咱们提供的最小批量处理不支持切分到事件级别粒度。这种成为准实时。

        Spark Streaming是更快的批处理，Flink批处理绑定在流处理中。

        尽管准实时系统没什么毛病，仍是有些系统须要基于事件的实时处理的。这些系统更适合用storm而不是Spark Streaming。这二者之间flink有很是有趣的选择。

• 结合历史数据和流的能力

        将流处理看成更快的批处理的一点好处在于，咱们能够在两种情形之间作相同的抽象。Spark在结合批和流数据上有着极佳的支持由于RDD抽象模型。

        在flink中，批和流不共享一样的api抽象层。因此即便有途径结合基于数据流的历史文件，但他没有Spark来的那么简洁。

        在许多应用中这种能力仍是很重要的。在这些应用中Spark代替了Flink流的地位。

• 多样的窗口函数

        因为最小批的特性，Spark中对窗口函数的支持比较局限，直到如今。你只能在基于处理时间中将批进行窗口化。

        相比于其余系统Flink提供了丰富的窗口系统。窗口函数也是flink流API的重中之重。他提供基于处理时间，数据时间，空记录等的窗口函数。这个多样性使得flink流API相比于spark要强大的多。

        我不肯定将这样的API带给Spark会不会很容易，不过直到如今flink有着相比Spark streaming更加有优点的窗口API。

        SQL interface

        目前来看Spark库中最热门的当属spark-sql了。Spark不只提供了像查询语言同样的Hive，还有用来查询结构数据的DSL同样的Dataframe。这是成熟的API而且在批处理和流世界中普遍地应用。

        如今Flink的Table API只支持像DSL的dataframe，它仍然在beta阶段。据称有计划将sql接口加进去，可是不肯定何时可以落地到框架中。

        因此如今Spark相比于flink有着不错的sql支持。我认为flink会后来居上的。

        Data source Integration

        Spark数据源API是这个框架中最好的API了。数据源API使得像NoSQL数据库，parquet，ORC这些不错的数据源做为spark中的第一等公民。固然这个API提供了像在源码级别中预测的操做的能力。

        Flink仍是很依赖于map／reduce inputFormat去作数据源的集成。尽管他是足够好的推送数据的API，可是它不能充分利用好源的能力。因此flink在数据源集成方面落后了一些。

        Iterative processing

        Spark的一个最常常被谈论到的特征就是高效处理机器学习的能力。因为能够进行内存计算，和其余的一些实现细节，以致于它确实是实现ML算法的强大平台。

        尽管ML算法在spark中是表现为直接非周期图的循环数据流。正常的没有分布式处理系统鼓励去作复杂的循环数据流运算。

        不过flink和其余框架比起来也没有多大差异。他支持在运行时控制循环依赖的图计算。相比于DAG他用了很是搞笑的方式去表现ML算法。因此Flink支持在本地平台的迭代。结果是相比于DAG的方法他更具有可扩展性和高性能。

        我但愿spark也能开始在框架中支持这个，这将会大大促进ML协会的发展。

        Stream as platform vs Batch as Platform

 

        结论

        最后总结下，Spark是更加成熟和完善的框架相比于Flink来讲。可是flink带来了譬如自定义的内存管理，像表同样的data set API这些奇妙的想法。Spark协会认识到这点，而且把他应用到spark中。这么看来flink是推进了大数据处理向下一个层次的发展。因此了解flink API和内在的机制能够帮助你了解在技术落地到Spark以前的这个新的流计算范例。