Flink的面試題有哪些

本篇內(nèi)容主要講解“Flink的面試題有哪些”，感興趣的朋友不妨來(lái)看看。本文介紹的方法操作簡(jiǎn)單快捷，實(shí)用性強(qiáng)。下面就讓小編來(lái)帶大家學(xué)習(xí)“Flink的面試題有哪些”吧!

1、Flink如何保證精確一次性消費(fèi)

Flink 保證精確一次性消費(fèi)主要依賴(lài)于兩種Flink機(jī)制

1、Checkpoint機(jī)制

2、二階段提交機(jī)制

Checkpoint機(jī)制

主要是當(dāng)Flink開(kāi)啟Checkpoint的時(shí)候，會(huì)往Source端插入一條barrir，然后這個(gè)barrir隨著數(shù)據(jù)流向一直流動(dòng)，當(dāng)流入到一個(gè)算子的時(shí)候，這個(gè)算子就開(kāi)始制作checkpoint，制作的是從barrir來(lái)到之前的時(shí)候當(dāng)前算子的狀態(tài)，將狀態(tài)寫(xiě)入狀態(tài)后端當(dāng)中。然后將barrir往下流動(dòng)，當(dāng)流動(dòng)到keyby 或者shuffle算子的時(shí)候，例如當(dāng)一個(gè)算子的數(shù)據(jù)，依賴(lài)于多個(gè)流的時(shí)候，這個(gè)時(shí)候會(huì)有barrir對(duì)齊，也就是當(dāng)所有的barrir都來(lái)到這個(gè)算子的時(shí)候進(jìn)行制作checkpoint，依次進(jìn)行流動(dòng)，當(dāng)流動(dòng)到sink算子的時(shí)候，并且sink算子也制作完成checkpoint會(huì)向jobmanager 報(bào)告 checkpoint n 制作完成。

二階段提交機(jī)制

Flink 提供了CheckpointedFunction與CheckpointListener這樣兩個(gè)接口，CheckpointedFunction中有snapshotState方法，每次checkpoint觸發(fā)執(zhí)行方法，通常會(huì)將緩存數(shù)據(jù)放入狀態(tài)中，可以理解為一個(gè)hook，這個(gè)方法里面可以實(shí)現(xiàn)預(yù)提交，CheckpointListyener中有notifyCheckpointComplete方法，checkpoint完成之后的通知方法，這里可以做一些額外的操作。例如FLinkKafkaConumerBase使用這個(gè)來(lái)完成Kafka offset的提交，在這個(gè)方法里面可以實(shí)現(xiàn)提交操作。在2PC中提到如果對(duì)應(yīng)流程例如某個(gè)checkpoint失敗的話，那么checkpoint就會(huì)回滾，不會(huì)影響數(shù)據(jù)一致性，那么如果在通知checkpoint成功的之后失敗了，那么就會(huì)在initalizeSate方法中完成事務(wù)的提交，這樣可以保證數(shù)據(jù)的一致性。最主要是根據(jù)checkpoint的狀態(tài)文件來(lái)判斷的。

2、flink和spark區(qū)別

flink是一個(gè)類(lèi)似spark的“開(kāi)源技術(shù)?！保?yàn)樗蔡峁┝伺幚?，流式?jì)算，圖計(jì)算，交互式查詢(xún)，機(jī)器學(xué)習(xí)等。flink也是內(nèi)存計(jì)算，比較類(lèi)似spark，但是不一樣的是，spark的計(jì)算模型基于RDD，將流式計(jì)算看成是特殊的批處理，他的DStream其實(shí)還是RDD。而flink吧批處理當(dāng)成是特殊的流式計(jì)算，但是批處理和流式計(jì)算的層的引擎是兩個(gè)，抽象了DataSet和DataStream。flink在性能上也表現(xiàn)的很好，流式計(jì)算延遲比spark少，能做到真正的流式計(jì)算，而spark只能是準(zhǔn)流式計(jì)算。而且在批處理上，當(dāng)?shù)螖?shù)變多，flink的速度比spark還要快，所以如果flink早一點(diǎn)出來(lái)，或許比現(xiàn)在的Spark更火。

3、Flink的狀態(tài)可以用來(lái)做什么？

Flink狀態(tài)主要有兩種使用方式：

1. checkpoint的數(shù)據(jù)恢復(fù)

2. 邏輯計(jì)算

4、Flink的waterMark機(jī)制，F(xiàn)link watermark傳遞機(jī)制

