感謝原文作者：http://blog.madhukaraphatak.com/introduction-to-flink-for-spark-developers-flink-vs-spark/

面向Spark開發人員的Apache Flink簡介：Flink vs Spark

世界還需要另一個大資料處理系統嗎？這是我第一次聽說Apache Flink時出現的問題。在大資料領域，我們沒有缺乏框架。但我們確實存在可以解決我們所有不同資料處理需求的內聚平臺的缺點。Apache spark似乎是城裡最好的框架，試圖解決這個問題。因此，我對另一個具有類似目標的框架的需求持懷疑態度。

在過去幾周裡，我出於好奇心開始花一些時間在叮噹上。最初，當我檢視標準示例時，它們看起來與Spark之一非常相似。所以我開始的印象是它只是另一個模仿火花功能的框架。但是當我花費越來越多的時間時，顯而易見的是，這些相同外觀的API背後幾乎沒有新穎的想法，這使得flink與火花脫穎而出。我對這些想法著迷，花了越來越多的時間來理解和探索這些想法。

許多狡猾的想法，如自定義記憶體管理，資料集API已經找到他們在Spark的家，證明這些想法真的很好。因此，理解flink可以幫助我們理解分散式資料處理的未來。

在這篇文章中，我嘗試將我對Apache flink的第一印象放在一起作為一個Spark開發者。這個咆哮/評論嚴重偏頗，因為我在Spark度過了最近兩年，並且只用了2-3周玩Apache flink。所以把我在這裡說的所有東西都拿出來。

什麼是Apache Flink？

Apache Flink是另一種新一代通用大資料處理引擎，旨在統一不同的資料負載。聽起來像Apache Spark嗎？究竟。Flink正試圖解決Spark試圖解決的同樣問題。這兩個系統都旨在構建單一平臺，您可以在其中執行批處理，流媒體，互動式，圖形處理，ML等。因此，flink與Spark的意識形態中介沒有太大差別。但是它們在實現細節方面確實存在很大差異。

因此，在下一節中，我將比較火花和叮噹的不同方面。一些方法在兩個框架中都是相同的，有些方法有很大不同。

Apache Spark與Apache Flink

1.抽象

在Spark中，對於批處理，我們有RDD抽象和DStream用於流式傳輸，這是內部RDD本身。因此，我們在Spark下面代表的所有資料都使用RDD抽象來表示。

在flink中，我們為流應用程式提供批量資料集和DataStream 資料集。它們聽起來與RDD和DStream非常相似，但它們不是。不同之處在於

• 資料集在執行時表示為計劃

在spark中，RDD在執行時表示為java物件。隨著Tungsten的推出，它有點變化。但在Apache flink中，Dataset被表示為一個邏輯計劃。這聽起來很熟悉嗎？是的，它們就像Spark中的資料幀一樣。所以在flink中，你可以像使用優化器優化的一等公民那樣獲得像api這樣的Dataframe。但是在Spark RDD之間不做任何優化。

flink的資料集就像spark的Dataframe API，在執行之前進行了優化。

在spark 1.6中，資料集API被新增到spark中，這可能最終取代RDD抽象。

• Dataset和DataStream是獨立的API

在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進入定製記憶體管理，稱為專案鎢。

Flink從第一天起就開始定製記憶體管理。實際上，這是Spark向這個方向發展的靈感之一。fl不僅可以將資料儲存在自定義二進位制佈局中，而且可以直接對二進位制資料進行操作。在spark中，所有資料幀操作都直接在1.5的鎢二進位制資料上執行。

在JVM上執行自定義記憶體管理可以提高效能並提高資源利用率。

支援的語言

Spark在Scala中實現。它提供其他語言的API，如Java，Python和R.

Flink是用Java實現的。它確實提供了Scala API。

因此，與flink相比，Spark中的選擇語言更好。在flink的一些scala API中，java抽象也是API的。我認為隨著scala API的使用者越來越多，這種情況會有所改善。我不太瞭解Spark API和Flink中的Java API，因為我很久以前就轉向了Scala。

API

Spark和Flink都模仿scala集合API。所以從表面來看，兩者的API看起來非常相似。以下是使用RDD和Dataset API的scala字數。

// 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也承認了這一事實。

Streaming

Apache Spark將流式處理視為快速批處理。Apache flink將批處理視為流處理的特殊情況。這兩種方法都具有令人著迷的含義。兩種不同方法的一些差異或含義是

• 實時與近實時

Apache flink提供事件級處理，也稱為實時流。它與Storm模型非常相似。

對於Spark，您將獲得不提供事件級粒度的迷你批處理。這種方法被稱為接近實時。

Spark流式處理是更快的批處理，Flink批處理是有限的流處理。

雖然大多數應用程式都可以近乎實時地使用，但很少有應用程式需要事件級實時處理。這些應用程式通常風暴而不是Spark流。對於他們來說，flink將成為非常有趣的選擇。

