1. 什么是Apache Flink (為什么使用 Flink 替代 Spark?)

• Apache Flink 是一個開源的基于流的有狀態(tài)計算架。它是分布式地執(zhí)行的，具備低延遲、高吞吐的優(yōu)秀性能，并且非常擅長處理有狀態(tài)的復(fù)雜計算邏輯場景。

2. Flink的核心概念

• Event Streams:即事件流，事件流可以是實時的也可以是歷史的。Flink 是基于流的，但它不止能處理流，也能處理批，而流和批的輸入都是事件流，差別在于實時與批量。
• State: Flink 擅長處理有狀態(tài)的計算。通常的復(fù)雜業(yè)務(wù)邏輯都是有狀態(tài)的，它不僅要處理單一的事件，而且需要記錄一系列歷史的信息，然后進(jìn)行計算或者判斷
• Time: 最主要處理的問題是數(shù)據(jù)亂序的時候，一致性如何保證
• Snapshots: 實現(xiàn)了數(shù)據(jù)的快照、故障的恢復(fù)，保證數(shù)據(jù)一致性和作業(yè)的升級遷移等

3. 作業(yè)在很多情況下有可能會失敗。失敗之后重新去運行時，我們?nèi)绾伪ＷC數(shù)據(jù)的一致性?

• Fink 基于 Chandv-Lampot 算法，會把分布式的每一個節(jié)點的狀態(tài)保存到分布式文件系統(tǒng)里面作為 Checkpoint(檢點)，過程大致如下。首先，從數(shù)據(jù)源端開始注入 Checkpoint Barrier，它是一種比較特殊的消息。
• 然后它會跟普通的事件一樣隨著數(shù)據(jù)流去流動，當(dāng) Barrier 到達(dá)算子之后，這個算子會把它當(dāng)前的本地狀態(tài)進(jìn)行快照保存，當(dāng) Barrier流動到 Sink，所有的狀態(tài)都保存完整了之后，它就形成一個全局的快照。
• 這樣當(dāng)作業(yè)失敗之后，就可以通過遠(yuǎn)程文件系統(tǒng)里面保存的 Checkpoint 來進(jìn)行回滾:先把 Source 回滾到 Checkpoint 記錄的ofset，然后把有狀態(tài)節(jié)點當(dāng)時的狀態(tài)回滾到對應(yīng)的時間點，進(jìn)行重新計算。這樣既可以不用從頭開始計算，又能保證數(shù)據(jù)語義的一致性。

4. Flink的時間語義

• Event Time: 事件創(chuàng)建的時間
• Ingestion Time: 數(shù)據(jù)進(jìn)入Flink的時間
• Processing Time: 執(zhí)行操作算子的本地系統(tǒng)時間，與機器相關(guān)

5. Flink的API可分為哪幾層?

• SQL & Tale AP!同時適用于批處理和流處理，這意味著你可以對有界數(shù)據(jù)流和無界數(shù)據(jù)流以相同的語義進(jìn)行查詢，并產(chǎn)生相同的結(jié)果。除了基本查詢外， 它還支持自定義的標(biāo)量函數(shù)，聚合函數(shù)以及表值函數(shù)，可以滿足多樣化的查詢需求。
• DataStream & DataSet API 是 Flink 數(shù)據(jù)處理的核心 APL，支持使用 Java 語言或 Scala 語言進(jìn)行調(diào)用，提供了數(shù)據(jù)讀取，數(shù)換和數(shù)據(jù)輸出等一系列常用操作的封裝。
• Stateful Stream Processing 是最低級別的抽象，它通過 Process Function 函數(shù)內(nèi)嵌到 DataStream AP1 中。ProcessEunction 是 Elink 提供的最底層 API，具有最大的靈活性，允許開發(fā)者對于時間和狀態(tài)進(jìn)行細(xì)粒度的控制。

6. Flink運行時組件

