Flink的面試題有哪些

本篇內容主要講解“Flink的面試題有哪些”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“Flink的面試題有哪些”吧!

1、Flink如何保證精確一次性消費

Flink 保證精確一次性消費主要依賴于兩種Flink機制

1、Checkpoint機制

2、二階段提交機制

Checkpoint機制

主要是當Flink開啟Checkpoint的時候，會往Source端插入一條barrir，然后這個barrir隨著數據流向一直流動，當流入到一個算子的時候，這個算子就開始制作checkpoint，制作的是從barrir來到之前的時候當前算子的狀態，將狀態寫入狀態后端當中。然后將barrir往下流動，當流動到keyby 或者shuffle算子的時候，例如當一個算子的數據，依賴于多個流的時候，這個時候會有barrir對齊，也就是當所有的barrir都來到這個算子的時候進行制作checkpoint，依次進行流動，當流動到sink算子的時候，并且sink算子也制作完成checkpoint會向jobmanager 報告 checkpoint n 制作完成。

二階段提交機制

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

2、flink和spark區別

flink是一個類似spark的“開源技術棧”，因為它也提供了批處理，流式計算，圖計算，交互式查詢，機器學習等。flink也是內存計算，比較類似spark，但是不一樣的是，spark的計算模型基于RDD，將流式計算看成是特殊的批處理，他的DStream其實還是RDD。而flink吧批處理當成是特殊的流式計算，但是批處理和流式計算的層的引擎是兩個，抽象了DataSet和DataStream。flink在性能上也表現的很好，流式計算延遲比spark少，能做到真正的流式計算，而spark只能是準流式計算。而且在批處理上，當迭代次數變多，flink的速度比spark還要快，所以如果flink早一點出來，或許比現在的Spark更火。

3、Flink的狀態可以用來做什么？

Flink狀態主要有兩種使用方式：

1. checkpoint的數據恢復

2. 邏輯計算

4、Flink的waterMark機制，Flink watermark傳遞機制

Flink 中的watermark機制是用來處理亂序的，flink的時間必須是event time ，有一個簡單的例子就是，假如窗口是5秒，watermark是2秒，那么 總共就是7秒，這個時候什么時候會觸發計算呢，假設數據初始時間是1000，那么等到6999的時候會觸發5999窗口的計算，那么下一個就是13999的時候觸發10999的窗口

其實這個就是watermark的機制，在多并行度中，例如在kafka中會所有的分區都達到才會觸發窗口

5、Flink的時間語義

Event Time 事件產生的時間

Ingestion time 事件進入Flink的時間

processing time 事件進入算子的時間

6、Flink window join

1、window join，即按照指定的字段和滾動滑動窗口和會話窗口進行 inner join

2、是coGoup 其實就是left join 和 right join，

3、interval join 也就是 在窗口中進行join 有一些問題，因為有些數據是真的會后到的，時間還很長，那么這個時候就有了interval join但是必須要是事件時間，并且還要指定watermark和水位以及獲取事件時間戳。并且要設置 偏移區間，因為join 也不能一直等的。

7、flink窗口函數有哪些

Tumbing window

Silding window

Session window

Count winodw

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

keyedProcessFunction 是有一個ontime 操作的，假如是 event時間的時候 那么 調用的時間就是查看，event的watermark 是否大于 trigger time 的時間，如果大于則進行計算，不大于就等著，如果是kafka的話，那么默認是分區鍵最小的時間來進行觸發。

9、flink是怎么處理離線數據的例如和離線數據的關聯？

1、async io

2、broadcast

3、async io + cache

4、open方法中讀取，然后定時線程刷新，緩存更新是先刪除，之后再來一條之后再負責寫入緩存

10、flink支持的數據類型

DataSet Api 和 DataStream Api、Table Api

11、Flink出現數據傾斜怎么辦

Flink數據傾斜如何查看：

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

KafkaSource端發生的數據傾斜

例如上游kafka發送的時候指定的key出現了數據熱點問題，那么就在接入之后，做一個負載均衡（前提下游不是keyby）。