• 能夠將歷史資料與流相結合

執行流處理作為更快批處理的優點之一是，我們可以在兩種情況下使用相同的抽象。Spark非常支援組合批處理和流資料，因為它們都使用rdd抽象。

在flink的情況下，批處理和流式傳輸不共享相同的api抽象。因此，雖然有很多方法可以將基於歷史檔案的資料與流相結合，但它並不像Spark那樣簡潔。

在許多應用中，這種能力非常重要。在這些應用程式中，Spark代替Flink流式傳輸。

• 靈活的視窗

由於迷你批次的性質，到目前為止Spark中對視窗的支援非常有限。只有您可以根據處理時間視窗批量處理。

與其他任何系統相比，Flink提供了非常靈活的視窗系統。Window是flink流API的主要焦點之一。它允許基於處理時間，資料時間，沒有記錄等的視窗。這種靈活性使flink流API與spark相比非常強大。

我不確定將這些API帶到Spark是多麼容易，所以直到那時flink與Spark流相比具有更好的視窗API。

SQL介面

截至目前，最活躍的Spark庫之一是spark-sql。Spark提供了像Hive一樣的查詢語言和像DSL這樣的Dataframe來查詢結構化資料。它是成熟的API，並且在批處理和很快在流媒體世界中得到廣泛使用。

截至目前，Flink Table API僅支援像DSL這樣的資料幀，並且它仍處於測試階段。有計劃新增sql介面但不確定何時它將落在框架中。

所以到目前為止，Spark與flink相比有著不錯的sql故事。我認為，與Spark相比，flink會趕上游戲的後期。

資料來源整合

Spark資料來源API是框架中最好的API之一。資料來源API使所有智慧資源如NoSQL資料庫，鑲木地板，ORC成為火星上的頭等公民。此API還提供了在源級別執行謂詞下推等高階操作的功能。

Flink仍然在很大程度上依賴於map / reduce InputFormat來進行資料來源整合。雖然它足夠好的API來提取資料但它不能巧妙地利用源能力。因此，flink目前落後於資料來源整合。

迭代處理

Spark最受關注的功能之一就是能夠有效地進行機器學習。在記憶體快取和其他實現細節中，它是實現ML演算法的真正強大的平臺。

雖然ML演算法是迴圈資料流，但它表示為火花內部的直接非迴圈圖。通常，沒有分散式處理系統鼓勵迴圈資料流，因為它們變得難以理解。

但是flink對其他人採取了一些不同的方法。它們支援執行時的受控迴圈依賴圖。這使得它們與DAG表示相比以非常有效的方式表示ML演算法。因此，Flink支援本機平臺中的迭代，與DAG方法相比，可實現卓越的可擴充套件性和效能。

我希望火花也開始支援這個框架，這將極大地有益於ML社群。

流作為平臺與批處理作為平臺

Apache Spark來自Map / Reduce時代，它將整個計算表示為資料作為檔案集合的移動。這些檔案可能作為磁碟上的陣列或物理檔案駐留在記憶體中。這具有非常好的屬性，如容錯等。

但Flink是一種新型系統，它將整個計算表示為流處理，其中資料有爭議地移動而沒有任何障礙。這個想法非常類似於像akka-streams這樣的新的反應流系統。

雖然我的研究很有限，但是哪一個是大資料系統的未來並不是很明顯，儘管這些日子似乎正在崛起。因此，在這個意義上，flink為我們考慮大資料系統注入了新鮮空氣。

Maturity

在瞭解所有差異之後，您可能會問的一個問題是Flink生產就像Spark一樣？我認為它還沒有完全準備好。像批處理這樣的部分已經投入生產，但其他部分如流媒體，表格API仍在不斷髮展。這並不是說人們沒有在生產中使用flink流。那裡有一些勇敢的人在做那件事。但作為大眾市場工具，它需要隨著時間的推移而成熟和穩定。

總結

在這個時候，與Flink相比，Spark是一個非常成熟和完整的框架。但flink確實帶來了非常有趣的想法，如自定義記憶體管理，資料集API等。Spark社群正在認識它並將這些想法引入火花。所以從這個意義上來說，flink正在將大資料處理完全提升到下一個層次。因此，瞭解flink API和內部結構將幫助您在Spark登陸之前瞭解這種新的流模式。

相關文章

• 2018年7月12日 » Spark on Kubernetes：Native Kubernetes Integration for Spark
• 2018年7月12日 » 探索Spark DataSource V2 - 第8部分：事務性寫入
• 2018年7月12日 » 探索Spark DataSource V2 - 第7部分：Meetup Talk
• 2016年5月5日 » Flink Streaming簡介 - 第10部分：Meetup Talk
• 2016年4月28日 » Flink流媒體簡介 - 第9部分：Flink的活動時間
• 2016年4月27日 » Flink Streaming簡介 - 第8部分：瞭解Flink流中的時間