【大數據面試題】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狀態主要有兩種使用方式：

checkpoint的數據恢復
邏輯計算

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有三種數據消費語義：

At Most Once 最多消費一次發生故障有可能丟失
At Least Once 最少一次發生故障有可能重複
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是一種延遲觸發的機制。

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，

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的概念

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