1. 簡(jiǎn)單介紹一下Flink

Flink是一個(gè)面向流處理和批處理的分布式數(shù)據(jù)計(jì)算引擎，能夠基于同一個(gè)Flink運(yùn)行，可以提供流處理和批處理兩種類型的功能。 在 Flink 的世界觀中，一切都是由流組成的，離線數(shù)據(jù)是有界的流；實(shí)時(shí)數(shù)據(jù)是一個(gè)沒有界限的流：這就是所謂的有界流和無界流。

2. Flink的運(yùn)行必須依賴Hadoop組件嗎

Flink可以完全獨(dú)立于Hadoop，在不依賴Hadoop組件下運(yùn)行。但是做為大數(shù)據(jù)的基礎(chǔ)設(shè)施，Hadoop體系是任何大數(shù)據(jù)框架都繞不過去的。Flink可以集成眾多 Hadooop 組件，例如Yarn、Hbase、HDFS等等。例如，F(xiàn)link可以和Yarn集成做資源調(diào)度，也可以讀寫HDFS，或者利用HDFS做檢查點(diǎn)。

3. Flink集群運(yùn)行時(shí)角色

Flink 運(yùn)行時(shí)由兩種類型的進(jìn)程組成：一個(gè) JobManager 和一個(gè)或者多個(gè) TaskManager。

圖片

Client 不是運(yùn)行時(shí)和程序執(zhí)行的一部分，而是用于準(zhǔn)備數(shù)據(jù)流并將其發(fā)送給 JobManager。之后，客戶端可以斷開連接（分離模式），或保持連接來接收進(jìn)程報(bào)告（附加模式）?？蛻舳丝梢宰鳛橛|發(fā)執(zhí)行 Java/Scala 程序的一部分運(yùn)行，也可以在命令行進(jìn)程 ./bin/flink run ... 中運(yùn)行。

可以通過多種方式啟動(dòng) JobManager 和 TaskManager：直接在機(jī)器上作為 standalone 集群?jiǎn)?dòng)、在容器中啟動(dòng)、或者通過YARN等資源框架管理并啟動(dòng)。TaskManager 連接到 JobManagers，宣布自己可用，并被分配工作。

JobManager：

JobManager 具有許多與協(xié)調(diào) Flink 應(yīng)用程序的分布式執(zhí)行有關(guān)的職責(zé)：它決定何時(shí)調(diào)度下一個(gè) task（或一組 task）、對(duì)完成的 task 或執(zhí)行失敗做出反應(yīng)、協(xié)調(diào) checkpoint、并且協(xié)調(diào)從失敗中恢復(fù)等等。這個(gè)進(jìn)程由三個(gè)不同的組件組成：

• ResourceManager

ResourceManager 負(fù)責(zé) Flink 集群中的資源提供、回收、分配，管理 task slots。

• Dispatcher

Dispatcher 提供了一個(gè) REST 接口，用來提交 Flink 應(yīng)用程序執(zhí)行，并為每個(gè)提交的作業(yè)啟動(dòng)一個(gè)新的 JobMaster。它還運(yùn)行 Flink WebUI 用來提供作業(yè)執(zhí)行信息。

• JobMaster

JobMaster 負(fù)責(zé)管理單個(gè)JobGraph的執(zhí)行。Flink 集群中可以同時(shí)運(yùn)行多個(gè)作業(yè)，每個(gè)作業(yè)都有自己的 JobMaster。

TaskManagers：

TaskManager（也稱為 worker）執(zhí)行作業(yè)流的 task，并且緩存和交換數(shù)據(jù)流。

必須始終至少有一個(gè) TaskManager。在 TaskManager 中資源調(diào)度的最小單位是 task slot。TaskManager 中 task slot 的數(shù)量表示并發(fā)處理 task 的數(shù)量。請(qǐng)注意一個(gè) task slot 中可以執(zhí)行多個(gè)算子。

4. Flink相比Spark Streaming有什么區(qū)別

1. 架構(gòu)模型

Spark Streaming 在運(yùn)行時(shí)的主要角色包括：Master、Worker、Driver、Executor，F(xiàn)link 在運(yùn)行時(shí)主要包含：Jobmanager、Taskmanager 和 Slot。

