這幾年大數據的飛速發展,出現了不少熱門的開源社區,其中著名的有 Hadoop、Storm,以及後來的 Spark,他們都有着各自專一的應用場景。Spark 掀開了內存計算的先河,也之內存爲賭注,贏得了內存計算的飛速發展。Spark 的火熱或多或少的掩蓋了其餘分佈式計算的系統身影。就像 Flink,也就在這個時候默默的發展着。html
在國外一些社區,有不少人將大數據的計算引擎分紅了 4 代,固然,也有不少人不會認同。咱們先姑且這麼認爲和討論。算法
首先第一代的計算引擎,無疑就是 Hadoop 承載的 MapReduce。這裏你們應該都不會對 MapReduce 陌生,它將計算分爲兩個階段,分別爲 Map 和 Reduce。對於上層應用來講,就不得不千方百計去拆分算法,甚至於不得不在上層應用實現多個 Job 的串聯,以完成一個完整的算法,例如迭代計算。apache
因爲這樣的弊端,催生了支持 DAG 框架的產生。所以,支持 DAG 的框架被劃分爲第二代計算引擎。如 Tez 以及更上層的 Oozie。這裏咱們不去細究各類 DAG 實現之間的區別,不過對於當時的 Tez 和 Oozie 來講,大多仍是批處理的任務。編程
接下來就是以 Spark 爲表明的第三代的計算引擎。第三代計算引擎的特色主要是 Job 內部的 DAG 支持(不跨越 Job),以及強調的實時計算。在這裏,不少人也會認爲第三代計算引擎也可以很好的運行批處理的 Job。緩存
隨着第三代計算引擎的出現,促進了上層應用快速發展,例如各類迭代計算的性能以及對流計算和 SQL 等的支持。Flink 的誕生就被歸在了第四代。這應該主要表如今 Flink 對流計算的支持,以及更一步的實時性上面。固然 Flink 也能夠支持 Batch 的任務,以及 DAG 的運算。網絡
Apache Flink是一個框架和分佈式處理引擎,用於對無界和有界數據流進行有狀態計算。Flink設計爲在全部常見的集羣環境中運行,之內存速度和任何規模執行計算。session
任何類型的數據都是做爲事件流產生的。信用卡交易,傳感器測量,機器日誌或網站或移動應用程序上的用戶交互,全部這些數據都做爲流生成。數據結構
數據能夠做爲無界或有界流處理。架構
無界流有一個開始但沒有定義的結束。它們不會在生成時終止並提供數據。必須持續處理無界流,即必須在攝取事件後當即處理事件。沒法等待全部輸入數據到達,由於輸入是無界的,而且在任什麼時候間點都不會完成。處理無界數據一般要求以特定順序(例如事件發生的順序)攝取事件,以便可以推斷結果完整性。app
有界流具備定義的開始和結束。能夠在執行任何計算以前經過攝取全部數據來處理有界流。處理有界流不須要有序攝取,由於能夠始終對有界數據集進行排序。有界流的處理也稱爲批處理。
Apache Flink擅長處理無界和有界數據集。精確控制時間和狀態使Flink的運行時可以在無界流上運行任何類型的應用程序。有界流由算法和數據結構內部處理,這些算法和數據結構專門針對固定大小的數據集而設計,從而產生出色的性能。
Apache Flink是一個分佈式系統,須要計算資源才能執行應用程序。Flink與全部常見的集羣資源管理器(如Hadoop YARN,Apache Mesos和Kubernetes)集成,但也能夠設置爲做爲獨立集羣運行。
Flink旨在很好地適用於以前列出的每一個資源管理器。這是經過特定於資源管理器的部署模式實現的,這些模式容許Flink以其慣用的方式與每一個資源管理器進行交互。
部署Flink應用程序時,Flink會根據應用程序配置的並行性自動識別所需資源,並從資源管理器請求它們。若是發生故障,Flink會經過請求新資源來替換髮生故障的容器。提交或控制應用程序的全部通訊都經過REST調用進行。這簡化了Flink在許多環境中的集成。
Flink旨在以任何規模運行有狀態流應用程序。應用程序能夠並行化爲數千個在集羣中分佈和同時執行的任務。所以,應用程序能夠利用幾乎無限量的CPU,主內存,磁盤和網絡IO。並且,Flink能夠輕鬆維護很是大的應用程序狀態。其異步和增量檢查點算法確保對處理延遲的影響最小,同時保證一次性狀態一致性。
用戶報告了在其生產環境中運行的Flink應用程序的可擴展性數字使人印象深入,例如
有狀態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。
支持高吞吐、低延遲、高性能的流處理
支持帶有事件時間的窗口(Window)操做
支持有狀態計算的Exactly-once語義
支持高度靈活的窗口(Window)操做,支持基於time、count、session,以及data-driven的窗口操做
支持具備Backpressure功能的持續流模型
支持基於輕量級分佈式快照(Snapshot)實現的容錯
一個運行時同時支持Batch on Streaming處理和Streaming處理
Flink在JVM內部實現了本身的內存管理
支持迭代計算
支持程序自動優化:避免特定狀況下Shuffle、排序等昂貴操做,中間結果有必要進行緩存
對Streaming數據類應用,提供DataStream API
對批處理類應用,提供DataSet API(支持Java/Scala)
支持機器學習(FlinkML)
支持圖分析(Gelly)
支持關係數據處理(Table)
支持復瑣事件處理(CEP)
支持Flink on YARN
支持HDFS
支持來自Kafka的輸入數據
支持Apache HBase
支持Hadoop程序
支持Tachyon
支持ElasticSearch
支持RabbitMQ
支持Apache Storm
支持S3
支持XtreemFS
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提供不一樣級別的抽象來開發流/批處理應用程序。