• 1. 作業(yè)管理器 (JobManager)
  • 1.控制一個應(yīng)用程序執(zhí)行的主進(jìn)程，也就是說，每個應(yīng)用程序都會被一個不同的Jobmanager所控制執(zhí)行
  • 2.Jobmanager會先接收到要執(zhí)行的應(yīng)用程序，這個應(yīng)用程序會包括: 作業(yè)圖(Job Graph) 、邏輯數(shù)據(jù)流圖 (Logical dataflowgraph) 和打包了所有的類、庫和其它資源的JAR包。
  • 3.Jobmanager會把Jobgraph轉(zhuǎn)換成一個物理層面的數(shù)據(jù)流圖，這個圖被叫做“執(zhí)行圖”Executiongraph)，包含了所有可以并發(fā)執(zhí)3行的任務(wù)。Job Manager會向資源管理器(Resourcemanager) 請求執(zhí)行任務(wù)必要的資源，也就是任務(wù)管理器(Taskmanacer)上的插槽slot。一旦它獲取到了足夠的資源，就會將執(zhí)行圖分發(fā)到真正運行它們的 Taskmanager上。而在運行過程中Jobmanagera會負(fù)責(zé)所有需要中央?yún)f(xié)調(diào)的操作，比如說檢查點(checkpoints)的協(xié)調(diào)。
• 2. 任務(wù)管理器 (TaskManager)
  • 1.Flink中的工作進(jìn)程。通常在 Flink中會有多個Taskmanager運行，每個Taskmanager都包含了一定數(shù)量的插槽(slots)。插槽的數(shù)量限制了Taskmanager能夠執(zhí)行的任務(wù)數(shù)量。
  • 2.啟動之后，Taskmanager會向資源管理器注冊它的插槽，收到資源管理器的指令后，Taskmanager就會將一個或者多個插槽提供給Jobmanager調(diào)用。Jobmanager就可以向插槽分配任務(wù)(tasks)來執(zhí)行了。
  • 3.在執(zhí)行過程中，一個Taskmanager可以跟其它運行同一應(yīng)用程序的Taskmanager交換數(shù)據(jù)
• 3. 資源管理器 (ResourceManager)
  • 1.主要負(fù)責(zé)管理任務(wù)管理器(TaskManager)的插槽(slot)Taskmanger插槽是Flink中定義的處理資源單元
  • 2.Flink為不同的環(huán)境和資源管理工具提供了不同資源管理器，比如YARN、K8s，以及 standalone部署。
  • 3.當(dāng)Jobmanager申請插槽資源時，Resourcemanager會將有空閑插槽的Taskmanager分配給Jobmanager。如果Resourcemanager沒有足夠的插槽來滿足 Jobmanaer的請求，它還可以向資源提供平臺發(fā)起會話，以提供啟動 Taskmanager進(jìn)程的容器。

7. flink任務(wù)提交流程

• 1.Flink任務(wù)提交后，Client向HDFS上傳Flink的Jar包和配置
• 2.隨后向Yarn ResourceManager提交任務(wù)，ResourceManager分配Container資源并通知對應(yīng)的NodeManager啟動
• 3.ApplicationMaster，ApplicationMaster啟動后加載Flink的Jar包和配置構(gòu)建環(huán)境
• 4.然后啟動 JobManager，之后ApplicationMaster向ResourceManager申請資源啟動 TaskManager
• 5.ResourceManager分配Container資源后，由ApplicationMaster通知資源所在節(jié)點的NodeManager啟動TaskManager
• 6.NodeManager加載Flink的Jar包和配置構(gòu)建環(huán)境并啟動TaskManager
• 7.TaskManager啟動后向JobManager發(fā)送心跳包，并等待JobManager向其分配任務(wù)

8. flink執(zhí)行圖

Flink中的執(zhí)行圖可以分成四層: Streamgraph -> Jobgraph -> Executiongraph -> 物理執(zhí)行圖

• 1.Streamgraph: 是根據(jù)用戶通過 Stream APl編寫的代碼生成的最初的圖。用來表示程序的拓?fù)浣Y(jié)構(gòu)。
• 2.Jobgraph: Streamgraph經(jīng)過優(yōu)化后生成了 Jobgraph，提交給 Jobmanager的數(shù)據(jù)結(jié)構(gòu)。主要的優(yōu)化為，將多個符合條件的節(jié)點chain在一起作為一個節(jié)點。
• 3.Execution Graph: Jobmanager根據(jù) Jobgraph生成,是 Jbgraph的并行化版本，是調(diào)度層最核心的數(shù)據(jù)結(jié)構(gòu)。
• 4.物理執(zhí)行圖: Jobmanager根據(jù) Executiongraph對Job進(jìn)行調(diào)度后，在各個Taskmanager上部署Task后形成的“圖”，并不是一個具體的數(shù)據(jù)結(jié)構(gòu)。