Flink 中的watermark機(jī)制是用來(lái)處理亂序的，flink的時(shí)間必須是event time ，有一個(gè)簡(jiǎn)單的例子就是，假如窗口是5秒，watermark是2秒，那么 總共就是7秒，這個(gè)時(shí)候什么時(shí)候會(huì)觸發(fā)計(jì)算呢，假設(shè)數(shù)據(jù)初始時(shí)間是1000，那么等到6999的時(shí)候會(huì)觸發(fā)5999窗口的計(jì)算，那么下一個(gè)就是13999的時(shí)候觸發(fā)10999的窗口

其實(shí)這個(gè)就是watermark的機(jī)制，在多并行度中，例如在kafka中會(huì)所有的分區(qū)都達(dá)到才會(huì)觸發(fā)窗口

5、Flink的時(shí)間語(yǔ)義

Event Time 事件產(chǎn)生的時(shí)間

Ingestion time 事件進(jìn)入Flink的時(shí)間

processing time 事件進(jìn)入算子的時(shí)間

6、Flink window join

1、window join，即按照指定的字段和滾動(dòng)滑動(dòng)窗口和會(huì)話窗口進(jìn)行 inner join

2、是coGoup 其實(shí)就是left join 和 right join，

3、interval join 也就是 在窗口中進(jìn)行join 有一些問(wèn)題，因?yàn)橛行?shù)據(jù)是真的會(huì)后到的，時(shí)間還很長(zhǎng)，那么這個(gè)時(shí)候就有了interval join但是必須要是事件時(shí)間，并且還要指定watermark和水位以及獲取事件時(shí)間戳。并且要設(shè)置 偏移區(qū)間，因?yàn)閖oin 也不能一直等的。

7、flink窗口函數(shù)有哪些

Tumbing window

Silding window

Session window

Count winodw

8、keyedProcessFunction 是如何工作的。假如是event time的話

keyedProcessFunction 是有一個(gè)ontime 操作的，假如是 event時(shí)間的時(shí)候 那么 調(diào)用的時(shí)間就是查看，event的watermark 是否大于 trigger time 的時(shí)間，如果大于則進(jìn)行計(jì)算，不大于就等著，如果是kafka的話，那么默認(rèn)是分區(qū)鍵最小的時(shí)間來(lái)進(jìn)行觸發(fā)。

9、flink是怎么處理離線數(shù)據(jù)的例如和離線數(shù)據(jù)的關(guān)聯(lián)？

1、async io

2、broadcast

3、async io + cache

4、open方法中讀取，然后定時(shí)線程刷新，緩存更新是先刪除，之后再來(lái)一條之后再負(fù)責(zé)寫(xiě)入緩存

10、flink支持的數(shù)據(jù)類(lèi)型

DataSet Api 和 DataStream Api、Table Api

11、Flink出現(xiàn)數(shù)據(jù)傾斜怎么辦

Flink數(shù)據(jù)傾斜如何查看：

在flink的web ui中可以看到數(shù)據(jù)傾斜的情況，就是每個(gè)subtask處理的數(shù)據(jù)量差距很大，例如有的只有一M 有的100M 這就是嚴(yán)重的數(shù)據(jù)傾斜了。

KafkaSource端發(fā)生的數(shù)據(jù)傾斜

例如上游kafka發(fā)送的時(shí)候指定的key出現(xiàn)了數(shù)據(jù)熱點(diǎn)問(wèn)題，那么就在接入之后，做一個(gè)負(fù)載均衡（前提下游不是keyby）。

聚合類(lèi)算子數(shù)據(jù)傾斜

預(yù)聚合加全局聚合

12、flink 維表關(guān)聯(lián)怎么做的

1、async io

2、broadcast

3、async io + cache

4、open方法中讀取，然后定時(shí)線程刷新，緩存更新是先刪除，之后再來(lái)一條之后再負(fù)責(zé)寫(xiě)入緩存

13、Flink checkpoint的超時(shí)問(wèn)題 如何解決。

1、是否網(wǎng)絡(luò)問(wèn)題

2、是否是barrir問(wèn)題

3、查看webui，是否有數(shù)據(jù)傾斜

4、有數(shù)據(jù)傾斜的話，那么解決數(shù)據(jù)傾斜后，會(huì)有改善，

14、flinkTopN與離線的TopN的區(qū)別