2. 任務(wù)調(diào)度

Spark Streaming 連續(xù)不斷的生成微小的數(shù)據(jù)批次，構(gòu)建有向無環(huán)圖 DAG，Spark Streaming 會(huì)依次創(chuàng)建 DStreamGraph、JobGenerator、JobScheduler。

Flink 根據(jù)用戶提交的代碼生成 StreamGraph，經(jīng)過優(yōu)化生成 JobGraph，然后提交給 JobManager 進(jìn)行處理，JobManager 會(huì)根據(jù) JobGraph 生成 ExecutionGraph，ExecutionGraph 是 Flink 調(diào)度最核心的數(shù)據(jù)結(jié)構(gòu)，JobManager 根據(jù) ExecutionGraph 對(duì) Job 進(jìn)行調(diào)度。

3. 時(shí)間機(jī)制

Spark Streaming 支持的時(shí)間機(jī)制有限，只支持處理時(shí)間。Flink 支持了流處理程序在時(shí)間上的三個(gè)定義：處理時(shí)間、事件時(shí)間、注入時(shí)間。同時(shí)也支持 watermark 機(jī)制來處理滯后數(shù)據(jù)。

4. 容錯(cuò)機(jī)制

對(duì)于 Spark Streaming 任務(wù)，我們可以設(shè)置 checkpoint，然后假如發(fā)生故障并重啟，我們可以從上次 checkpoint 之處恢復(fù)，但是這個(gè)行為只能使得數(shù)據(jù)不丟失，可能會(huì)重復(fù)處理，不能做到恰一次處理語義。

Flink 則使用兩階段提交協(xié)議來解決這個(gè)問題。

5. 介紹下Flink的容錯(cuò)機(jī)制（checkpoint）

Checkpoint機(jī)制是Flink可靠性的基石，可以保證Flink集群在某個(gè)算子因?yàn)槟承┰?如 異常退出)出現(xiàn)故障時(shí)，能夠?qū)⒄麄€(gè)應(yīng)用流圖的狀態(tài)恢復(fù)到故障之前的某一狀態(tài)，保證應(yīng)用流圖狀態(tài)的一致性。Flink的Checkpoint機(jī)制原理來自“Chandy-Lamport algorithm”算法。

每個(gè)需要Checkpoint的應(yīng)用在啟動(dòng)時(shí)，F(xiàn)link的JobManager為其創(chuàng)建一個(gè) CheckpointCoordinator(檢查點(diǎn)協(xié)調(diào)器)，CheckpointCoordinator全權(quán)負(fù)責(zé)本應(yīng)用的快照制作。

CheckpointCoordinator(檢查點(diǎn)協(xié)調(diào)器)，CheckpointCoordinator全權(quán)負(fù)責(zé)本應(yīng)用的快照制作。

圖片

1. CheckpointCoordinator(檢查點(diǎn)協(xié)調(diào)器) 周期性的向該流應(yīng)用的所有source算子發(fā)送 barrier(屏障)。

2. 當(dāng)某個(gè)source算子收到一個(gè)barrier時(shí)，便暫停數(shù)據(jù)處理過程，然后將自己的當(dāng)前狀態(tài)制作成快照，并保存到指定的持久化存儲(chǔ)中，最后向CheckpointCoordinator報(bào)告自己快照制作情況，同時(shí)向自身所有下游算子廣播該barrier，恢復(fù)數(shù)據(jù)處理

3. 下游算子收到barrier之后，會(huì)暫停自己的數(shù)據(jù)處理過程，然后將自身的相關(guān)狀態(tài)制作成快照，并保存到指定的持久化存儲(chǔ)中，最后向CheckpointCoordinator報(bào)告自身快照情況，同時(shí)向自身所有下游算子廣播該barrier，恢復(fù)數(shù)據(jù)處理。

4. 每個(gè)算子按照步驟3不斷制作快照并向下游廣播，直到最后barrier傳遞到sink算子，快照制作完成。