9. flink的分區(qū)策略

• 按照key值分區(qū)
• 全部發(fā)往一個分區(qū)
• 廣播
• 上下游并行度一樣時一對一發(fā)送
• 隨機均勻分配
• 輪流分配

10. Flink 的狀態(tài)分為哪兩類

作為對狀態(tài)支持比較好的系統(tǒng)，F(xiàn)link內(nèi)部提供了可以使用的很多種可選的狀態(tài)原語。從大的角度看.所有狀態(tài)可以分為KeyedState和OperatorState 兩類。

11.KeyedState都有哪幾類

Keyed State 可以進(jìn)一步劃分為下面的 5 類，它們分別是
。比較常用的: ValueState、ListState、MapState
。不太常用的: ReducingState 和 AggregationState

12.Flink中watermark的概念

• watermark是一種街量Event Time進(jìn)展的機制，它是數(shù)據(jù)本身的一個隱藏屬性。通?；贓vent Time的數(shù)據(jù)，自身都包含一個timestamp.watermark是用于處理亂序事件的，而正確的處理亂序事件，通常用walermark機制結(jié)合window來實現(xiàn)。
• 流處理從事件產(chǎn)生，到流經(jīng)source，再到operator，中間是有一個過程和時間的。雖然大部分情況下，流到operator的數(shù)據(jù)都是按照事件產(chǎn)生的時間順序來的，但是也不排除由于網(wǎng)絡(luò)、背壓等原因，導(dǎo)致亂序的產(chǎn)生 ou-of-order或者說late element)。
  但是對于late element，我們又不能無限期的等下去，必須要有個機制來保證一個特定的時間后，必須發(fā)window去進(jìn)行計算了。這個特別的機制，就是watermark。

13.什么是Flink的全局快照

• 全局快照首先是一個分布式應(yīng)用，它有多個進(jìn)程分布在多個服務(wù)器上:
• 其次，它在應(yīng)用內(nèi)部有自己的處理邏輯和狀態(tài):
• 第三，應(yīng)用間是可以互相通信的:
• 第四，在這種分布式的應(yīng)用，有內(nèi)部狀態(tài)，硬件可以通信的情況下，某一時刻的全局狀態(tài)，就叫做全局的快照

14.為什么需要全局快照

• 第一，用它來做檢查點，可以定期對全局狀態(tài)做備份，當(dāng)應(yīng)用程序故障時，就可以拿來恢復(fù):
• 第二，做死鎖檢測，進(jìn)行快照后當(dāng)前的程序繼續(xù)運行，然后可以對快照進(jìn)行分 析，看應(yīng)用程序是不是存在死鎖狀態(tài)，如果是就可以進(jìn)行相應(yīng)的處理。

15.Flink的容錯機制

• Exacty once是指每條 event 會且只會對 state 產(chǎn)生一次影響，這里的“一次”并非端到端的嚴(yán)格一次，而是指在 Flink 內(nèi)部只處理一次，不包括 source和 sink 的處理。
• Atleast once，是指每條 event 會對 state 產(chǎn)生最少一次影響，也就是存在重復(fù)處理的可能。
• At most once，是指每條 event 會對 state 產(chǎn)生最多一次影響，就是狀態(tài)可能會在出錯時丟失。

16.Flink是如何實現(xiàn)End-To-End Exactly-once的?

• Flink通過狀態(tài)和兩次提交協(xié)議來保證了端到端的exactly-once語義
• Source: 支持?jǐn)?shù)據(jù)的replay，如Kafka的offset。
• Transformation: 借助于checkpoint
• Sink: Checkpoint + 兩階段事務(wù)提交

17.解釋下兩階段提交?

• 一旦Flink開始做checkpoint操作，就會進(jìn)入pre-commit “預(yù)提交”階段，同時JobManager的Coordinator會將Barrier注入數(shù)據(jù)流中
• 當(dāng)所有的barrier在算子中成功進(jìn)行一遍傳遞《就是Checkpoint完成)，并完成快照后，“預(yù)提交”階
  等所有的算子完成“預(yù)提交”