topn 無(wú)論是在離線還是在實(shí)時(shí)計(jì)算中都是比較常見(jiàn)的功能，不同于離線計(jì)算中的topn，實(shí)時(shí)數(shù)據(jù)是持續(xù)不斷的，這樣就給topn的計(jì)算帶來(lái)很大的困難，因?yàn)橐掷m(xù)在內(nèi)存中維持一個(gè)topn的數(shù)據(jù)結(jié)構(gòu)，當(dāng)有新數(shù)據(jù)來(lái)的時(shí)候，更新這個(gè)數(shù)據(jù)結(jié)構(gòu)

15、sparkstreaming 和flink 里checkpoint的區(qū)別

sparkstreaming 的checkpoint會(huì)導(dǎo)致數(shù)據(jù)重復(fù)消費(fèi)

但是flink的 checkpoint可以 保證精確一次性，同時(shí)可以進(jìn)行增量，快速的checkpoint的，有三個(gè)狀態(tài)后端，memery、rocksdb、hdfs

16、簡(jiǎn)單介紹一下cep狀態(tài)編程

Complex Event Processing（CEP）：

FLink Cep 是在FLink中實(shí)現(xiàn)的復(fù)雜時(shí)間處理庫(kù)，CEP允許在無(wú)休止的時(shí)間流中檢測(cè)事件模式，讓我們有機(jī)會(huì)掌握數(shù)據(jù)中重要的部分，一個(gè)或多個(gè)由簡(jiǎn)單事件構(gòu)成的時(shí)間流通過(guò)一定的規(guī)則匹配，然后輸出用戶(hù)想得到的數(shù)據(jù)，也就是滿(mǎn)足規(guī)則的復(fù)雜事件。

17、 Flink cep連續(xù)事件的可選項(xiàng)有什么

18、如何通過(guò)flink的CEP來(lái)實(shí)現(xiàn)支付延遲提醒

19、Flink cep 你用過(guò)哪些業(yè)務(wù)場(chǎng)景

20、cep底層如何工作

21、cep怎么老化

22、cep性能調(diào)優(yōu)

23、Flink的背壓，介紹一下Flink的反壓，你們是如何監(jiān)控和發(fā)現(xiàn)的呢。

Flink 沒(méi)有使用任何復(fù)雜的機(jī)制來(lái)解決反壓?jiǎn)栴}，F(xiàn)link 在數(shù)據(jù)傳輸過(guò)程中使用了分布式阻塞隊(duì)列。我們知道在一個(gè)阻塞隊(duì)列中，當(dāng)隊(duì)列滿(mǎn)了以后發(fā)送者會(huì)被天然阻塞住，這種阻塞功能相當(dāng)于給這個(gè)阻塞隊(duì)列提供了反壓的能力。

當(dāng)你的任務(wù)出現(xiàn)反壓時(shí)，如果你的上游是類(lèi)似 Kafka 的消息系統(tǒng)，很明顯的表現(xiàn)就是消費(fèi)速度變慢，Kafka 消息出現(xiàn)堆積。

如果你的業(yè)務(wù)對(duì)數(shù)據(jù)延遲要求并不高，那么反壓其實(shí)并沒(méi)有很大的影響。但是對(duì)于規(guī)模很大的集群中的大作業(yè)，反壓會(huì)造成嚴(yán)重的“并發(fā)癥”。首先任務(wù)狀態(tài)會(huì)變得很大，因?yàn)閿?shù)據(jù)大規(guī)模堆積在系統(tǒng)中，這些暫時(shí)不被處理的數(shù)據(jù)同樣會(huì)被放到“狀態(tài)”中。另外，F(xiàn)link 會(huì)因?yàn)閿?shù)據(jù)堆積和處理速度變慢導(dǎo)致 checkpoint 超時(shí)，而 checkpoint 是 Flink 保證數(shù)據(jù)一致性的關(guān)鍵所在，最終會(huì)導(dǎo)致數(shù)據(jù)的不一致發(fā)生。

Flink Web UI

Flink 的后臺(tái)頁(yè)面是我們發(fā)現(xiàn)反壓?jiǎn)栴}的第一選擇。Flink 的后臺(tái)頁(yè)面可以直觀、清晰地看到當(dāng)前作業(yè)的運(yùn)行狀態(tài)。

Web UI，需要注意的是，只有用戶(hù)在訪問(wèn)點(diǎn)擊某一個(gè)作業(yè)時(shí)，才會(huì)觸發(fā)反壓狀態(tài)的計(jì)算。在默認(rèn)的設(shè)置下，F(xiàn)link的TaskManager會(huì)每隔50ms觸發(fā)一次反壓狀態(tài)監(jiān)測(cè)，共監(jiān)測(cè)100次，并將計(jì)算結(jié)果反饋給JobManager，最后由JobManager進(jìn)行反壓比例的計(jì)算，然后進(jìn)行展示。

