這幾年，在整個大資料領域，Flink可算是火得一塌糊，不但將阿里Blink中的大部分特性merge到社群的Flink中，使得Flink在流式實時計算領域更是一騎絕塵，讓其他實時計算框架只能望其項背，目前Flink根本經看不到其他的對手！同時Flink新版本又完美的相容Hive，使得Flink在離線計算也快馬加鞭，飛速趕超，完美實現批流統一，甚至很多有人稱2020年為批流統一元年！

一、什麼是Flink

• Flink簡介

Apache Flink 是一個分散式大資料處理引擎，可對有限資料流和無限資料流進行有狀態計算。可部署在各種叢集環境，對各種大小的資料規模進行快速計算。

• Flink的歷史

早在 2008 年，Flink 的前身已經是柏林理工大學一個研究性專案， 在 2014 被 Apache 孵化器所接受，然後迅速地成為了 ASF（Apache Software Foundation）的頂級專案之一。

Flink的商業公司 Data Artisans，位於柏林的，公司成立於2014年，共獲得兩輪融資共計650萬歐。該公司旨在為企業提供大規模資料處理解決方案，使企業可以管理和部署實時資料，實時反饋資料，做更快、更精準的商業決策。目前，ING, Netflix 和 Uber 等企業都通過 Data Artisans 的 Apache Flink 平臺部署大規模分散式應用，如實時資料分析、機器學習、搜尋、排序推薦和欺詐風險等。

2019年1月8日，阿里巴巴以 9000 萬歐元收購該公司！

二、Flink的特點

• 批流統一
• 支援高吞吐、低延遲、高效能的流處
• 支援帶有事件時間的視窗（Window）操作
• 支援有狀態計算的Exactly-once語義
• 支援高度靈活的視窗（Window）操作，支援基於time、count、session視窗操作
• 支援具有Backpressure功能的持續流模型
• 支援基於輕量級分散式快照（Snapshot）實現的容錯
• 支援迭代計算
• Flink在JVM內部實現了自己的記憶體管理
• 支援程式自動優化：避免特定情況下Shuffle、排序等昂貴操作，中間結果有必要進行快取

三、傳統Lambda架構的存在的問題

• 冗餘儲存
  資料將會儲存在多個系統中，增加冗餘存粗。
• 維護成本高
  每個系統的資料格式不一致，資料需要做轉換，增加維護成本，尤其是當業務到達一定量級時，維護成本劇增。
• 學習成本高
  多個系統之前需要完全打通，不同的產品有不同的開發方式，尤其是針對新人來說，需要投入更多的精力去學習多種系統，增加學習成本。

四、Flink與其他框架的對比

• spark streaming

Spark就是為離線計算而設計的，在Spark生態體系中，不論是流處理和批處理都是底層引擎都是Spark Core，Spark Streaming將微批次小任務不停的提交到Spark引擎，從而實現準實時計算，SparkStreaming只不過是一種特殊的批處理而已。

Spark Streaming存在的問題

1. 處理延遲較高
2. 對狀態的支援不完美
3. 對視窗的支援不靈活
4. 不支援EventTime

• Flink

Flink就是為實時計算而設計的，Flink可以同時實現批處理和流處理，Flink將批處理（即有有界資料）視作一種特殊的流處理。

五、Flink架構簡介

• JobManager：

也稱之為Master，用於協調分散式執行，它用來排程task，協調檢查點，協調失敗時恢復等。Flink執行時至少存在一個master，如果配置高可用模式則會存在多個master，它們其中有一個是leader，而其他的都是standby。

• TaskManager：

也稱之為Worker，用於執行一個dataflow的task、資料緩衝和Data Streams的資料交換，Flink執行時至少會存在一個TaskManager。JobManager和TaskManager可以直接執行在物理機上，或者執行YARN這樣的資源排程框架，TaskManager通過網路連線到JobManager，通過RPC通訊告知自身的可用性進而獲得任務分配。

SparkStreaming和Flink的角色對比