• 就會發(fā)起一個commit “提交”動作，但是任何一個“預(yù)提交” 失敗都會導(dǎo)致回滾到最近的checkooint.

18.Flink 的 checkpoint 存在哪里?

可以是內(nèi)存，文件系統(tǒng)，或者 RocksDB。

19.海量 key 去重

如果是海量數(shù)據(jù)的話，Set結(jié)構(gòu)是不現(xiàn)實的，可以考慮使用布隆過濾器來去重。

20.Flink 的 checkpoint 機制對比 spark 有什么不同和優(yōu)勢?

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

21.Flink CEP 編程中當(dāng)狀態(tài)沒有到達(dá)的時候會將數(shù)據(jù)保存在哪里?

• 在 Flink CEP 的處理邏輯中，狀態(tài)沒有滿足的和遲到的數(shù)據(jù)，都會存儲在一個 Map 數(shù)據(jù)結(jié)構(gòu)中，也就是說，如果我們限定判斷事件序列的時長為 5 分鐘，那么內(nèi)存中就會存儲 5 分鐘的數(shù)據(jù)。

22.Flink 程序在面對數(shù)據(jù)高峰期時如何處理?

使用大容量的 Kafka 把數(shù)據(jù)先放到消息隊列里面作為數(shù)據(jù)源，再使用Flink 進(jìn)行消費，不過這樣會影響到一點實時性。

23.Flink 的運行必須依賴 Hadoop組件嗎?

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

24.Flink 資源管理中 Task Slot 的概念

• 在Flink架構(gòu)角色中我們提到，TaskManager是實際負(fù)責(zé)執(zhí)行計算的Worker， TaskManager 是一個JVM 進(jìn)程，并會以獨立的線程來執(zhí)行一個task或多個subtask。為了控制一個 TaskManager 能接受多少個 task, Flink 提出了 Task Slot 的概念。
• 簡單的說，TaskManager會將自己節(jié)點上管理的資源分為不同的Slot: 固定大小的資源子集。這樣就避免了不同Job的Task互相競爭內(nèi)存資源，但是需要主要的是，Slot只會做內(nèi)存的隔離。沒有做CPU的隔離。

25.Flink的重啟策略都有哪些?

• 固定延遲重啟策略 (Fixed Delay Restart Strategy)
• 故障率重啟策略 (Failure Rate Restart Strategy)
• 沒有重啟策略(No Restart Strategy)
• Fallback重啟策略 (Fallback Restart Strategy)

26.Flink中的廣播變量，使用時需要注意什么?

• 我們知道Flink是并行的，計算過程可能不在一個 Slot 中進(jìn)行，那么有一種情況即:當(dāng)我們需要訪問同一份數(shù)據(jù)。那么Fink中的廣播變量就是為了解決這種情況。
• 我們可以把廣播變量理解為是一個公共的共享變量，我們可以把一個dataset 數(shù)據(jù)集廣播出去，然后不同的task在節(jié)點上都能夠獲取到，這個數(shù)據(jù)在每個節(jié)點上只會存在一份。

27.Flink的內(nèi)存模型

28.數(shù)據(jù)傾斜問題

• 1.keyBy之前發(fā)生數(shù)據(jù)傾斜
  如果keyBy之前就存在數(shù)據(jù)傾斜，上游算子的某些實例可能處理的數(shù)據(jù)較多，某些實例可能處理的數(shù)據(jù)較少，產(chǎn)生該情況可能是因為數(shù)據(jù)源的數(shù)據(jù)本身就不均勻，例如由于某些原因Kafka的topic中某些partition的數(shù)據(jù)量較大，某些partition的數(shù)據(jù)量較少。對于不存在kevBy的Flink任務(wù)也會出現(xiàn)該情況。
  這種情況，需要讓Flink任務(wù)強制進(jìn)行shuffle。使用shuffle、rebalance、rescale算子即可將數(shù)據(jù)均勻分配，從而解決數(shù)據(jù)傾斜的過
