一. Flink的引入
這幾年大數據的飛速發展，出現了很多熱門的開源社區，其中著名的有 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 的運算。
二. Flink簡介
Apache Flink是一個框架和分佈式處理引擎，用於對無界和有界數據流進行有狀態計算。Flink設計為在所有常見的集群環境中運行，以內存速度和任何規模執行計算。
1.無界流和有界流
任何類型的數據都是作為事件流產生的。信用卡交易，傳感器測量，機器日誌或網站或移動應用程序上的用戶交互，所有這些數據都作為流生成。
數據可以作為無界或有界流處理。
- 無界流有一個開始但沒有定義的結束。它們不會在生成時終止並提供數據。必須持續處理無界流，即必須在攝取事件後立即處理事件。無法等待所有輸入數據到達，因為輸入是無界的，並且在任何時間點都不會完成。處理無界數據通常要求以特定順序（例如事件發生的順序）攝取事件，以便能夠推斷結果完整性。
- 有界流具有定義的開始和結束。可以在執行任何計算之前通過攝取所有數據來處理有界流。處理有界流不需要有序攝取，因為可以始終對有界數據集進行排序。有界流的處理也稱為批處理。
Apache Flink擅長處理無界和有界數據集。精確控制時間和狀態使Flink的運行時能夠在無界流上運行任何類型的應用程序。有界流由算法和數據結構內部處理，這些算法和數據結構專門針對固定大小的數據集而設計，從而產生出色的性能。
2.隨處部署應用程序
Apache Flink是一個分佈式系統，需要計算資源才能執行應用程序。Flink與所有常見的集群資源管理器（如Hadoop YARN，Apache Mesos和Kubernetes）集成，但也可以設置為作為獨立集群運行。
Flink旨在很好地適用於之前列出的每個資源管理器。這是通過特定於資源管理器的部署模式實現的，這些模式允許Flink以其慣用的方式與每個資源管理器進行交互。
部署Flink應用程序時，Flink會根據應用程序配置的並行性自動識別所需資源，並從資源管理器請求它們。如果發生故障，Flink會通過請求新資源來替換髮生故障的容器。提交或控制應用程序的所有通信都通過REST調用進行。這簡化了Flink在許多環境中的集成。
3.以任何比例運行應用程序
Flink旨在以任何規模運行有狀態流應用程序。應用程序可以並行化為數千個在集群中分佈和同時執行的任務。因此，應用程序可以利用幾乎無限量的CPU，主內存，磁盤和網絡IO。而且，Flink可以輕鬆維護非常大的應用程序狀態。其異步和增量檢查點算法確保對處理延遲的影響最小，同時保證一次性狀態一致性。
用戶報告了在其生產環境中運行的Flink應用程序的可擴展性數字令人印象深刻，例如
- 應用程序每天處理數萬億個事件，
- 應用程序維護多個TB的狀態，以及
- 應用程序在數千個內核的運行。
4.利用內存中的性能
有狀態Flink應用程序針對本地狀態訪問進行了優化。任務狀態始終保留在內存中，或者，如果狀態大小超過可用內存，則保存在訪問高效的磁盤上數據結構中。因此，任務通過訪問本地（通常是內存中）狀態來執行所有計算，從而產生非常低的處理延遲。Flink通過定期和異步檢查本地狀態到持久存儲來保證在出現故障時的一次狀態一致性。
5.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。
三. Flink技術特點
1. 流處理特性
支持高吞吐、低延遲、高性能的流處理
支持帶有事件時間的窗口（Window）操作
支持有狀態計算的Exactly-once語義
支持高度靈活的窗口（Window）操作，支持基於time、count、session，以及data-driven的窗口操作
支持具有Backpressure功能的持續流模型
支持基於輕量級分佈式快照（Snapshot）實現的容錯
一個運行時同時支持Batch on Streaming處理和Streaming處理
Flink在JVM內部實現了自己的內存管理
支持迭代計算
支持程序自動優化：避免特定情況下Shuffle、排序等昂貴操作，中間結果有必要進行緩存
2. API支持
對Streaming數據類應用，提供DataStream API
對批處理類應用，提供DataSet API（支持Java/Scala）
3. Libraries支持
支持機器學習（FlinkML）
支持圖分析（Gelly）
支持關係數據處理（Table）
支持複雜事件處理（CEP）
4. 整合支持
支持Flink on YARN
支持HDFS
支持來自Kafka的輸入數據
支持Apache HBase
支持Hadoop程序
支持Tachyon
支持ElasticSearch
支持RabbitMQ
支持Apache Storm
支持S3
支持XtreemFS
5. Flink生態圈
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的編程模型
Flink提供不同級別的抽象來開發流/批處理應用程序。
如果你是天津的，可以直接轉發+關注+私信我，可以到我們研究院（事業單位）來面試！
不是天津的轉發+關注+私信我回復“大數據”可以獲取下面學習資料
閱讀更多 大數據java架構師 的文章
