Flink面試突擊

大資料方面的面試總結匯總，本篇為Flink的面試總結，

一、簡單介紹一下 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的特性包括：

• 支持高吞吐、低延遲、高性能的流處理
• 支持帶有事件時間的視窗 （Window） 操作
• 支持有狀態計算的 Exactly-once 語意
• 支持基于 time、count、session 以及 data-driven 的視窗操作
• 支持具有 Backpressure 功能的持續流模型
• 支持基于輕量級分布式快照（Snapshot）實作的容錯
• 同時支持 Batch on Streaming 處理和 Streaming 處理
• Flink 在 JVM 內部實作了自己的記憶體管理支持迭代計算支持程式自動優化：避免特定情況下 Shuffle、排序等昂貴操作，中間結果有必要進行快取

二、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 統一了流和批處理？

因為flink無論是批處理還是流處理，底層都是有狀態的流處理，flink執行批處理實際上是流處理的一種特例，只不過此時的流式有界的，而流處理的流式無界的，應用于流處理上的transformation完全可以應用在batch上并且table API和sql都可以用在批處理和流處理上，只不過區別在于：

1. 容錯并不是采用的流式處理的checkpoint，而是直接重新計算
2. dataset api 處理的資料是很簡單的資料結構，而stream處理的是key/value
3. 流處理在應用 transformation 和 table api 和 sql 的時候不支持topN、limit、sort普通欄位等操作

另外從計算模型上來說：批處理每個stage只有完全處理完才會把快取中（快取+磁盤）序列化的資料發往下一個stage，而流處理是一條一條，批處理吞吐量大，流處理時效性強，而flink則是采用了折中的方式，在記憶體中劃分緩沖小塊，當小塊滿了就發往下一個stage，如果快取塊無限大，那么就是批處理了，

四、Flink是如何支持批流一體的？

本道面試題考察的其實就是一句話：Flink的開發者認為批處理是流處理的一種特殊情況，批處理是有限的流處理，Flink 使用一個引擎支持了DataSet API 和 DataStream API，

五、Flink 的運行必須依賴 Hadoop組件嗎？

Flink可以完全獨立于Hadoop，在不依賴Hadoop組件下運行，但是做為大資料的基礎設施，Hadoop體系是任何大資料框架都繞不過去的，

Flink可以集成眾多Hadooop 組件，例如Yarn、Hbase、HDFS等等，例如，Flink可以和Yarn集成做資源調度，也可以讀寫HDFS，或者利用HDFS做檢查點，

六、Flink的并行度了解嗎？Flink的并行度設定是怎樣的？

Flink中的任務被分為多個并行任務來執行，其中每個并行的實體處理一部分資料，這些并行實體的數量被稱為并行度，我們在實際生產環境中可以從四個不同層面設定并行度：

• 操作算子層面 (Operator Level)
• 執行環境層面 (Execution Environment Level)
• 客戶端層面 (Client Level)
• 系統層面 (System Level)

需要注意的優先級：算子層面>環境層面>客戶端層面>系統層面，

七、Flink的基礎編程模型了解嗎？

上圖是來自Flink官網的運行流程圖，通過上圖我們可以得知：

Flink 程式的基本構建是資料輸入來自一個 Source，Source 代表資料的輸入端，經過 Transformation 進行轉換，然后在一個或者多個Sink接收器中結束，

資料流（stream）就是一組永遠不會停止的資料記錄流，而轉換（transformation）是將一個或多個流作為輸入，并生成一個或多個輸出流的操作，執行時，Flink程式映射到 streaming dataflows，由流（streams）和轉換操作（transformation operators）組成，

八、Flink集群有哪些角色？各自有什么作用？

Flink 程式在運行時主要有 TaskManager，JobManager，Client三種角色，

• JobManager扮演著集群中的管理者Master的角色，它是整個集群的協調者，負責接收Flink Job，協調檢查點，Failover故障恢復等，同時管理Flink集群中從節點TaskManager，

  1). JobManager 接收待執行的 application，application 包含一個 JobGraph 和 JAR （包含所有需要的classes,libraries 和其他資源），

  2). JobManager 將 JobGraph 轉成 ExecutionGraph，ExecutionGraph中包含可以并發執行的 tasks，

  3). JobManager 向 ResourceManager 申請需要的資源（TaskManager slots），一旦分配到足夠的slots，則分發 tasks 到 TaskManager 執行，

  4). 執行期間，JobManager 負責中央協調，如協調checkpoint等