聚合類算子數據傾斜

預聚合加全局聚合

12、flink 維表關聯怎么做的

1、async io

2、broadcast

3、async io + cache

4、open方法中讀取，然后定時線程刷新，緩存更新是先刪除，之后再來一條之后再負責寫入緩存

13、Flink checkpoint的超時問題 如何解決。

1、是否網絡問題

2、是否是barrir問題

3、查看webui，是否有數據傾斜

4、有數據傾斜的話，那么解決數據傾斜后，會有改善，

14、flinkTopN與離線的TopN的區別

topn 無論是在離線還是在實時計算中都是比較常見的功能，不同于離線計算中的topn，實時數據是持續不斷的，這樣就給topn的計算帶來很大的困難，因為要持續在內存中維持一個topn的數據結構，當有新數據來的時候，更新這個數據結構

15、sparkstreaming 和flink 里checkpoint的區別

sparkstreaming 的checkpoint會導致數據重復消費

但是flink的 checkpoint可以 保證精確一次性，同時可以進行增量，快速的checkpoint的，有三個狀態后端，memery、rocksdb、hdfs

16、簡單介紹一下cep狀態編程

Complex Event Processing（CEP）：

FLink Cep 是在FLink中實現的復雜時間處理庫，CEP允許在無休止的時間流中檢測事件模式，讓我們有機會掌握數據中重要的部分，一個或多個由簡單事件構成的時間流通過一定的規則匹配，然后輸出用戶想得到的數據，也就是滿足規則的復雜事件。

17、 Flink cep連續事件的可選項有什么

18、如何通過flink的CEP來實現支付延遲提醒

19、Flink cep 你用過哪些業務場景

20、cep底層如何工作

21、cep怎么老化

22、cep性能調優

23、Flink的背壓，介紹一下Flink的反壓，你們是如何監控和發現的呢。

Flink 沒有使用任何復雜的機制來解決反壓問題，Flink 在數據傳輸過程中使用了分布式阻塞隊列。我們知道在一個阻塞隊列中，當隊列滿了以后發送者會被天然阻塞住，這種阻塞功能相當于給這個阻塞隊列提供了反壓的能力。

當你的任務出現反壓時，如果你的上游是類似 Kafka 的消息系統，很明顯的表現就是消費速度變慢，Kafka 消息出現堆積。

如果你的業務對數據延遲要求并不高，那么反壓其實并沒有很大的影響。但是對于規模很大的集群中的大作業，反壓會造成嚴重的“并發癥”。首先任務狀態會變得很大，因為數據大規模堆積在系統中，這些暫時不被處理的數據同樣會被放到“狀態”中。另外，Flink 會因為數據堆積和處理速度變慢導致 checkpoint 超時，而 checkpoint 是 Flink 保證數據一致性的關鍵所在，最終會導致數據的不一致發生。

Flink Web UI

Flink 的后臺頁面是我們發現反壓問題的第一選擇。Flink 的后臺頁面可以直觀、清晰地看到當前作業的運行狀態。

Web UI，需要注意的是，只有用戶在訪問點擊某一個作業時，才會觸發反壓狀態的計算。在默認的設置下，Flink的TaskManager會每隔50ms觸發一次反壓狀態監測，共監測100次，并將計算結果反饋給JobManager，最后由JobManager進行反壓比例的計算，然后進行展示。

在生產環境中Flink任務有反壓有三種OK、LOW、HIGH

OK正常

LOW一般

HIGH高負載

24、Flink的CBO，邏輯執行計劃和物理執行計劃

Flink的優化執行其實是借鑒的數據庫的優化器來生成的執行計劃。

CBO，成本優化器，代價最小的執行計劃就是最好的執行計劃。傳統的數據庫，成本優化器做出最優化的執行計劃是依據統計信息來計算的。Flink 的成本優化器也一樣。Flink 在提供最終執行前，優化每個查詢的執行邏輯和物理執行計劃。這些優化工作是交給底層來完成的。根據查詢成本執行進一步的優化，從而產生潛在的不同決策：如何排序連接，執行哪種類型的連接，并行度等等。

