### 簡單介紹一下Flink
Flink 是一個框架和分佈式處理引擎，用於對無界和有界數據流進行有狀態計算。 並且 Flink 提供了數據分佈、容錯機制以及資源管理等核心功能。
Flink提供了諸多高抽象層的API以便用戶編寫分佈式任務：
-
DataSet API， 對靜態數據進行批處理操作，將靜態數據抽象成分佈式的數據集，用戶可以方便地使用Flink提供的各種操作符對分佈式數據集進行處理，支持Java、Scala和Python。
-
DataStream API，對數據流進行流處理操作，將流式的數據抽象成分佈式的數據流，用戶可以方便地對分佈式數據流進行各種操作，支持Java和Scala。
-
Table API，對結構化數據進行查詢操作，將結構化數據抽象成關係表，並通過類SQL的DSL對關係表進行各種查詢操作，支持Java和Scala。
此外，Flink 還針對特定的應用領域提供了領域庫，例如： Flink ML，Flink 的機器學習庫，提供了機器學習Pipelines API並實現了多種機器學習算法。 Gelly，Flink 的圖計算庫，提供了圖計算的相關API及多種圖計算算法實現。
### Flink 相比傳統的 Spark Streaming 有什麼區別?
Flink 是標準的實時處理引擎，基於事件驅動。而 Spark Streaming 是微批（Micro-Batch）的模型。
1. 架構模型
Spark Streaming 在運行時的主要角色包括： Master、Worker、Driver、Executor，Flink 在運行時主要包含： Jobmanager、Taskmanager和Slot。
2. 任務調度
Spark Streaming 連續不斷的生成微小的數據批次，構建有向無環圖DAG，Spark Streaming 會依次創建 DStreamGraph、JobGenerator、JobScheduler。
Flink 根據用戶提交的代碼生成 StreamGraph，經過優化生成 JobGraph，然後提交給 JobManager進行處理，JobManager 會根據 JobGraph 生成 ExecutionGraph，ExecutionGraph 是 Flink 調度最核心的數據結構，JobManager 根據 ExecutionGraph 對 Job 進行調度。
3. 時間機制
Spark Streaming 支持的時間機制有限，只支持處理時間。 Flink 支持了流處理程序在時間上的三個定義： 處理時間、事件時間、注入時間。 同時也支持 watermark 機制來處理滯後數據。
4. 容錯機制
對於 Spark Streaming 任務，我們可以設置 checkpoint，然後假如發生故障並重啓，我們可以從上次 checkpoint 之處恢復，但是這個行爲只能使得數據不丟失，可能會重複處理，不能做到恰好一次處理語義。
Flink 則使用兩階段提交協議來解決這個問題。
### Flink 的組件棧有哪些？
- DataSource ：表示數據源組件，主要用來接收數據，目前官網提供了readTextFile、socketTextStream、fromCollection以及一些第三方的Source。
- Transformation ：表示算子，主要用來對數據進行處理，比如Map、FlatMap、Filter、Reduce、Aggregation 等。
- DataSink ：表示輸出組件，主要用來把計算的結果輸出到其他存儲介質中，比如writeAsText 以及Kafka、Redis、Elasticsearch等第三方Sink組件。
### Flink 集羣都有哪些角色
Flink 程序在運行時主要有 TaskManager，JobManager，Client三種角色。 其中JobManager扮演着集羣中的管理者Master的角色，它是整個集羣的協調者，負責接收Flink Job，協調檢查點，Failover 故障恢復等，同時管理Flink集羣中從節點TaskManager。
TaskManager是實際負責執行計算的Worker，在其上執行Flink Job的一組Task，每個TaskManager負責管理其所在節點上的資源信息，如內存、磁盤、網絡，在啓動的時候將資源的狀態向JobManager彙報。
Client是Flink程序提交的客戶端，當用戶提交一個Flink程序時，會首先創建一個Client，該Client首先會對用戶提交的Flink程序進行預處理，並提交到Flink集羣中處理，所以Client需要從用戶提交的Flink程序配置中獲取JobManager的地址，並建立到JobManager的連接，將Flink Job提交給JobManager。
### Flink 資源管理中 Task Slot 的概念
在Flink架構角色中我們提到，TaskManager是實際負責執行計算的Worker，TaskManager 是一個 JVM 進程，並會以獨立的線程來執行一個task或多個subtask。 爲了控制一個 TaskManager 能接受多少個 task，Flink 提出了 Task Slot 的概念。
簡單的說，TaskManager會將自己節點上管理的資源分爲不同的Slot： 固定大小的資源子集。 這樣就避免了不同Job的Task互相競爭內存資源，但是需要主要的是，Slot只會做內存的隔離。 沒有做CPU的隔離。
### Flink 分區策略
GlobalPartitioner 數據會被分發到下游算子的第一個實例中進行處理。
ShufflePartitioner 數據會被隨機分發到下游算子的每一個實例中進行處理。
RebalancePartitioner 數據會被循環發送到下游的每一個實例中進行處理。
RescalePartitioner 這種分區器會根據上下游算子的並行度，循環的方式輸出到下游算子的每個實例。 這裏有點難以理解，假設上游並行度爲2，編號爲A和B。 下游並行度爲4，編號爲1，2，3，4。 那麼A則把數據循環發送給1和2，B則把數據循環發送給3和4。 假設上游並行度爲4，編號爲A，B，C，D。 下游並行度爲2，編號爲1，2。 那麼A和B則把數據發送給1，C和D則把數據發送給2。
BroadcastPartitioner 廣播分區會將上游數據輸出到下游算子的每個實例中。 適合於大數據集和小數據集做Jion的場景。
ForwardPartitioner ForwardPartitioner 用於將記錄輸出到下游本地的算子實例。 它要求上下游算子並行度一樣。 簡單的說，ForwardPartitioner用來做數據的控制檯打印。
KeyGroupStreamPartitioner Hash分區器。 會將數據按 Key 的 Hash 值輸出到下游算子實例中。
CustomPartitionerWrapper 用戶自定義分區器。 需要用戶自己實現Partitioner接口，來定義自己的分區邏輯。
### Flink的並行度和設置
Flink中的任務被分爲多個並行任務來執行，其中每個並行的實例處理一部分數據。 這些並行實例的數量被稱爲並行度。
我們在實際生產環境中可以從四個不同層面設置並行度：
-
操作算子層面(Operator Level)
-
執行環境層面(Execution Environment Level)
-
客戶端層面(Client Level)
-
系統層面(System Level)
需要注意的優先級： 算子層面>環境層面>客戶端層面>系統層面。
### Flink的Slot和parallelism有什麼區別
slot是指taskmanager的併發執行能力，假設我們將 taskmanager.numberOfTaskSlots 配置爲3 那麼每一個 taskmanager 中分配3個 TaskSlot, 3個 taskmanager 一共有9個TaskSlot。
parallelism是指taskmanager實際使用的併發能力。 假設我們把 parallelism.default 設置爲1，那麼9個 TaskSlot 只能用1個，有8個空閒。
### Flink重啓策略
-
固定延遲重啓策略（Fixed Delay Restart Strategy）
-
故障率重啓策略（Failure Rate Restart Strategy）
-
沒有重啓策略（No Restart Strategy）
-
Fallback重啓策略（Fallback Restart Strategy）
### Flink中的分佈式緩存
Flink實現的分佈式緩存和Hadoop有異曲同工之妙。 目的是在本地讀取文件，並把他放在 taskmanager 節點中，防止task重複拉取。
### Flink中的廣播變量
把一個dataset 數據集廣播出去，然後不同的task在節點上都能夠獲取到，這個數據在每個節點上只會存在一份。
### Flink中的狀態存儲
Flink在做計算的過程中經常需要存儲中間狀態，來避免數據丟失和狀態恢復。 選擇的狀態存儲策略不同，會影響狀態持久化如何和 checkpoint 交互。
Flink提供了三種狀態存儲方式： MemoryStateBackend、FsStateBackend、RocksDBStateBackend。