• TaskManager是實際負責執行計算的Worker，在其上執行Flink Job的一組Task，每個TaskManager負責管理其所在節點上的資源資訊，如記憶體、磁盤、網路，在啟動的時候將資源的狀態向JobManager匯報，

  1). 啟動之后，TaskManager 向 ResourceManager 注冊 slots 數，當接收到 ResourceManager 的分配通知后，會向 JobManager 提供一個或多個slots，

  2). 緊接著 JobManager 將 tasks 分配到 slots 執行，

  3). 執行期間，不同的 TaskManager 之間會進行資料交換

• Client是Flink程式提交的客戶端，當用戶提交一個Flink程式時，會首先創建一個Client，該Client首先會對用戶提交的Flink程式進行預處理，并提交到Flink集群中處理，所以Client需要從用戶提交的Flink程式配置中獲取JobManager的地址，并建立到JobManager的連接，將Flink Job提交給JobManager，

九、Flink的架構？

主從結構 ：Jobmanager，taskmanager兩個行程（可以把client也加進去），
集群模式： standalone，on yarn（在yarn上運行一個flink集群/提交到yarn上運行flink job）

（1）Jobmanager:

• registerTaskManager：在flink集群啟動時，taskmanager會向jobmanager注冊
• submitjob：flink程式內部通過client向jobmanager提交job，job是以jobgraph形式提交
• canceljob：請求取消一個flinkjob
• updateTaskExcutionStage：更新taskmanager中excution的狀態資訊
• requestnextinputsplit：運行在taskmanager上的task請求獲取下一個要處理的split
• jobstatuschanged：executionGraph向jobmanager發送該訊息，用來表示job的狀態變化

（2）Taskmanager:

• 注冊：向jobmnager注冊自己
• 可操作階段：該階段taskmanager可以接受并處理與task有關的訊息

（3）client:

client對用戶提交的代碼進行預處理，client將程式組裝成一個 jobgraph，它是由多個jobvertex組成的DAG，

十、Flink 的組件堆疊有哪些？

根據 Flink 官網描述，Flink 是一個分層架構的系統，每一層所包含的組件都提供了特定的抽象，用來服務于上層組件，

自下而上，每一層分別代表：

• Deploy 層：該層主要涉及了Flink的部署模式，在上圖中我們可以看出，Flink 支持包括local、Standalone、Cluster、Cloud等多種部署模式，
• Runtime 層：Runtime層提供了支持 Flink 計算的核心實作，比如：支持分布式 Stream 處理、JobGraph到ExecutionGraph的映射、調度等等，為上層API層提供基礎服務，
• API層：API 層主要實作了面向流（Stream）處理和批（Batch）處理API，其中面向流處理對應DataStream API，面向批處理對應DataSet API，后續版本，Flink有計劃將DataStream和DataSet API進行統一，
• Libraries層：該層稱為Flink應用框架層，根據API層的劃分，在API層之上構建的滿足特定應用的實作計算框架，也分別對應于面向流處理和面向批處理兩類，面向流處理支持：CEP（復雜事件處理）、基于SQL-like的操作（基于Table的關系操作）；面向批處理支持：FlinkML（機器學習庫）、Gelly（圖處理），

十一、Flink的 Checkpoint 機制詳細講一下？注意與spark的區別？

Flink 實作容錯主要靠強大的 CheckPoint 機制和 State 機制，Checkpoint 負責定時制作分布式快照、對程式中的狀態進行備份；State 用來存盤計算程序中的中間狀態，

Flink是通過checkpoint機制實作容錯，它的原理是不斷的生成分布式streaming資料流snapshot快照，在流處理失敗時通過這些snapshot可以恢復資料流處理，而flink的快照有兩個核心：

• barrier 機制：barrier是實作checkpoint的機制，
• state 狀態保存：state保存則是通過barrier這種機制進行 分布式快照 的實作，

1. barrier

barrier是checkpoint的核心，他會當做記錄打入資料流，從而將資料流分組，并沿著資料流方向向前推進，每個barrier會攜帶一個snapshotID，屬于該snapshot的記錄會被推向該barrier的前方，所以barrier之后的屬于下一個ckeckpoint期間（snapshot中）的資料，

然后當中間的operation接收到barrier后，會發送barrier到屬于該barrier的snapshot的資料流中，等到sink operation接收到該barrier后會向checkpoint coordinator確認該snapshot，直到所有的sink operation都確認了該snapshot，才會認為完成了本次checkpoint或者本次snapshot，

理解：可以認為barrier這種機制是flink實作分布式快照的手段，那么在這個程序中要記錄state快照資訊，到底有哪些資訊需要序列話呢？

