【大資料面試題】Flink第一彈60連發

感謝胖子大佬提供的企業面試題，本文因為時間關系只有部分答案，后續的答案小編會持續補全，請持續關注本系列，年后升職加薪就靠它了，胖子大佬就在交流群里，需要加群的公眾號回復【加群】，
更多面試題可以參考：《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，例如排序等操作，

61、Flink優化 你了解多少

62、Flink記憶體溢位怎么辦

63、說說Flink中的keyState包含哪些資料結構

64、Flink shardGroup的概念

歡迎關注，《大資料成神之路》系列文章

歡迎關注，《大資料成神之路》系列文章

歡迎關注，《大資料成神之路》系列文章

標籤：Java

上一篇：Java高并發18-并發串列CopyOnWriteArrayList原始碼決議

下一篇：BindingResult的使用