// TODO

25、Flink中數據聚合，不使用窗口怎么實現聚合

• valueState 用于保存單個值

• ListState 用于保存list元素

• MapState 用于保存一組鍵值對

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

• AggregatingState和 ReducingState類似，返回一個AggregatingState內部聚合后的值

26、Flink中state有哪幾種存儲方式

Memery、RocksDB、HDFS

27、Flink 異常數據怎么處理

異常數據在我們的場景中，一般分為缺失字段和異常值數據。

異常值： 例如寶寶的年齡的數據，例如對于母嬰行業來講，一個寶寶的年齡是一個至關重要的數據，可以說是最重要的，因為寶寶大于3歲幾乎就不會在母嬰上面購買物品。像我們的有當日、未知、以及很久的時間。這樣都屬于異常字段，這些數據我們會展示出來給店長和區域經理看，讓他們知道多少個年齡是不準的。如果要處理的話，可以根據他購買的時間來進行實時矯正，例如孕婦服裝、奶粉的段位、紙尿褲的大小，以及奶嘴啊一些能夠區分年齡段的來進行處理。我們并沒有實時處理這些數據，我們會有一個底層的策略任務夜維去跑，一個星期跑一次。

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

28、Flink 監控你們怎么做的

1、我們監控了Flink的任務是否停止

2、我們監控了Flink的Kafka的LAG

3、我們會進行實時數據對賬，例如銷售額。

29、Flink 有數據丟失的可能嗎

Flink有三種數據消費語義：

1. At Most Once 最多消費一次 發生故障有可能丟失

2. At Least Once 最少一次 發生故障有可能重復

3. Exactly-Once 精確一次 如果產生故障，也能保證數據不丟失不重復。

flink 新版本已經不提供 At-Most-Once 語義。

30、Flink interval join 你能簡單的寫一寫嗎

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

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

并行度根據kafka topic的并行度，一個并行度3個G

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

利用 broadcast State 將維度數據流廣播到下游所有 task 中。這個 broadcast 的流可以與我們的事件流進行 connect，然后在后續的 process 算子中進行關聯操作即可。

33、flink的source端斷了，比如kafka出故障，沒有數據發過來，怎么處理？

會有報警，監控的kafka偏移量也就是LAG。

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

window join 啊 cogroup 啊 map flatmap，async io 等

35、flink的水位線，你了解嗎，能簡單介紹一下嗎

Flink 的watermark是一種延遲觸發的機制。

一般watermark是和window結合來進行處理亂序數據的，Watermark最根本就是一個時間機制，例如我設置最大亂序時間為2s，窗口時間為5秒，那么就是當事件時間大于7s的時候會觸發窗口。當然假如有數據分區的情況下，例如kafka中接入watermake的話，那么watermake是會流動的，取的是所有分區中最小的watermake進行流動，因為只有最小的能夠保證，之前的數據都已經來到了，可以觸發計算了。

36、Flink怎么維護Checkpoint？在HDFS上存儲的話會有小文件嗎

默認情況下，如果設置了Checkpoint選項，Flink只保留最近成功生成的1個Checkpoint。當Flink程序失敗時，可以從最近的這個Checkpoint來進行恢復。但是，如果我們希望保留多個Checkpoint，并能夠根據實際需要選擇其中一個進行恢復，這樣會更加靈活。Flink支持保留多個Checkpoint，需要在Flink的配置文件conf/flink-conf.yaml中，添加如下配置指定最多需要保存Checkpoint的個數。

關于小文件問題可以參考代達羅斯之殤-大數據領域小文件問題解決攻略。

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

Spark 默認使用的是 Java序列化機制，同時還有優化的機制，也就是kryo

Flink是自己實現的序列化機制，也就是TypeInformation

38、Flink是怎么處理遲到數據的？但是實際開發中不能有數據遲到，怎么做？

Flink 的watermark是一種延遲觸發的機制。

