這幾年大數據的飛速發展，出現了很多熱門的開源社區，其中著名的有 Hadoop、Storm，以及后來的 Spark，他們都有著各自專注的應用場景。Spark 掀開了內存計算的先河，也以內存為賭注，贏得了內存計算的飛速發展。Spark 的火熱或多或少的掩蓋了其他分布式計算的系統身影。就像 Flink，也就在這個時候默默的發展著。

在國外一些社區，有很多人將大數據的計算引擎分成了 4 代，當然，也有很多人不會認同。我們先姑且這么認為和討論。

首先第一代的計算引擎，無疑就是 Hadoop 承載的 MapReduce。這里大家應該都不會對 MapReduce 陌生，它將計算分為兩個階段，分別為 Map 和 Reduce。對于上層應用來說，就不得不想方設法去拆分算法，甚至于不得不在上層應用實現多個 Job 的串聯，以完成一個完整的算法，例如迭代計算。

由于這樣的弊端，催生了支持 DAG 框架的產生。因此，支持 DAG 的框架被劃分為第二代計算引擎。如 Tez 以及更上層的 Oozie。這里我們不去細究各種 DAG 實現之間的區別，不過對于當時的 Tez 和 Oozie 來說，大多還是批處理的任務。

接下來就是以 Spark 為代表的第三代的計算引擎。第三代計算引擎的特點主要是 Job 內部的 DAG 支持（不跨越 Job），以及強調的實時計算。在這里，很多人也會認為第三代計算引擎也能夠很好的運行批處理的 Job。

隨著第三代計算引擎的出現，促進了上層應用快速發展，例如各種迭代計算的性能以及對流計算和 SQL 等的支持。Flink 的誕生就被歸在了第四代。這應該主要表現在 Flink 對流計算的支持，以及更一步的實時性上面。當然 Flink 也可以支持 Batch 的任務，以及 DAG 的運算。

或許會有人不同意以上的分類，我覺得其實這并不重要的，重要的是體會各個框架的差異，以及更適合的場景。并進行理解，沒有哪一個框架可以完美的支持所有的場景，也就不可能有任何一個框架能完全取代另一個，就像 Spark 沒有完全取代 Hadoop，當然 Flink 也不可能取代 Spark。本文將致力描述 Flink 的原理以及應用。

Flink 簡介

很多人可能都是在 2015 年才聽到 Flink 這個詞，其實早在 2008 年，Flink 的前身已經是柏林理工大學一個研究性項目， 在 2014 被 Apache 孵化器所接受，然后迅速地成為了 ASF（Apache Software Foundation）的頂級項目之一。Flink 的最新版本目前已經更新到了 0.10.0 了，在很多人感慨 Spark 的快速發展的同時，或許我們也該為 Flink 的發展速度點個贊。

Flink 是一個針對流數據和批數據的分布式處理引擎。它主要是由 Java 代碼實現。目前主要還是依靠開源社區的貢獻而發展。對 Flink 而言，其所要處理的主要場景就是流數據，批數據只是流數據的一個極限特例而已。再換句話說，Flink 會把所有任務當成流來處理，這也是其最大的特點。Flink 可以支持本地的快速迭代，以及一些環形的迭代任務。并且 Flink 可以定制化內存管理。在這點，如果要對比 Flink 和 Spark 的話，Flink 并沒有將內存完全交給應用層。這也是為什么 Spark 相對于 Flink，更容易出現 OOM 的原因（out of memory）。就框架本身與應用場景來說，Flink 更相似與 Storm。如果之前了解過 Storm 或者 Flume 的讀者，可能會更容易理解 Flink 的架構和很多概念。下面讓我們先來看下 Flink 的架構圖。

圖 1. Flink 架構圖

如圖 1 所示，我們可以了解到 Flink 幾個最基礎的概念，Client、JobManager 和 TaskManager。Client 用來提交任務給 JobManager，JobManager 分發任務給 TaskManager 去執行，然后 TaskManager 會心跳的匯報任務狀態。看到這里，有的人應該已經有種回到 Hadoop 一代的錯覺。確實，從架構圖去看，JobManager 很像當年的 JobTracker，TaskManager 也很像當年的 TaskTracker。然而有一個最重要的區別就是 TaskManager 之間是是流（Stream）。其次，Hadoop 一代中，只有 Map 和 Reduce 之間的 Shuffle，而對 Flink 而言，可能是很多級，并且在 TaskManager 內部和 TaskManager 之間都會有數據傳遞，而不像 Hadoop，是固定的 Map 到 Reduce。

Flink 中的調度簡述

在 Flink 集群中，計算資源被定義為 Task Slot。每個 TaskManager 會擁有一個或多個 Slots。JobManager 會以 Slot 為單位調度 Task。但是這里的 Task 跟我們在 Hadoop 中的理解是有區別的。對 Flink 的 JobManager 來說，其調度的是一個 Pipeline 的 Task，而不是一個點。舉個例子，在 Hadoop 中 Map 和 Reduce 是兩個獨立調度的 Task，并且都會去占用計算資源。對 Flink 來說 MapReduce 是一個 Pipeline 的 Task，只占用一個計算資源。類同的，如果有一個 MRR 的 Pipeline Task，在 Flink 中其也是一個被整體調度的 Pipeline Task。在 TaskManager 中，根據其所擁有的 Slot 個數，同時會擁有多個 Pipeline。

在 Flink StandAlone 的部署模式中，這個還比較容易理解。因為 Flink 自身也需要簡單的管理計算資源（Slot）。當 Flink 部署在 Yarn 上面之后，Flink 并沒有弱化資源管理。也就是說這時候的 Flink 在做一些 Yarn 該做的事情。從設計角度來講，我認為這是不太合理的。如果 Yarn 的 Container 無法完全隔離 CPU 資源，這時候對 Flink 的 TaskManager 配置多個 Slot，應該會出現資源不公平利用的現象。Flink 如果想在數據中心更好的與其他計算框架共享計算資源，應該盡量不要干預計算資源的分配和定義。

需要深度學習 Flink 調度讀者，可以在 Flink 的源碼目錄中找到 flink-runtime 這個文件夾，JobManager 的 code 基本都在這里。

Flink 的生態圈

一個計算框架要有長遠的發展，必須打造一個完整的 Stack。不然就跟紙上談兵一樣，沒有任何意義。只有上層有了具體的應用，并能很好的發揮計算框架本身的優勢，那么這個計算框架才能吸引更多的資源，才會更快的進步。所以 Flink 也在努力構建自己的 Stack。

Flink 首先支持了 Scala 和 Java 的 API，Python 也正在測試中。Flink 通過 Gelly 支持了圖操作，還有機器學習的 FlinkML。Table 是一種接口化的 SQL 支持，也就是 API 支持，而不是文本化的 SQL 解析和執行。對于完整的 Stack 我們可以參考下圖。

圖 2. Flink 的 Stack

Flink 為了更廣泛的支持大數據的生態圈，其下也實現了很多 Connector 的子項目。最熟悉的，當然就是與 Hadoop HDFS 集成。其次，Flink 也宣布支持了 Tachyon、S3 以及 MapRFS。不過對于 Tachyon 以及 S3 的支持，都是通過 Hadoop HDFS 這層包裝實現的，也就是說要使用 Tachyon 和 S3，就必須有 Hadoop，而且要更改 Hadoop 的配置（core-site.xml）。如果瀏覽 Flink 的代碼目錄，我們就會看到更多 Connector 項目，例如 Flume 和 Kafka。

總結

以上是生活随笔為你收集整理的新一代大数据处理引擎 Apache Flink的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。