本篇內(nèi)容介紹了“Flink相關(guān)面試題有哪些”的有關(guān)知識(shí)，在實(shí)際案例的操作過(guò)程中，不少人都會(huì)遇到這樣的困境，接下來(lái)就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

創(chuàng)新互聯(lián)建站從2013年創(chuàng)立，先為萊陽(yáng)等服務(wù)建站，萊陽(yáng)等地企業(yè)，進(jìn)行企業(yè)商務(wù)咨詢服務(wù)。為萊陽(yáng)企業(yè)網(wǎng)站制作PC+手機(jī)+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問(wèn)題。

一、Flink Job的提交流程

用戶提交的Flink Job會(huì)被轉(zhuǎn)化成一個(gè)DAG任務(wù)運(yùn)行，分別是：StreamGraph、JobGraph、ExecutionGraph，F(xiàn)link中JobManager與TaskManager，JobManager與Client的交互是基于Akka工具包的，是通過(guò)消息驅(qū)動(dòng)。整個(gè)Flink Job的提交還包含著ActorSystem的創(chuàng)建，JobManager的啟動(dòng)，TaskManager的啟動(dòng)和注冊(cè)。

二、Flink所謂"三層圖"結(jié)構(gòu)是哪幾個(gè)"圖"？

一個(gè)Flink任務(wù)的DAG生成計(jì)算圖大致經(jīng)歷以下三個(gè)過(guò)程：

• StreamGraph
  最接近代碼所表達(dá)的邏輯層面的計(jì)算拓?fù)浣Y(jié)構(gòu)，按照用戶代碼的執(zhí)行順序向StreamExecutionEnvironment添加StreamTransformation構(gòu)成流式圖。

• JobGraph
  從StreamGraph生成，將可以串聯(lián)合并的節(jié)點(diǎn)進(jìn)行合并，設(shè)置節(jié)點(diǎn)之間的邊，安排資源共享slot槽位和放置相關(guān)聯(lián)的節(jié)點(diǎn)，上傳任務(wù)所需的文件，設(shè)置檢查點(diǎn)配置等。相當(dāng)于經(jīng)過(guò)部分初始化和優(yōu)化處理的任務(wù)圖。

• ExecutionGraph
  由JobGraph轉(zhuǎn)換而來(lái)，包含了任務(wù)具體執(zhí)行所需的內(nèi)容，是最貼近底層實(shí)現(xiàn)的執(zhí)行圖。

三、JobManger在集群中扮演了什么角色？

JobManager 負(fù)責(zé)整個(gè) Flink 集群任務(wù)的調(diào)度以及資源的管理，從客戶端中獲取提交的應(yīng)用，然后根據(jù)集群中 TaskManager 上 TaskSlot 的使用情況，為提交的應(yīng)用分配相應(yīng)的 TaskSlot 資源并命令 TaskManager 啟動(dòng)從客戶端中獲取的應(yīng)用。

JobManager 相當(dāng)于整個(gè)集群的 Master 節(jié)點(diǎn)，且整個(gè)集群有且只有一個(gè)活躍的 JobManager ，負(fù)責(zé)整個(gè)集群的任務(wù)管理和資源管理。

JobManager 和 TaskManager 之間通過(guò) Actor System 進(jìn)行通信，獲取任務(wù)執(zhí)行的情況并通過(guò) Actor System 將應(yīng)用的任務(wù)執(zhí)行情況發(fā)送給客戶端。

同時(shí)在任務(wù)執(zhí)行的過(guò)程中，F(xiàn)link JobManager 會(huì)觸發(fā) Checkpoint 操作，每個(gè) TaskManager 節(jié)點(diǎn) 收到 Checkpoint 觸發(fā)指令后，完成 Checkpoint 操作，所有的 Checkpoint 協(xié)調(diào)過(guò)程都是在 Fink JobManager 中完成。

當(dāng)任務(wù)完成后，F(xiàn)link 會(huì)將任務(wù)執(zhí)行的信息反饋給客戶端，并且釋放掉 TaskManager 中的資源以供下一次提交任務(wù)使用。

四、JobManger在集群?jiǎn)?dòng)過(guò)程中起到什么作用？

JobManager的職責(zé)主要是接收Flink作業(yè)，調(diào)度Task，收集作業(yè)狀態(tài)和管理TaskManager。它包含一個(gè)Actor，并且做如下操作：

• RegisterTaskManager: 它由想要注冊(cè)到JobManager的TaskManager發(fā)送。注冊(cè)成功會(huì)通過(guò)AcknowledgeRegistration消息進(jìn)行Ack。