在生產(chǎn)環(huán)境中Flink任務(wù)有反壓有三種OK、LOW、HIGH

OK正常

LOW一般

HIGH高負(fù)載

24、Flink的CBO，邏輯執(zhí)行計(jì)劃和物理執(zhí)行計(jì)劃

Flink的優(yōu)化執(zhí)行其實(shí)是借鑒的數(shù)據(jù)庫(kù)的優(yōu)化器來(lái)生成的執(zhí)行計(jì)劃。

CBO，成本優(yōu)化器，代價(jià)最小的執(zhí)行計(jì)劃就是最好的執(zhí)行計(jì)劃。傳統(tǒng)的數(shù)據(jù)庫(kù)，成本優(yōu)化器做出最優(yōu)化的執(zhí)行計(jì)劃是依據(jù)統(tǒng)計(jì)信息來(lái)計(jì)算的。Flink 的成本優(yōu)化器也一樣。Flink 在提供最終執(zhí)行前，優(yōu)化每個(gè)查詢(xún)的執(zhí)行邏輯和物理執(zhí)行計(jì)劃。這些優(yōu)化工作是交給底層來(lái)完成的。根據(jù)查詢(xún)成本執(zhí)行進(jìn)一步的優(yōu)化，從而產(chǎn)生潛在的不同決策：如何排序連接，執(zhí)行哪種類(lèi)型的連接，并行度等等。

// TODO

25、Flink中數(shù)據(jù)聚合，不使用窗口怎么實(shí)現(xiàn)聚合

• valueState 用于保存單個(gè)值

• ListState 用于保存list元素

• MapState 用于保存一組鍵值對(duì)

• ReducingState 提供了和ListState相同的方法，返回一個(gè)ReducingFunction聚合后的值。

• AggregatingState和 ReducingState類(lèi)似，返回一個(gè)AggregatingState內(nèi)部聚合后的值

26、Flink中state有哪幾種存儲(chǔ)方式

Memery、RocksDB、HDFS

27、Flink 異常數(shù)據(jù)怎么處理

異常數(shù)據(jù)在我們的場(chǎng)景中，一般分為缺失字段和異常值數(shù)據(jù)。

異常值： 例如寶寶的年齡的數(shù)據(jù)，例如對(duì)于母嬰行業(yè)來(lái)講，一個(gè)寶寶的年齡是一個(gè)至關(guān)重要的數(shù)據(jù)，可以說(shuō)是最重要的，因?yàn)閷殞毚笥?歲幾乎就不會(huì)在母嬰上面購(gòu)買(mǎi)物品。像我們的有當(dāng)日、未知、以及很久的時(shí)間。這樣都屬于異常字段，這些數(shù)據(jù)我們會(huì)展示出來(lái)給店長(zhǎng)和區(qū)域經(jīng)理看，讓他們知道多少個(gè)年齡是不準(zhǔn)的。如果要處理的話，可以根據(jù)他購(gòu)買(mǎi)的時(shí)間來(lái)進(jìn)行實(shí)時(shí)矯正，例如孕婦服裝、奶粉的段位、紙尿褲的大小，以及奶嘴啊一些能夠區(qū)分年齡段的來(lái)進(jìn)行處理。我們并沒(méi)有實(shí)時(shí)處理這些數(shù)據(jù)，我們會(huì)有一個(gè)底層的策略任務(wù)夜維去跑，一個(gè)星期跑一次。

缺失字段： 例如有的字段真的缺失的很厲害，能修補(bǔ)就修補(bǔ)。不能修補(bǔ)就放棄，就像上家公司中的新聞推薦過(guò)濾器。

28、Flink 監(jiān)控你們?cè)趺醋龅?/h5>

1、我們監(jiān)控了Flink的任務(wù)是否停止

2、我們監(jiān)控了Flink的Kafka的LAG

3、我們會(huì)進(jìn)行實(shí)時(shí)數(shù)據(jù)對(duì)賬，例如銷(xiāo)售額。

29、Flink 有數(shù)據(jù)丟失的可能嗎

Flink有三種數(shù)據(jù)消費(fèi)語(yǔ)義：

1. At Most Once 最多消費(fèi)一次 發(fā)生故障有可能丟失

2. At Least Once 最少一次 發(fā)生故障有可能重復(fù)