在說state保存之前我們要知道flink的三種方式，

• jobmanager記憶體，不建議；
• hdfs（可以使用，同步 進行分布式快照）；
• rocksDB（異步 進行分布式快照），

除了第3種其他兩種都是同步快照，也就是說用hdfs這種方式快照是會阻塞資料處理的，只有當兩個barrier之間資料處理完成并完成快照之后才向下一個task發送資料并打入barrier n，我們不管異步快照，我們現在只說同步快照，

2. state狀態保存

state狀態保存分為兩種：

• 一種是用戶自定義狀態：也就是我們為了實作需求敲的代碼（算子），他們來創建和修改的state；
• 一種是系統狀態：此狀態可以認為資料緩沖區，比如window視窗函式，我們要知道資料處理的情況，

生成的快照現在包含：

• 對于每個并行流資料源，創建快照時流中的偏移/位置
• 對于每個運算子，存盤在快照中的狀態指標

3. stream aligning (barrier k對齊)

這個情況出現的很少，用于解決同一個Operation處理多個輸入流的情況（不是同一個資料源），這種情況下operation將先收到barrier k的資料快取起來不進行處理，只有當另一個流的barrier k到達之后再進行處理，同時opeartion會向checkpoint coordinator上報snapshot，這就是barrier k對齊，

SparkCheckpoint

spark的checkpoint的方式沒有這么復雜，直接通過記錄metadata和data的方式來進行checkpoint，從checkpoint中恢復時是決不允許修改代碼的，而sss是有些情況可以接受修改代碼的，

1. metadata checkpoint ，將定義流式計算的資訊保存到hdfs：配置、dstream操作、尚未完成的批次
2. data checkpoint ， 這就比較直接了，直接持久化RDD到hdfs，因為我們知道spark的容錯就是基于rdd的血緣關系的，而為了避免依賴關系鏈太長，spark會定期從最新的rdd中持久化資料到hdfs，

注意：如果spark程式中沒有updateStateByKey或reduceByKeyAndWindow這種帶有狀態持續改變的算子操作的時候完全可以不用對rdd進行持久化，只需要利用metadata來恢復程式即可，因為資料的丟失時可以接受的，但是如果存在狀態轉換的演算法就不行了，

十二、Flink 分布式快照 Checkpoint 的原理是什么？

Flink的分布式快照是根據Chandy-Lamport演算法量身定做的，簡單來說就是持續創建分布式資料流及其狀態的一致快照，

核心思想：是在 input source 端插入 barrier，控制 barrier 的同步來實作 snapshot 的備份 和 exactly-once 語意，

十三、Flink Checkpoint 常見失敗原因分析?

Flink Checkpoint 失敗有很多種原因，常見的失敗原因如下：

• 用戶代碼邏輯沒有對于例外處理，讓其直接在運行中拋出，比如決議 Json 例外，沒有捕獲，導致 Checkpoint失敗，或者呼叫Dubbo 超時例外等等，
• 依賴外部存盤系統，在進行資料互動時，出錯，例外沒有處理，比如輸出資料到 Kafka、Redis、HBase等，客戶端拋出了超時例外，沒有進行捕獲，Flink 任務容錯機制會再次重啟，
• 記憶體不足，頻繁GC，超出了 GC 負載的限制，比如 OOM 例外
• 網路問題、機器不可用問題等等，

從目前的具體實踐情況來看，Flink Checkpoint 例外絕大多數還是用戶代碼邏輯的問題，對于程式例外沒有正確的處理導致，所以在撰寫 Flink 實時任務時，一定要注意處理程式可能出現的各種例外，這樣，也會讓實時任務的邏輯更加的健壯，

十四、Flink 是如何保證Exactly-once語意的？

Flink通過實作 兩階段提交 和 狀態保存 來實作 端到端 的一致性語意， 分為以下幾個步驟：

• 開始事務（beginTransaction）創建一個臨時檔案夾，來寫把資料寫入到這個檔案夾里面
• 預提交（preCommit）將記憶體中快取的資料寫入檔案并關閉
• 正式提交（commit）將之前寫完的臨時檔案放入目標目錄下，這代表著最終的資料會有一些延遲
• 丟棄（abort）丟棄臨時檔案

十五、如果下級存盤不支持事務，Flink 怎么保證 exactly-once？

端到端的 exactly-once 對 sink 要求比較高，具體實作主要有冪等寫入和事務性寫入兩種方式，