• SubmitJob: 由提交作業(yè)到系統(tǒng)的Client發(fā)送。提交的信息是JobGraph形式的作業(yè)描述信息。

• CancelJob: 請(qǐng)求取消指定id的作業(yè)。成功會(huì)返回CancellationSuccess，否則返回CancellationFailure。

• UpdateTaskExecutionState: 由TaskManager發(fā)送，用來(lái)更新執(zhí)行節(jié)點(diǎn)(ExecutionVertex)的狀態(tài)。成功則返回true，否則返回false。

• RequestNextInputSplit: TaskManager上的Task請(qǐng)求下一個(gè)輸入split，成功則返回NextInputSplit，否則返回null。

• JobStatusChanged：它意味著作業(yè)的狀態(tài)(RUNNING, CANCELING, FINISHED,等)發(fā)生變化。這個(gè)消息由ExecutionGraph發(fā)送。

五、TaskManager在集群中扮演了什么角色?

TaskManager 相當(dāng)于整個(gè)集群的 Slave 節(jié)點(diǎn)，負(fù)責(zé)具體的任務(wù)執(zhí)行和對(duì)應(yīng)任務(wù)在每個(gè)節(jié)點(diǎn)上的資源申請(qǐng)和管理。

客戶端通過(guò)將編寫(xiě)好的 Flink 應(yīng)用編譯打包，提交到 JobManager，然后 JobManager 會(huì)根據(jù)已注冊(cè)在 JobManager 中 TaskManager 的資源情況，將任務(wù)分配給有資源的 TaskManager節(jié)點(diǎn)，然后啟動(dòng)并運(yùn)行任務(wù)。

TaskManager 從 JobManager 接收需要部署的任務(wù)，然后使用 Slot 資源啟動(dòng) Task，建立數(shù)據(jù)接入的網(wǎng)絡(luò)連接，接收數(shù)據(jù)并開(kāi)始數(shù)據(jù)處理。同時(shí) TaskManager 之間的數(shù)據(jù)交互都是通過(guò)數(shù)據(jù)流的方式進(jìn)行的。

可以看出，F(xiàn)link 的任務(wù)運(yùn)行其實(shí)是采用多線程的方式，這和 MapReduce 多 JVM 進(jìn)行的方式有很大的區(qū)別，F(xiàn)link 能夠極大提高 CPU 使用效率，在多個(gè)任務(wù)和 Task 之間通過(guò) TaskSlot 方式共享系統(tǒng)資源，每個(gè) TaskManager 中通過(guò)管理多個(gè) TaskSlot 資源池進(jìn)行對(duì)資源進(jìn)行有效管理。

六、TaskManager在集群?jiǎn)?dòng)過(guò)程中起到什么作用？ 

TaskManager的啟動(dòng)流程較為簡(jiǎn)單：
啟動(dòng)類：org.apache.flink.runtime.taskmanager.TaskManager
核心啟動(dòng)方法 ：selectNetworkInterfaceAndRunTaskManager
啟動(dòng)后直接向JobManager注冊(cè)自己，注冊(cè)完成后，進(jìn)行部分模塊的初始化。

七、Flink 計(jì)算資源的調(diào)度是如何實(shí)現(xiàn)的？

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

通過(guò)調(diào)整 task slot 的數(shù)量，用戶可以定義task之間是如何相互隔離的。每個(gè) TaskManager 有一個(gè)slot，也就意味著每個(gè)task運(yùn)行在獨(dú)立的 JVM 中。每個(gè) TaskManager 有多個(gè)slot的話，也就是說(shuō)多個(gè)task運(yùn)行在同一個(gè)JVM中。

而在同一個(gè)JVM進(jìn)程中的task，可以共享TCP連接（基于多路復(fù)用）和心跳消息，可以減少數(shù)據(jù)的網(wǎng)絡(luò)傳輸，也能共享一些數(shù)據(jù)結(jié)構(gòu)，一定程度上減少了每個(gè)task的消耗。
每個(gè)slot可以接受單個(gè)task，也可以接受多個(gè)連續(xù)task組成的pipeline，如下圖所示，F(xiàn)latMap函數(shù)占用一個(gè)taskslot，而key Agg函數(shù)和sink函數(shù)共用一個(gè)taskslot：

八、簡(jiǎn)述Flink的數(shù)據(jù)抽象及數(shù)據(jù)交換過(guò)程？