3. Exactly-Once 精確一次 如果產(chǎn)生故障，也能保證數(shù)據(jù)不丟失不重復(fù)。

flink 新版本已經(jīng)不提供 At-Most-Once 語(yǔ)義。

30、Flink interval join 你能簡(jiǎn)單的寫(xiě)一寫(xiě)嗎

DataStream<T> keyed1 = ds1.keyBy(o -> o.getString("key"))
DataStream<T> keyed2 = ds2.keyBy(o -> o.getString("key"))
//右邊時(shí)間戳-5s<=左邊流時(shí)間戳<=右邊時(shí)間戳-1s
keyed1.intervalJoin(keyed2).between(Time.milliseconds(-5), Time.milliseconds(5))

31、Flink 提交的時(shí)候 并行度如何制定，以及資源如何配置

并行度根據(jù)kafka topic的并行度，一個(gè)并行度3個(gè)G

32、Flink的boardcast join 的原理是什么

利用 broadcast State 將維度數(shù)據(jù)流廣播到下游所有 task 中。這個(gè) broadcast 的流可以與我們的事件流進(jìn)行 connect，然后在后續(xù)的 process 算子中進(jìn)行關(guān)聯(lián)操作即可。

33、flink的source端斷了，比如kafka出故障，沒(méi)有數(shù)據(jù)發(fā)過(guò)來(lái)，怎么處理？

會(huì)有報(bào)警，監(jiān)控的kafka偏移量也就是LAG。

34、flink有什么常用的流的API?

window join 啊 cogroup 啊 map flatmap，async io 等

35、flink的水位線，你了解嗎，能簡(jiǎn)單介紹一下嗎

Flink 的watermark是一種延遲觸發(fā)的機(jī)制。

一般watermark是和window結(jié)合來(lái)進(jìn)行處理亂序數(shù)據(jù)的，Watermark最根本就是一個(gè)時(shí)間機(jī)制，例如我設(shè)置最大亂序時(shí)間為2s，窗口時(shí)間為5秒，那么就是當(dāng)事件時(shí)間大于7s的時(shí)候會(huì)觸發(fā)窗口。當(dāng)然假如有數(shù)據(jù)分區(qū)的情況下，例如kafka中接入watermake的話，那么watermake是會(huì)流動(dòng)的，取的是所有分區(qū)中最小的watermake進(jìn)行流動(dòng)，因?yàn)橹挥凶钚〉哪軌虮ＷC，之前的數(shù)據(jù)都已經(jīng)來(lái)到了，可以觸發(fā)計(jì)算了。

36、Flink怎么維護(hù)Checkpoint？在HDFS上存儲(chǔ)的話會(huì)有小文件嗎

默認(rèn)情況下，如果設(shè)置了Checkpoint選項(xiàng)，F(xiàn)link只保留最近成功生成的1個(gè)Checkpoint。當(dāng)Flink程序失敗時(shí)，可以從最近的這個(gè)Checkpoint來(lái)進(jìn)行恢復(fù)。但是，如果我們希望保留多個(gè)Checkpoint，并能夠根據(jù)實(shí)際需要選擇其中一個(gè)進(jìn)行恢復(fù)，這樣會(huì)更加靈活。Flink支持保留多個(gè)Checkpoint，需要在Flink的配置文件conf/flink-conf.yaml中，添加如下配置指定最多需要保存Checkpoint的個(gè)數(shù)。

關(guān)于小文件問(wèn)題可以參考代達(dá)羅斯之殤-大數(shù)據(jù)領(lǐng)域小文件問(wèn)題解決攻略。

37、Spark和Flink的序列化，有什么區(qū)別嗎？

Spark 默認(rèn)使用的是 Java序列化機(jī)制，同時(shí)還有優(yōu)化的機(jī)制，也就是kryo

Flink是自己實(shí)現(xiàn)的序列化機(jī)制，也就是TypeInformation

38、Flink是怎么處理遲到數(shù)據(jù)的？但是實(shí)際開(kāi)發(fā)中不能有數(shù)據(jù)遲到，怎么做？

Flink 的watermark是一種延遲觸發(fā)的機(jī)制。