• 冪等寫入的場景依賴于業務邏輯，更常見的是用事務性寫入，而事務性寫入又有預寫日志（WAL）和兩階段提交（2PC）兩種方式，
• 如果外部系統不支持事務，那么可以用預寫日志的方式，把結果資料先當成狀態保存，然后在收到 checkpoint 完成的通知時，一次性寫入 sink 系統，

十六、Flink 中的 Time 有哪幾種？

Flink中的時間有三種型別，如下圖所示：

• Event Time：是事件創建的時間，它通常由事件中的時間戳描述，例如采集的日志資料中，每一條日志都會記錄自己的生成時間，Flink通過時間戳分配器訪問事件時間戳，
• Ingestion Time：是資料進入Flink的時間，
• Processing Time：是每一個執行基于時間操作的算子的本地系統時間，與機器相關，默認的時間屬性就是Processing Time，

例如，一條日志進入Flink的時間為2021-01-22 10:00:00.123，到達Window的系統時間為2021-01-22 10:00:01.234，日志的內容如下：

2021-01-06 18:37:15.624 INFO Fail over to rm2

對于業務來說，要統計1min內的故障日志個數，哪個時間是最有意義的？—— eventTime，因為我們要根據日志的生成時間進行統計，

十七、Flink對于遲到資料是怎么處理的？

Flink中 WaterMark 和 Window 機制解決了流式資料的亂序問題，對于因為延遲而順序有誤的資料，可以根據eventTime進行業務處理，對于延遲的資料Flink也有自己的解決辦法，主要的辦法是給定一個允許延遲的時間，在該時間范圍內仍可以接受處理延遲資料：

• 設定允許延遲的時間是通過allowedLateness(lateness: Time)設定
• 保存延遲資料則是通過sideOutputLateData(outputTag: OutputTag[T])保存
• 獲取延遲資料是通過DataStream.getSideOutput(tag: OutputTag[X])獲取

十八、Flink 資源管理中 Task Slot 的概念

在Flink中每個TaskManager是一個JVM的行程, 可以在不同的執行緒中執行一個或多個子任務， 為了控制一個worker能接收多少個task，worker通過task slot（任務槽）來進行控制（一個worker至少有一個task slot），

簡單的說，TaskManager 會將自己節點上管理的資源分為不同的 Slot：固定大小的資源子集，這樣就避免了不同 Job 的 Task 互相競爭記憶體資源，但是需要主要的是，Slot 只會做記憶體的隔離，沒有做 CPU 的隔離，

TaskSlot 與 Parallelism的關系?

Slot 是指 TaskManager 最大能并發執行 的能力，
parallelism 是指 TaskManager 實際使用的并發能力，也是 Flink-Job 的實際并發能力，

十九、Flink的重啟策略了解嗎

Flink支持不同的重啟策略，這些重啟策略控制著job失敗后如何重啟：

1. 固定延遲重啟策略

   固定延遲重啟策略會嘗試一個給定的次數來重啟Job，如果超過了最大的重啟次數，Job最終將失敗，在連續的兩次重啟嘗試之間，重啟策略會等待一個固定的時間，

2. 失敗率重啟策略

   失敗率重啟策略在Job失敗后會重啟，但是超過失敗率后，Job會最終被認定失敗，在兩個連續的重啟嘗試之間，重啟策略會等待一個固定的時間，

3. 無重啟策略

   Job直接失敗，不會嘗試進行重啟，

二十、Flink是如何處理反壓的？

Flink 內部是基于 producer-consumer 模型來進行訊息傳遞的，Flink的反壓設計也是基于這個模型，Flink 使用了高效有界的分布式阻塞佇列，就像 Java 通用的阻塞佇列（BlockingQueue）一樣，下游消費者消費變慢，上游就會受到阻塞，

二十一、Flink中的狀態存盤？

Flink在做計算的程序中經常需要存盤中間狀態，來避免資料丟失和狀態恢復，選擇的狀態存盤策略不同，會影響狀態持久化如何和 checkpoint 互動，Flink提供了三種狀態存盤方式：MemoryStateBackend、FsStateBackend、RocksDBStateBackend，

二十二、Flink的記憶體管理是如何做的？

Flink 并不是將大量物件存在堆上，而是將物件都序列化到一個預分配的記憶體塊上，此外，Flink大量的使用了堆外記憶體，如果需要處理的資料超出了記憶體限制，則會將部分資料存盤到硬碟上，Flink 為了直接操作二進制資料實作了自己的序列化框架，

理論上 Flink 的記憶體管理分為三部分：