一般watermark是和window結合來進行處理亂序數據的，Watermark最根本就是一個時間機制，例如我設置最大亂序時間為2s，窗口時間為5秒，那么就是當事件時間大于7s的時候會觸發窗口。當然假如有數據分區的情況下，例如kafka中接入watermake的話，那么watermake是會流動的，取的是所有分區中最小的watermake進行流動，因為只有最小的能夠保證，之前的數據都已經來到了，可以觸發計算了。

39、畫出flink執行時的流程圖。

40、Flink分區分配策略

41、Flink關閉后狀態端數據恢復得慢怎么辦？

42、了解flink的savepoint嗎？講一下savepoint和checkpoint的不同和各有什么優勢

43、flink的狀態后端機制

Flink的狀態后端是Flink在做checkpoint的時候將狀態快照持久化，有三種狀態后端 Memery、HDFS、RocksDB

44、flink中滑動窗口和滾動窗口的區別，實際應用的窗口是哪種？用的是窗口長度和滑動步長是多少？

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

Flink 未來的目標是批處理和流處理一體化，因為批處理的數據集你可以理解為是一個有限的數據流。Flink 在批出理方面，尤其是在今年 Flink 1.9 Release 之后，合入大量在 Hive 方面的功能，你可以使用 Flink SQL 來讀取 Hive 中的元數據和數據集，并且使用 Flink SQL 對其進行邏輯加工，不過目前 Flink 在批處理方面的性能，還是干不過 Spark的。

目前看來，Flink 在批處理方面還有很多內容要做，當然，如果是實時計算引擎的引入，Flink 當然是首選。

46、flink計算的UV你們是如何設置狀態后端保存數據

可以使用布隆過濾器。

47、sparkstreaming和flink在執行任務上有啥區別，不是簡單的流處理和微批，sparkstreaming提交任務是分解成stage，flink是轉換graph，有啥區別？

48、flink把streamgraph轉化成jobGraph是在哪個階段？

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

還有kafka數據順序消費的處理。

50、flink你一般設置水位線設置多少

我們之前設置的水位線是6s

52、Flink任務提交流程

Flink任務提交后，Client向HDFS上傳Flink的jar包和配置，之后向Yarn ResourceManager提交任務，ResourceManager分配Container資源并通知對應的NodeManager啟動 ApplicationMaster，ApplicationMaster啟動后加載Flink的jar包和配置構建環境，然后啟動JobManager；之后Application Master向ResourceManager申請資源啟動TaskManager ，ResourceManager分配Container資源后，由ApplicationMaster通知資源所在的節點的NodeManager啟動TaskManager，NodeManager加載Flink的Jar包和配置構建環境并啟動TaskManager，TaskManager啟動向JobManager發送心跳，并等待JobManager向其分配任務。

53、Flink技術架構圖

54、flink如何實現在指定時間進行計算。

55、手寫Flink topN

57、Flink的Join算子有哪些

一般join是發生在window上面的:

1、window join，即按照指定的字段和滾動滑動窗口和會話窗口進行 inner join

2、是coGoup 其實就是left join 和 right join，

3、interval join 也就是 在窗口中進行join 有一些問題，因為有些數據是真的會后到的，時間還很長，那么這個時候就有了interval join但是必須要是事件時間，并且還要指定watermark和水位以及獲取事件時間戳。并且要設置 偏移區間，因為join 也不能一直等的。

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

內存管理及配置優化

Flink 目前的 TaskExecutor 內存模型存在著一些缺陷，導致優化資源利用率比較困難，例如：

• 流和批處理內存占用的配置模型不同

• 流處理中的 RocksDB state backend 需要依賴用戶進行復雜的配置

為了讓內存配置變的對于用戶更加清晰、直觀，Flink 1.10 對 TaskExecutor 的內存模型和配置邏輯進行了較大的改動 （FLIP-49 [7]）。這些改動使得 Flink 能夠更好地適配所有部署環境（例如 Kubernetes, Yarn, Mesos），讓用戶能夠更加嚴格的控制其內存開銷。

Managed 內存擴展