一般watermark是和window結(jié)合來(lái)進(jìn)行處理亂序數(shù)據(jù)的，Watermark最根本就是一個(gè)時(shí)間機(jī)制，例如我設(shè)置最大亂序時(shí)間為2s，窗口時(shí)間為5秒，那么就是當(dāng)事件時(shí)間大于7s的時(shí)候會(huì)觸發(fā)窗口。當(dāng)然假如有數(shù)據(jù)分區(qū)的情況下，例如kafka中接入watermake的話，那么watermake是會(huì)流動(dòng)的，取的是所有分區(qū)中最小的watermake進(jìn)行流動(dòng)，因?yàn)橹挥凶钚〉哪軌虮ＷC，之前的數(shù)據(jù)都已經(jīng)來(lái)到了，可以觸發(fā)計(jì)算了。

39、畫(huà)出flink執(zhí)行時(shí)的流程圖。

40、Flink分區(qū)分配策略

41、Flink關(guān)閉后狀態(tài)端數(shù)據(jù)恢復(fù)得慢怎么辦？

42、了解flink的savepoint嗎？講一下savepoint和checkpoint的不同和各有什么優(yōu)勢(shì)

43、flink的狀態(tài)后端機(jī)制

Flink的狀態(tài)后端是Flink在做checkpoint的時(shí)候?qū)顟B(tài)快照持久化，有三種狀態(tài)后端 Memery、HDFS、RocksDB

44、flink中滑動(dòng)窗口和滾動(dòng)窗口的區(qū)別，實(shí)際應(yīng)用的窗口是哪種？用的是窗口長(zhǎng)度和滑動(dòng)步長(zhǎng)是多少？

45、用flink能替代spark的批處理功能嗎

Flink 未來(lái)的目標(biāo)是批處理和流處理一體化，因?yàn)榕幚淼臄?shù)據(jù)集你可以理解為是一個(gè)有限的數(shù)據(jù)流。Flink 在批出理方面，尤其是在今年 Flink 1.9 Release 之后，合入大量在 Hive 方面的功能，你可以使用 Flink SQL 來(lái)讀取 Hive 中的元數(shù)據(jù)和數(shù)據(jù)集，并且使用 Flink SQL 對(duì)其進(jìn)行邏輯加工，不過(guò)目前 Flink 在批處理方面的性能，還是干不過(guò) Spark的。

目前看來(lái)，F(xiàn)link 在批處理方面還有很多內(nèi)容要做，當(dāng)然，如果是實(shí)時(shí)計(jì)算引擎的引入，F(xiàn)link 當(dāng)然是首選。

46、flink計(jì)算的UV你們是如何設(shè)置狀態(tài)后端保存數(shù)據(jù)

可以使用布隆過(guò)濾器。

47、sparkstreaming和flink在執(zhí)行任務(wù)上有啥區(qū)別，不是簡(jiǎn)單的流處理和微批，sparkstreaming提交任務(wù)是分解成stage，flink是轉(zhuǎn)換graph，有啥區(qū)別？

48、flink把streamgraph轉(zhuǎn)化成jobGraph是在哪個(gè)階段？

49、Flink中的watermark除了處理亂序數(shù)據(jù)還有其他作用嗎？

還有kafka數(shù)據(jù)順序消費(fèi)的處理。

50、flink你一般設(shè)置水位線設(shè)置多少

我們之前設(shè)置的水位線是6s

52、Flink任務(wù)提交流程

Flink任務(wù)提交后，Client向HDFS上傳Flink的jar包和配置，之后向Yarn ResourceManager提交任務(wù)，ResourceManager分配Container資源并通知對(duì)應(yīng)的NodeManager啟動(dòng) ApplicationMaster，ApplicationMaster啟動(dòng)后加載Flink的jar包和配置構(gòu)建環(huán)境，然后啟動(dòng)JobManager；之后Application Master向ResourceManager申請(qǐng)資源啟動(dòng)TaskManager ，ResourceManager分配Container資源后，由ApplicationMaster通知資源所在的節(jié)點(diǎn)的NodeManager啟動(dòng)TaskManager，NodeManager加載Flink的Jar包和配置構(gòu)建環(huán)境并啟動(dòng)TaskManager，TaskManager啟動(dòng)向JobManager發(fā)送心跳，并等待JobManager向其分配任務(wù)。

53、Flink技術(shù)架構(gòu)圖

54、flink如何實(shí)現(xiàn)在指定時(shí)間進(jìn)行計(jì)算。

55、手寫(xiě)Flink topN

57、Flink的Join算子有哪些

一般join是發(fā)生在window上面的:

1、window join，即按照指定的字段和滾動(dòng)滑動(dòng)窗口和會(huì)話窗口進(jìn)行 inner join

2、是coGoup 其實(shí)就是left join 和 right join，

