1. Flink的引入

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

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

首先第一代的計算引擎，無疑就是 Hadoop 承載的 MapReduce。這裏大家應該都不會對 MapReduce 陌生，它將計算分為兩個階段，分別為

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

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

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

首先，我們可以通過下面的性能測試初步了解兩個框架的性能區別，它們都可以基於內存計算框架進行實時計算，所以都擁有非常好的計算性能。經過測試，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組數據

叠代次數（縱坐標是秒，橫坐標是次數）

Spark和Flink全部都運行在Hadoop YARN上，性能為Flink > Spark > Hadoop(MR)，叠代次數越多越明顯，性能上，Flink優於Spark和Hadoop最主要的原因是Flink支持增量叠代，具有對叠代自動優化的功能。

2. 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 的架構圖。

我們可以了解到 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。

3. 技術的特點（可選）

關於Flink所支持的特性，我這裏只是通過分類的方式簡單做一下梳理，涉及到具體的一些概念及其原理會在後面的部分做詳細說明。

3.1. 流處理特性

支持高吞吐、低延遲、高性能的流處理

支持帶有事件時間的窗口（Window）操作

支持有狀態計算的Exactly-once語義

支持高度靈活的窗口（Window）操作，支持基於time、count、session，以及data-driven的窗口操作

支持具有Backpressure功能的持續流模型

支持基於輕量級分布式快照（Snapshot）實現的容錯

一個運行時同時支持Batch on Streaming處理和Streaming處理

Flink在JVM內部實現了自己的內存管理

支持叠代計算

支持程序自動優化：避免特定情況下Shuffle、排序等昂貴操作，中間結果有必要進行緩存

3.2. API支持

對Streaming數據類應用，提供DataStream API

對批處理類應用，提供DataSet API（支持Java/Scala）

3.3. Libraries支持

支持機器學習（FlinkML）

支持圖分析（Gelly）

支持關系數據處理（Table）

支持復雜事件處理（CEP）

3.4. 整合支持

支持Flink on YARN

支持HDFS

支持來自Kafka的輸入數據

支持Apache HBase

支持Hadoop程序

支持Tachyon

支持ElasticSearch

支持RabbitMQ

支持Apache Storm

支持S3

支持XtreemFS

3.5. Flink生態圈

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

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

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

Flink編程入門（一）