5. 當(dāng)CheckpointCoordinator收到所有算子的報(bào)告之后，認(rèn)為該周期的快照制作成功; 否則，如果在規(guī)定的時(shí)間內(nèi)沒有收到所有算子的報(bào)告，則認(rèn)為本周期快照制作失敗。

文章推薦：

Flink可靠性的基石-checkpoint機(jī)制詳細(xì)解析

6. Flink checkpoint與Spark Streaming的有什么區(qū)別或優(yōu)勢(shì)嗎

spark streaming 的 checkpoint 僅僅是針對(duì) driver 的故障恢復(fù)做了數(shù)據(jù)和元數(shù)據(jù)的 checkpoint。而 flink 的 checkpoint 機(jī)制 要復(fù)雜了很多，它采用的是輕量級(jí)的分布式快照，實(shí)現(xiàn)了每個(gè)算子的快照，及流動(dòng)中的數(shù)據(jù)的快照。

7. Flink是如何保證Exactly-once語義的

Flink通過實(shí)現(xiàn)兩階段提交和狀態(tài)保存來實(shí)現(xiàn)端到端的一致性語義。分為以下幾個(gè)步驟：

開始事務(wù)（beginTransaction） 創(chuàng)建一個(gè)臨時(shí)文件夾，來寫把數(shù)據(jù)寫入到這個(gè)文件夾里面

預(yù)提交（preCommit）將內(nèi)存中緩存的數(shù)據(jù)寫入文件并關(guān)閉

正式提交（commit）將之前寫完的臨時(shí)文件放入目標(biāo)目錄下。這代表著最終的數(shù)據(jù)會(huì)有一些延遲

丟棄（abort）丟棄臨時(shí)文件

若失敗發(fā)生在預(yù)提交成功后，正式提交前?？梢愿鶕?jù)狀態(tài)來提交預(yù)提交的數(shù)據(jù)，也可刪除預(yù)提交的數(shù)據(jù)。

兩階段提交協(xié)議詳解：八張圖搞懂Flink的Exactly-once

8. 如果下級(jí)存儲(chǔ)不支持事務(wù)，F(xiàn)link怎么保證exactly-once

端到端的exactly-once對(duì)sink要求比較高，具體實(shí)現(xiàn)主要有冪等寫入和事務(wù)性寫入兩種方式。

冪等寫入的場(chǎng)景依賴于業(yè)務(wù)邏輯，更常見的是用事務(wù)性寫入。而事務(wù)性寫入又有預(yù)寫日志（WAL）和兩階段提交（2PC）兩種方式。

如果外部系統(tǒng)不支持事務(wù)，那么可以用預(yù)寫日志的方式，把結(jié)果數(shù)據(jù)先當(dāng)成狀態(tài)保存，然后在收到 checkpoint 完成的通知時(shí)，一次性寫入 sink 系統(tǒng)。

9. Flink常用的算子有哪些

分兩部分：

1. 數(shù)據(jù)讀取，這是Flink流計(jì)算應(yīng)用的起點(diǎn)，常用算子有：

• 從內(nèi)存讀：fromElements

• 從文件讀：readTextFile

• Socket 接入 ：socketTextStream

• 自定義讀?。篶reateInput

2. 處理數(shù)據(jù)的算子，常用的算子包括：Map（單輸入單輸出）、FlatMap（單輸入、多輸出）、Filter（過濾）、KeyBy（分組）、Reduce（聚合）、Window（窗口）、Connect（連接）、Split（分割）等。

推薦閱讀：一文學(xué)完Flink流計(jì)算常用算子（Flink算子大全）

10. Flink任務(wù)延時(shí)高，如何入手

在 Flink 的后臺(tái)任務(wù)管理中，我們可以看到 Flink 的哪個(gè)算子和 task 出現(xiàn)了反壓。最主要的手段是資源調(diào)優(yōu)和算子調(diào)優(yōu)。資源調(diào)優(yōu)即是對(duì)作業(yè)中的 Operator 的并發(fā)數(shù)（parallelism）、CPU（core）、堆內(nèi)存（heap_memory）等參數(shù)進(jìn)行調(diào)優(yōu)。作業(yè)參數(shù)調(diào)優(yōu)包括：并行度的設(shè)置，State 的設(shè)置，checkpoint 的設(shè)置。