3、interval join 也就是 在窗口中進(jìn)行join 有一些問(wèn)題，因?yàn)橛行?shù)據(jù)是真的會(huì)后到的，時(shí)間還很長(zhǎng)，那么這個(gè)時(shí)候就有了interval join但是必須要是事件時(shí)間，并且還要指定watermark和水位以及獲取事件時(shí)間戳。并且要設(shè)置 偏移區(qū)間，因?yàn)閖oin 也不能一直等的。

58、Flink1.10 有什么新特性嗎？

內(nèi)存管理及配置優(yōu)化

Flink 目前的 TaskExecutor 內(nèi)存模型存在著一些缺陷，導(dǎo)致優(yōu)化資源利用率比較困難，例如：

• 流和批處理內(nèi)存占用的配置模型不同

• 流處理中的 RocksDB state backend 需要依賴(lài)用戶(hù)進(jìn)行復(fù)雜的配置

為了讓內(nèi)存配置變的對(duì)于用戶(hù)更加清晰、直觀，F(xiàn)link 1.10 對(duì) TaskExecutor 的內(nèi)存模型和配置邏輯進(jìn)行了較大的改動(dòng) （FLIP-49 [7]）。這些改動(dòng)使得 Flink 能夠更好地適配所有部署環(huán)境（例如 Kubernetes, Yarn, Mesos），讓用戶(hù)能夠更加嚴(yán)格的控制其內(nèi)存開(kāi)銷(xiāo)。

Managed 內(nèi)存擴(kuò)展

Managed 內(nèi)存的范圍有所擴(kuò)展，還涵蓋了 RocksDB state backend 使用的內(nèi)存。盡管批處理作業(yè)既可以使用堆內(nèi)內(nèi)存也可以使用堆外內(nèi)存，使用 RocksDB state backend 的流處理作業(yè)卻只能利用堆外內(nèi)存。因此為了讓用戶(hù)執(zhí)行流和批處理作業(yè)時(shí)無(wú)需更改集群的配置，我們規(guī)定從現(xiàn)在起 managed 內(nèi)存只能在堆外。

簡(jiǎn)化 RocksDB 配置

此前，配置像 RocksDB 這樣的堆外 state backend 需要進(jìn)行大量的手動(dòng)調(diào)試，例如減小 JVM 堆空間、設(shè)置 Flink 使用堆外內(nèi)存等?，F(xiàn)在，F(xiàn)link 的開(kāi)箱配置即可支持這一切，且只需要簡(jiǎn)單地改變 managed 內(nèi)存的大小即可調(diào)整 RocksDB state backend 的內(nèi)存預(yù)算。

另一個(gè)重要的優(yōu)化是，F(xiàn)link 現(xiàn)在可以限制 RocksDB 的 native 內(nèi)存占用，以避免超過(guò)總的內(nèi)存預(yù)算—這對(duì)于 Kubernetes 等容器化部署環(huán)境尤為重要。

統(tǒng)一的作業(yè)提交邏輯 在此之前，提交作業(yè)是由執(zhí)行環(huán)境負(fù)責(zé)的，且與不同的部署目標(biāo)（例如 Yarn, Kubernetes, Mesos）緊密相關(guān)。這導(dǎo)致用戶(hù)需要針對(duì)不同環(huán)境保留多套配置，增加了管理的成本。

在 Flink 1.10 中，作業(yè)提交邏輯被抽象到了通用的 Executor 接口。新增加的 ExecutorCLI （引入了為任意執(zhí)行目標(biāo)指定配置參數(shù)的統(tǒng)一方法。此外，隨著引入 JobClient負(fù)責(zé)獲取 JobExecutionResult，獲取作業(yè)執(zhí)行結(jié)果的邏輯也得以與作業(yè)提交解耦。

原生 Kubernetes 集成（Beta）

對(duì)于想要在容器化環(huán)境中嘗試 Flink 的用戶(hù)來(lái)說(shuō)，想要在 Kubernetes 上部署和管理一個(gè) Flink standalone 集群，首先需要對(duì)容器、算子及像 kubectl 這樣的環(huán)境工具有所了解。

在 Flink 1.10 中，我們推出了初步的支持 session 模式的主動(dòng) Kubernetes 集成（FLINK-9953）。其中，“主動(dòng)”指 Flink ResourceManager (K8sResMngr) 原生地與 Kubernetes 通信，像 Flink 在 Yarn 和 Mesos 上一樣按需申請(qǐng) pod。用戶(hù)可以利用 namespace，在多租戶(hù)環(huán)境中以較少的資源開(kāi)銷(xiāo)啟動(dòng) Flink。這需要用戶(hù)提前配置好 RBAC 角色和有足夠權(quán)限的服務(wù)賬號(hào)。