• 2.keyBy之后無開窗聚合數(shù)據(jù)傾斜
  map端使用狀態(tài)先預(yù)聚合，達(dá)到一定時間或者一定size后再同一輸出 (localkeyby) 。
• 3.keyBy后的窗口聚合操作存在數(shù)據(jù)傾斜
  因為使用了窗口，變成了有界數(shù)據(jù)的處理，窗口默認(rèn)是觸發(fā)時才會輸出一條結(jié)果發(fā)往下游。所以可以使用兩階段聚合的方式:第一階段聚合: key拼接隨機數(shù)前綴或后綴，進(jìn)步keyby、開窗、聚合
  第二階段聚合: 去掉隨機數(shù)前綴或后綴，按照原來的key及windowEnd作keyby、聚合。

29.Flink連接API

• union 多流合并，類型一致
• connect 兩條流分別處理，類型可不一致，可共享狀態(tài)
• join 相當(dāng)于innerjoin
• coGroup 實現(xiàn)左外連接，第一個流沒有join上，也要輸出

30.Flink-On-Yarn常見的提交模式有哪些，分別有什么優(yōu)缺點?

• 1.yarn-session 式
  這種方式需要先啟動集群，然后在提交作業(yè)，接著會向varn申請一塊空間后，資源永遠(yuǎn)保持不變。如果資源滿了，下一個就任務(wù)就無法提交，只能等到varn中其中一個作業(yè)完成后，程放了資源，那下-個作業(yè)才會正常提交，這種方式資源被限制在sesSi0n中，不能超過比較適合特定的運行環(huán)境或測試環(huán)境。
• 2.per-job模式
  這種方式直接在yarn上提交任務(wù)運行Flink作業(yè)，這種方式的好處是一個任務(wù)會對應(yīng)一個job，即每提交一個作業(yè)會根據(jù)自身的情況.向yarn中申請資源，直到作業(yè)執(zhí)行完成，并不會影響下一個作業(yè)的正常運行，除非是yarn上面沒有任何資源的情況下。一般生產(chǎn)環(huán)境是采用此方式運行。這種方式需要保證集群資源足夠。

31.Flink如何處理遲到數(shù)據(jù)

• watermark可以設(shè)置容錯時間
• window的allowedLateness方法，可以設(shè)置窗口允許外理遲到數(shù)據(jù)的時間。
• window的sideOutoutlLateData方法，可以將遲到的數(shù)據(jù)寫入側(cè)輸出流

32.Flink任務(wù)延遲高如何解決

• 在Flink的后臺任務(wù)管理中，我們可以看到Flink的那個算子和task出現(xiàn)了反壓。最主要的手段是資源調(diào)優(yōu)和算子調(diào)優(yōu)。
• 例如調(diào)大并發(fā)。
• 增加運行任務(wù)的資源?？s短窗口時長。

33.Flink Operator Chains

為了更高效地分布式執(zhí)行，F(xiàn)link會盡可能地將operator的subtask鏈接 chain) 在一起形成task。每個task在一個線程中執(zhí)行。將operatorst技成ask是非帶有效的優(yōu)化:它能減少線程之同的切授，減少消息的序列化/反成列化，減少少了是遲的同時提高整體的吞吐量。這就是我們所說的算子鏈。其實就是盡量把操作邏輯放入到同一個subtask里就是一個槽taskSlot文章來源地址http://www.zghlxwxcb.cn/news/detail-615363.html

34.Flink什么情況下才會把Operator chain在一起形成算子鏈?

• 上下游并行度一致
• 下游數(shù)據(jù)沒有其他的輸入
• 上下游節(jié)點都在同一個soltqroup中，默認(rèn)是一樣的，如果不是，單獨指定的算子資源，會獨占TaskSolt
• 沒有keyed操作
• 數(shù)據(jù)發(fā)送策路是forward
• 用戶沒有禁用chain

35.Flink中應(yīng)用在ableAPI中的UDF有幾種?

• scalar function: 針對一條record的一個字段的操作，返回一個字段。
• table function: 針對一條record的一個字段的操作，返回多個字段
• aggregate function: 針對多條記錄的一個字段操作，返回一條記錄

到了這里，關(guān)于flink面試常見題帶答案(持續(xù)更新)的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！