Managed 內存的范圍有所擴展，還涵蓋了 RocksDB state backend 使用的內存。盡管批處理作業既可以使用堆內內存也可以使用堆外內存，使用 RocksDB state backend 的流處理作業卻只能利用堆外內存。因此為了讓用戶執行流和批處理作業時無需更改集群的配置，我們規定從現在起 managed 內存只能在堆外。

簡化 RocksDB 配置

此前，配置像 RocksDB 這樣的堆外 state backend 需要進行大量的手動調試，例如減小 JVM 堆空間、設置 Flink 使用堆外內存等。現在，Flink 的開箱配置即可支持這一切，且只需要簡單地改變 managed 內存的大小即可調整 RocksDB state backend 的內存預算。

另一個重要的優化是，Flink 現在可以限制 RocksDB 的 native 內存占用，以避免超過總的內存預算—這對于 Kubernetes 等容器化部署環境尤為重要。

統一的作業提交邏輯 在此之前，提交作業是由執行環境負責的，且與不同的部署目標（例如 Yarn, Kubernetes, Mesos）緊密相關。這導致用戶需要針對不同環境保留多套配置，增加了管理的成本。

在 Flink 1.10 中，作業提交邏輯被抽象到了通用的 Executor 接口。新增加的 ExecutorCLI （引入了為任意執行目標指定配置參數的統一方法。此外，隨著引入 JobClient負責獲取 JobExecutionResult，獲取作業執行結果的邏輯也得以與作業提交解耦。

原生 Kubernetes 集成（Beta）

對于想要在容器化環境中嘗試 Flink 的用戶來說，想要在 Kubernetes 上部署和管理一個 Flink standalone 集群，首先需要對容器、算子及像 kubectl 這樣的環境工具有所了解。

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

Table API/SQL: 生產可用的 Hive 集成

Flink 1.9 推出了預覽版的 Hive 集成。該版本允許用戶使用 SQL DDL 將 Flink 特有的元數據持久化到 Hive Metastore、調用 Hive 中定義的 UDF 以及讀、寫 Hive 中的表。Flink 1.10 進一步開發和完善了這一特性，帶來了全面兼容 Hive 主要版本的生產可用的 Hive 集成。

Batch SQL 原生分區支持

此前，Flink 只支持寫入未分區的 Hive 表。在 Flink 1.10 中，Flink SQL 擴展支持了 INSERT OVERWRITE 和 PARTITION 的語法（FLIP-63 ），允許用戶寫入 Hive 中的靜態和動態分區。

• 寫入靜態分區

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

• 寫入動態分區

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

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

另外，除了分區剪枝，Flink 1.10 的 Hive 集成還引入了許多數據讀取方面的優化，例如：

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

• LIMIT 下推：對于包含 LIMIT 語句的查詢，Flink 在所有可能的地方限制返回的數據條數，以降低通過網絡傳輸的數據量。

• 讀取數據時的 ORC 向量化： 為了提高讀取 ORC 文件的性能，對于 Hive 2.0.0 及以上版本以及非復合數據類型的列，Flink 現在默認使用原生的 ORC 向量化讀取器。

59、Flink的重啟策略

固定延遲重啟策略

固定延遲重啟策略是嘗試給定次數重新啟動作業。如果超過最大嘗試次數，則作業失敗。在兩次連續重啟嘗試之間，會有一個固定的延遲等待時間。

故障率重啟策略

故障率重啟策略在故障后重新作業，當設置的故障率（failure rate）超過每個時間間隔的故障時，作業最終失敗。在兩次連續重啟嘗試之間，重啟策略延遲等待一段時間。

無重啟策略

作業直接失敗，不嘗試重啟。

后備重啟策略

使用群集定義的重新啟動策略。這對于啟用檢查點的流式傳輸程序很有幫助。默認情況下，如果沒有定義其他重啟策略，則選擇固定延遲重啟策略。

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

aggregate： 增量聚合

process： 全量聚合

當計算累加操作時候可以使用aggregate操作。

當計算窗口內全量數據的時候使用process，例如排序等操作。

到此，相信大家對“Flink的面試題有哪些”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！