• Network Buffers：這個是在 TaskManager 啟動的時候分配的，這是一組用于快取網路資料的記憶體，每個塊是32K，默認分配 2048 個，可以通過“taskmanager.network.numberOfBuffers”修改
• Memory Manage pool：大量的 Memory Segment 塊，用于運行時的演算法（Sort/Join/Shuffle等），這部分啟動的時候就會分配，下面這段代碼，根據組態檔中的各種引數來計算記憶體的分配方法，（heap or off-heap，這個放到下節談），記憶體的分配支持預分配和 lazy load，默認懶加載的方式，
• User Code，這部分是除了 Memory Manager 之外的記憶體用于 User code 和 TaskManager
  本身的資料結構，

二十三、Flink CEP 編程中當狀態沒有到達的時候會將資料保存在哪里

在流式處理中，CEP 當然是要支持 EventTime 的，那么相對應的也要支持資料的遲到現象，也就是watermark的處理邏輯，CEP對未匹配成功的事件序列的處理，和遲到資料是類似的，在 Flink CEP的處理邏輯中，狀態沒有滿足的和遲到的資料，都會存盤在一個Map資料結構中，也就是說，如果我們限定判斷事件序列的時長為5分鐘，那么記憶體中就會存盤5分鐘的資料，這在我看來，也是對記憶體的極大損傷之一，

二十四、Flink中 window 出現資料傾斜怎么解決？

window 產生資料傾斜指的是資料在不同的視窗內堆積的資料量相差過多，本質上產生這種情況的原因是資料源頭發送的資料量速度不同導致的，出現這種情況一般通過兩種方式來解決：

• 在資料進入視窗前做預聚合
• 重新設計視窗聚合的 key

二十五、Flink 任務延時高，如何入手？

在 Flink 的后臺任務管理中，我們可以看到 Flink 的哪個算子和 task 出現了反壓，

最主要的手段是資源調優和算子調優，

• 資源調優即是對作業中的 Operator的并發數（parallelism）、CPU（core）、堆記憶體（heap_memory）等引數進行調優，
• 作業引數調優包括：并行度的設定，State 的設定，checkpoint 的設定，

二十六、Flink 計算資源調度如何實作？

TaskManager 中最細粒度的資源是 Task slot，代表了一個固定大小的資源子集，每個 TaskManager 會將其所占有的資源平分給它的 slot，

通過調整 task slot 的數量，用戶可以定義 task 之間是如何相互隔離的，每個 TaskManager 有一個 slot，也就意味著每個 task 運行在獨立的 JVM 中，每個 TaskManager 有多個 slot 的話，也就是說多個 task 運行在同一個 JVM 中，

而在同一個 JVM 行程中的 task，可以共享 TCP 連接（基于多路復用）和心跳訊息，可以減少資料的網路傳輸，也能共享一些資料結構，一定程度上減少了每個 task 的消耗， 每個 slot 可以接受單個 task，也可以接受多個連續 task 組成的 pipeline，如下圖所示，FlatMap 函式占用一個 taskslot，而 key Agg 函式和 sink 函式共用一個 taskslot，

二十七、簡單說說FlinkSQL的是如何實作的？

Flink 將 SQL 校驗、SQL 決議以及 SQL 優化交給了Apache Calcite，Calcite 在其他很多開源專案里也都應用到了，譬如 Apache Hive, Apache Drill, Apache Kylin, Cascading，Calcite 在新的架構中處于核心的地位，如下圖所示，

構建抽象語法樹的事情交給了 Calcite 去做，SQL query 會經過 Calcite 決議器轉變成 SQL 節點樹，通過驗證后構建成 Calcite 的抽象語法樹（也就是圖中的 Logical Plan），另一邊，Table API 上的呼叫會構建成 Table API 的抽象語法樹，并通過 Calcite 提供的 RelBuilder 轉變成 Calcite 的抽象語法樹，然后依次被轉換成邏輯執行計劃和物理執行計劃，在提交任務后會分發到各個 TaskManager 中運行，在運行時會使用 Janino 編譯器編譯代碼后運行，

二十八、你們的Flink集群規模多大？

大家注意，這個問題看起來是問你實際應用中的Flink集群規模，其實還隱藏著另一個問題：Flink可以支持多少節點的集群規模？

在回答這個問題時候，可以將自己生產環節中的集群規模、節點、記憶體情況說明，同時說明部署模式（一般是Flink on Yarn），除此之外，用戶也可以同時在小集群（少于5個節點）和擁有 TB 級別狀態的上千個節點上運行 Flink 任務，

參考：

flink常見面試題

Flink進入大廠面試準備，收藏這一篇就夠了

Flink 面試題

Flink面試題

Flink吐血總結，學習與面試收藏這一篇就夠了！