1. 簡單介紹一下Flink
Flink是一個面向流處理和批處理的分布式數據計算引擎,能夠基于同一個Flink運行,可以提供流處理和批處理兩種類型的功能。 在 Flink 的世界觀中,一切都是由流組成的,離線數據是有界的流;實時數據是一個沒有界限的流:這就是所謂的有界流和無界流。
2. Flink的運行必須依賴Hadoop組件嗎
Flink可以完全獨立于Hadoop,在不依賴Hadoop組件下運行。但是做為大數據的基礎設施,Hadoop體系是任何大數據框架都繞不過去的。Flink可以集成眾多 Hadooop 組件,例如Yarn、Hbase、HDFS等等。例如,Flink可以和Yarn集成做資源調度,也可以讀寫HDFS,或者利用HDFS做檢查點。
3. Flink集群運行時角色
Flink 運行時由兩種類型的進程組成:一個 JobManager 和一個或者多個 TaskManager。
Client 不是運行時和程序執行的一部分,而是用于準備數據流并將其發送給 JobManager。之后,客戶端可以斷開連接(分離模式),或保持連接來接收進程報告(附加模式)??蛻舳丝梢宰鳛橛|發執行 Java/Scala 程序的一部分運行,也可以在命令行進程 ./bin/flink run ...
中運行。
可以通過多種方式啟動 JobManager 和 TaskManager:直接在機器上作為 standalone 集群啟動、在容器中啟動、或者通過YARN等資源框架管理并啟動。TaskManager 連接到 JobManagers,宣布自己可用,并被分配工作。
JobManager:
JobManager 具有許多與協調 Flink 應用程序的分布式執行有關的職責:它決定何時調度下一個 task(或一組 task)、對完成的 task 或執行失敗做出反應、協調 checkpoint、并且協調從失敗中恢復等等。這個進程由三個不同的組件組成:
- ResourceManager
ResourceManager 負責 Flink 集群中的資源提供、回收、分配,管理 task slots。
- Dispatcher
Dispatcher 提供了一個 REST 接口,用來提交 Flink 應用程序執行,并為每個提交的作業啟動一個新的 JobMaster。它還運行 Flink WebUI 用來提供作業執行信息。
- JobMaster
JobMaster 負責管理單個JobGraph的執行。Flink 集群中可以同時運行多個作業,每個作業都有自己的 JobMaster。
TaskManagers:
TaskManager(也稱為 worker)執行作業流的 task,并且緩存和交換數據流。
必須始終至少有一個 TaskManager。在 TaskManager 中資源調度的最小單位是 task slot。TaskManager 中 task slot 的數量表示并發處理 task 的數量。請注意一個 task slot 中可以執行多個算子。
4. Flink相比Spark Streaming有什么區別
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 則使用兩階段提交協議來解決這個問題。
5. 介紹下Flink的容錯機制(checkpoint)
Checkpoint機制是Flink可靠性的基石,可以保證Flink集群在某個算子因為某些原因(如 異常退出)出現故障時,能夠將整個應用流圖的狀態恢復到故障之前的某一狀態,保證應用流圖狀態的一致性。Flink的Checkpoint機制原理來自“Chandy-Lamport algorithm”算法。
每個需要Checkpoint的應用在啟動時,Flink的JobManager為其創建一個 CheckpointCoordinator(檢查點協調器),CheckpointCoordinator全權負責本應用的快照制作。
CheckpointCoordinator(檢查點協調器),CheckpointCoordinator全權負責本應用的快照制作。
CheckpointCoordinator(檢查點協調器) 周期性的向該流應用的所有source算子發送 barrier(屏障)。
當某個source算子收到一個barrier時,便暫停數據處理過程,然后將自己的當前狀態制作成快照,并保存到指定的持久化存儲中,最后向CheckpointCoordinator報告自己快照制作情況,同時向自身所有下游算子廣播該barrier,恢復數據處理
下游算子收到barrier之后,會暫停自己的數據處理過程,然后將自身的相關狀態制作成快照,并保存到指定的持久化存儲中,最后向CheckpointCoordinator報告自身快照情況,同時向自身所有下游算子廣播該barrier,恢復數據處理。
每個算子按照步驟3不斷制作快照并向下游廣播,直到最后barrier傳遞到sink算子,快照制作完成。
當CheckpointCoordinator收到所有算子的報告之后,認為該周期的快照制作成功; 否則,如果在規定的時間內沒有收到所有算子的報告,則認為本周期快照制作失敗。
文章推薦:
6. Flink checkpoint與Spark Streaming的有什么區別或優勢嗎
spark streaming 的 checkpoint 僅僅是針對 driver 的故障恢復做了數據和元數據的 checkpoint。而 flink 的 checkpoint 機制 要復雜了很多,它采用的是輕量級的分布式快照,實現了每個算子的快照,及流動中的數據的快照。
7. Flink是如何保證Exactly-once語義的
Flink通過實現兩階段提交和狀態保存來實現端到端的一致性語義。分為以下幾個步驟:
開始事務(beginTransaction) 創建一個臨時文件夾,來寫把數據寫入到這個文件夾里面
預提交(preCommit)將內存中緩存的數據寫入文件并關閉
正式提交(commit)將之前寫完的臨時文件放入目標目錄下。這代表著最終的數據會有一些延遲
丟棄(abort)丟棄臨時文件
若失敗發生在預提交成功后,正式提交前。可以根據狀態來提交預提交的數據,也可刪除預提交的數據。
兩階段提交協議詳解:八張圖搞懂Flink的Exactly-once
8. 如果下級存儲不支持事務,Flink怎么保證exactly-once
端到端的exactly-once對sink要求比較高,具體實現主要有冪等寫入和事務性寫入兩種方式。
冪等寫入的場景依賴于業務邏輯,更常見的是用事務性寫入。而事務性寫入又有預寫日志(WAL)和兩階段提交(2PC)兩種方式。
如果外部系統不支持事務,那么可以用預寫日志的方式,把結果數據先當成狀態保存,然后在收到 checkpoint 完成的通知時,一次性寫入 sink 系統。
9. Flink常用的算子有哪些
分兩部分:
- 數據讀取,這是Flink流計算應用的起點,常用算子有:
從內存讀:fromElements
從文件讀:readTextFile
Socket 接入 :socketTextStream
自定義讀取:createInput
- 處理數據的算子,常用的算子包括:Map(單輸入單輸出)、FlatMap(單輸入、多輸出)、Filter(過濾)、KeyBy(分組)、Reduce(聚合)、Window(窗口)、Connect(連接)、Split(分割)等。
推薦閱讀:一文學完Flink流計算常用算子(Flink算子大全)
10. Flink任務延時高,如何入手
在 Flink 的后臺任務管理中,我們可以看到 Flink 的哪個算子和 task 出現了反壓。最主要的手段是資源調優和算子調優。資源調優即是對作業中的 Operator 的并發數(parallelism)、CPU(core)、堆內存(heap_memory)等參數進行調優。作業參數調優包括:并行度的設置,State 的設置,checkpoint 的設置。