Flink 為了避免JVM的固有缺陷例如java對(duì)象存儲(chǔ)密度低，F(xiàn)GC影響吞吐和響應(yīng)等，實(shí)現(xiàn)了自主管理內(nèi)存。MemorySegment就是Flink的內(nèi)存抽象。默認(rèn)情況下，一個(gè)MemorySegment可以被看做是一個(gè)32kb大的內(nèi)存塊的抽象。這塊內(nèi)存既可以是JVM里的一個(gè)byte[]，也可以是堆外內(nèi)存（DirectByteBuffer）。

在MemorySegment這個(gè)抽象之上，F(xiàn)link在數(shù)據(jù)從operator內(nèi)的數(shù)據(jù)對(duì)象在向TaskManager上轉(zhuǎn)移，預(yù)備被發(fā)給下個(gè)節(jié)點(diǎn)的過(guò)程中，使用的抽象或者說(shuō)內(nèi)存對(duì)象是Buffer。

對(duì)接從Java對(duì)象轉(zhuǎn)為Buffer的中間對(duì)象是另一個(gè)抽象StreamRecord。

九、Flink 中的分布式快照機(jī)制是如何實(shí)現(xiàn)的？

Flink的容錯(cuò)機(jī)制的核心部分是制作分布式數(shù)據(jù)流和操作算子狀態(tài)的一致性快照。這些快照充當(dāng)一致性checkpoint，系統(tǒng)可以在發(fā)生故障時(shí)回滾。Flink用于制作這些快照的機(jī)制在“分布式數(shù)據(jù)流的輕量級(jí)異步快照”中進(jìn)行了描述。它受到分布式快照的標(biāo)準(zhǔn)Chandy-Lamport算法的啟發(fā)，專門(mén)針對(duì)Flink的執(zhí)行模型而定制。

barriers在數(shù)據(jù)流源處被注入并行數(shù)據(jù)流中?？煺課的barriers被插入的位置（我們稱之為Sn）是快照所包含的數(shù)據(jù)在數(shù)據(jù)源中最大位置。例如，在Apache Kafka中，此位置將是分區(qū)中最后一條記錄的偏移量。將該位置Sn報(bào)告給checkpoint協(xié)調(diào)器（Flink的JobManager）。

然后barriers向下游流動(dòng)。當(dāng)一個(gè)中間操作算子從其所有輸入流中收到快照n的barriers時(shí)，它會(huì)為快照n發(fā)出barriers進(jìn)入其所有輸出流中。一旦sink操作算子（流式DAG的末端）從其所有輸入流接收到barriers n，它就向checkpoint協(xié)調(diào)器確認(rèn)快照n完成。在所有sink確認(rèn)快照后，意味快照著已完成。

一旦完成快照n，job將永遠(yuǎn)不再向數(shù)據(jù)源請(qǐng)求Sn之前的記錄，因?yàn)榇藭r(shí)這些記錄（及其后續(xù)記錄）將已經(jīng)通過(guò)整個(gè)數(shù)據(jù)流拓?fù)?，也即是已?jīng)被處理結(jié)束。

十、簡(jiǎn)單說(shuō)說(shuō)FlinkSQL的是如何實(shí)現(xiàn)的？

Flink 將 SQL 校驗(yàn)、SQL 解析以及 SQL 優(yōu)化交給了Apache Calcite。Calcite 在其他很多開(kāi)源項(xiàng)目里也都應(yīng)用到了，譬如 Apache Hive, Apache Drill, Apache Kylin, Cascading。Calcite 在新的架構(gòu)中處于核心的地位，如下圖所示。

構(gòu)建抽象語(yǔ)法樹(shù)的事情交給了 Calcite 去做。SQL query 會(huì)經(jīng)過(guò) Calcite 解析器轉(zhuǎn)變成 SQL 節(jié)點(diǎn)樹(shù)，通過(guò)驗(yàn)證后構(gòu)建成 Calcite 的抽象語(yǔ)法樹(shù)（也就是圖中的 Logical Plan）。另一邊，Table API 上的調(diào)用會(huì)構(gòu)建成 Table API 的抽象語(yǔ)法樹(shù)，并通過(guò) Calcite 提供的 RelBuilder 轉(zhuǎn)變成 Calcite 的抽象語(yǔ)法樹(shù)。然后依次被轉(zhuǎn)換成邏輯執(zhí)行計(jì)劃和物理執(zhí)行計(jì)劃。

在提交任務(wù)后會(huì)分發(fā)到各個(gè) TaskManager 中運(yùn)行，在運(yùn)行時(shí)會(huì)使用 Janino 編譯器編譯代碼后運(yùn)行。

“Flink相關(guān)面試題有哪些”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！