Table API/SQL: 生產(chǎn)可用的 Hive 集成

Flink 1.9 推出了預(yù)覽版的 Hive 集成。該版本允許用戶(hù)使用 SQL DDL 將 Flink 特有的元數(shù)據(jù)持久化到 Hive Metastore、調(diào)用 Hive 中定義的 UDF 以及讀、寫(xiě) Hive 中的表。Flink 1.10 進(jìn)一步開(kāi)發(fā)和完善了這一特性，帶來(lái)了全面兼容 Hive 主要版本的生產(chǎn)可用的 Hive 集成。

Batch SQL 原生分區(qū)支持

此前，F(xiàn)link 只支持寫(xiě)入未分區(qū)的 Hive 表。在 Flink 1.10 中，F(xiàn)link SQL 擴(kuò)展支持了 INSERT OVERWRITE 和 PARTITION 的語(yǔ)法（FLIP-63 ），允許用戶(hù)寫(xiě)入 Hive 中的靜態(tài)和動(dòng)態(tài)分區(qū)。

• 寫(xiě)入靜態(tài)分區(qū)

INSERT { INTO | OVERWRITE } TABLE tablename1 [PARTITION (partcol1=val1, partcol2=val2 ...)] select_statement1 FROM from_statement;

• 寫(xiě)入動(dòng)態(tài)分區(qū)

INSERT { INTO | OVERWRITE } TABLE tablename1 select_statement1 FROM from_statement;

對(duì)分區(qū)表的全面支持，使得用戶(hù)在讀取數(shù)據(jù)時(shí)能夠受益于分區(qū)剪枝，減少了需要掃描的數(shù)據(jù)量，從而大幅提升了這些操作的性能。

另外，除了分區(qū)剪枝，F(xiàn)link 1.10 的 Hive 集成還引入了許多數(shù)據(jù)讀取方面的優(yōu)化，例如：

• 投影下推：Flink 采用了投影下推技術(shù)，通過(guò)在掃描表時(shí)忽略不必要的域，最小化 Flink 和 Hive 表之間的數(shù)據(jù)傳輸量。這一優(yōu)化在表的列數(shù)較多時(shí)尤為有效。

• LIMIT 下推：對(duì)于包含 LIMIT 語(yǔ)句的查詢(xún)，F(xiàn)link 在所有可能的地方限制返回的數(shù)據(jù)條數(shù)，以降低通過(guò)網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)量。

• 讀取數(shù)據(jù)時(shí)的 ORC 向量化： 為了提高讀取 ORC 文件的性能，對(duì)于 Hive 2.0.0 及以上版本以及非復(fù)合數(shù)據(jù)類(lèi)型的列，F(xiàn)link 現(xiàn)在默認(rèn)使用原生的 ORC 向量化讀取器。

59、Flink的重啟策略

固定延遲重啟策略

固定延遲重啟策略是嘗試給定次數(shù)重新啟動(dòng)作業(yè)。如果超過(guò)最大嘗試次數(shù)，則作業(yè)失敗。在兩次連續(xù)重啟嘗試之間，會(huì)有一個(gè)固定的延遲等待時(shí)間。

故障率重啟策略

故障率重啟策略在故障后重新作業(yè)，當(dāng)設(shè)置的故障率（failure rate）超過(guò)每個(gè)時(shí)間間隔的故障時(shí)，作業(yè)最終失敗。在兩次連續(xù)重啟嘗試之間，重啟策略延遲等待一段時(shí)間。

無(wú)重啟策略

作業(yè)直接失敗，不嘗試重啟。

后備重啟策略

使用群集定義的重新啟動(dòng)策略。這對(duì)于啟用檢查點(diǎn)的流式傳輸程序很有幫助。默認(rèn)情況下，如果沒(méi)有定義其他重啟策略，則選擇固定延遲重啟策略。

60、Flink什么時(shí)候用aggregate()或者process()

aggregate： 增量聚合

process： 全量聚合

當(dāng)計(jì)算累加操作時(shí)候可以使用aggregate操作。

當(dāng)計(jì)算窗口內(nèi)全量數(shù)據(jù)的時(shí)候使用process，例如排序等操作。

到此，相信大家對(duì)“Flink的面試題有哪些”有了更深的了解，不妨來(lái)實(shí)際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢(xún)，關(guān)注我們，繼續(xù)學(xué)習(xí)！