本篇內(nèi)容主要講解“Flink的面試題有哪些”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“Flink的面試題有哪些”吧!
創(chuàng)新互聯(lián)建站專注為客戶提供全方位的互聯(lián)網(wǎng)綜合服務，包含不限于網(wǎng)站設計、成都網(wǎng)站設計、肇源網(wǎng)絡推廣、重慶小程序開發(fā)公司、肇源網(wǎng)絡營銷、肇源企業(yè)策劃、肇源品牌公關(guān)、搜索引擎seo、人物專訪、企業(yè)宣傳片、企業(yè)代運營等，從售前售中售后，我們都將竭誠為您服務，您的肯定，是我們最大的嘉獎；創(chuàng)新互聯(lián)建站為所有大學生創(chuàng)業(yè)者提供肇源建站搭建服務，24小時服務熱線：13518219792，官方網(wǎng)址：www.cdcxhl.com
Flink 保證精確一次性消費主要依賴于兩種Flink機制
1、Checkpoint機制
2、二階段提交機制
Checkpoint機制
主要是當Flink開啟Checkpoint的時候，會往Source端插入一條barrir，然后這個barrir隨著數(shù)據(jù)流向一直流動，當流入到一個算子的時候，這個算子就開始制作checkpoint，制作的是從barrir來到之前的時候當前算子的狀態(tài)，將狀態(tài)寫入狀態(tài)后端當中。然后將barrir往下流動，當流動到keyby 或者shuffle算子的時候，例如當一個算子的數(shù)據(jù)，依賴于多個流的時候，這個時候會有barrir對齊，也就是當所有的barrir都來到這個算子的時候進行制作checkpoint，依次進行流動，當流動到sink算子的時候，并且sink算子也制作完成checkpoint會向jobmanager 報告 checkpoint n 制作完成。
二階段提交機制
Flink 提供了CheckpointedFunction與CheckpointListener這樣兩個接口，CheckpointedFunction中有snapshotState方法，每次checkpoint觸發(fā)執(zhí)行方法，通常會將緩存數(shù)據(jù)放入狀態(tài)中，可以理解為一個hook，這個方法里面可以實現(xiàn)預提交，CheckpointListyener中有notifyCheckpointComplete方法，checkpoint完成之后的通知方法，這里可以做一些額外的操作。例如FLinkKafkaConumerBase使用這個來完成Kafka offset的提交，在這個方法里面可以實現(xiàn)提交操作。在2PC中提到如果對應流程例如某個checkpoint失敗的話，那么checkpoint就會回滾，不會影響數(shù)據(jù)一致性，那么如果在通知checkpoint成功的之后失敗了，那么就會在initalizeSate方法中完成事務的提交，這樣可以保證數(shù)據(jù)的一致性。最主要是根據(jù)checkpoint的狀態(tài)文件來判斷的。
flink是一個類似spark的“開源技術(shù)?！?，因為它也提供了批處理，流式計算，圖計算，交互式查詢，機器學習等。flink也是內(nèi)存計算，比較類似spark，但是不一樣的是，spark的計算模型基于RDD，將流式計算看成是特殊的批處理，他的DStream其實還是RDD。而flink吧批處理當成是特殊的流式計算，但是批處理和流式計算的層的引擎是兩個，抽象了DataSet和DataStream。flink在性能上也表現(xiàn)的很好，流式計算延遲比spark少，能做到真正的流式計算，而spark只能是準流式計算。而且在批處理上，當?shù)螖?shù)變多，flink的速度比spark還要快，所以如果flink早一點出來，或許比現(xiàn)在的Spark更火。
Flink狀態(tài)主要有兩種使用方式：
checkpoint的數(shù)據(jù)恢復
邏輯計算
Flink 中的watermark機制是用來處理亂序的，flink的時間必須是event time ，有一個簡單的例子就是，假如窗口是5秒，watermark是2秒，那么 總共就是7秒，這個時候什么時候會觸發(fā)計算呢，假設數(shù)據(jù)初始時間是1000，那么等到6999的時候會觸發(fā)5999窗口的計算，那么下一個就是13999的時候觸發(fā)10999的窗口
其實這個就是watermark的機制，在多并行度中，例如在kafka中會所有的分區(qū)都達到才會觸發(fā)窗口
Event Time 事件產(chǎn)生的時間
Ingestion time 事件進入Flink的時間
processing time 事件進入算子的時間
1、window join，即按照指定的字段和滾動滑動窗口和會話窗口進行 inner join
2、是coGoup 其實就是left join 和 right join，
3、interval join 也就是 在窗口中進行join 有一些問題，因為有些數(shù)據(jù)是真的會后到的，時間還很長，那么這個時候就有了interval join但是必須要是事件時間，并且還要指定watermark和水位以及獲取事件時間戳。并且要設置 偏移區(qū)間，因為join 也不能一直等的。
Tumbing window
Silding window
Session window
Count winodw
keyedProcessFunction 是有一個ontime 操作的，假如是 event時間的時候 那么 調(diào)用的時間就是查看，event的watermark 是否大于 trigger time 的時間，如果大于則進行計算，不大于就等著，如果是kafka的話，那么默認是分區(qū)鍵最小的時間來進行觸發(fā)。
1、async io
2、broadcast
3、async io + cache
4、open方法中讀取，然后定時線程刷新，緩存更新是先刪除，之后再來一條之后再負責寫入緩存
DataSet Api 和 DataStream Api、Table Api
Flink數(shù)據(jù)傾斜如何查看：
在flink的web ui中可以看到數(shù)據(jù)傾斜的情況，就是每個subtask處理的數(shù)據(jù)量差距很大，例如有的只有一M 有的100M 這就是嚴重的數(shù)據(jù)傾斜了。
KafkaSource端發(fā)生的數(shù)據(jù)傾斜
例如上游kafka發(fā)送的時候指定的key出現(xiàn)了數(shù)據(jù)熱點問題，那么就在接入之后，做一個負載均衡（前提下游不是keyby）。
聚合類算子數(shù)據(jù)傾斜
預聚合加全局聚合
1、async io
2、broadcast
3、async io + cache
4、open方法中讀取，然后定時線程刷新，緩存更新是先刪除，之后再來一條之后再負責寫入緩存
1、是否網(wǎng)絡問題
2、是否是barrir問題
3、查看webui，是否有數(shù)據(jù)傾斜
4、有數(shù)據(jù)傾斜的話，那么解決數(shù)據(jù)傾斜后，會有改善，
topn 無論是在離線還是在實時計算中都是比較常見的功能，不同于離線計算中的topn，實時數(shù)據(jù)是持續(xù)不斷的，這樣就給topn的計算帶來很大的困難，因為要持續(xù)在內(nèi)存中維持一個topn的數(shù)據(jù)結(jié)構(gòu)，當有新數(shù)據(jù)來的時候，更新這個數(shù)據(jù)結(jié)構(gòu)
sparkstreaming 的checkpoint會導致數(shù)據(jù)重復消費
但是flink的 checkpoint可以 保證精確一次性，同時可以進行增量，快速的checkpoint的，有三個狀態(tài)后端，memery、rocksdb、hdfs
Complex Event Processing（CEP）：
FLink Cep 是在FLink中實現(xiàn)的復雜時間處理庫，CEP允許在無休止的時間流中檢測事件模式，讓我們有機會掌握數(shù)據(jù)中重要的部分，一個或多個由簡單事件構(gòu)成的時間流通過一定的規(guī)則匹配，然后輸出用戶想得到的數(shù)據(jù)，也就是滿足規(guī)則的復雜事件。
Flink 沒有使用任何復雜的機制來解決反壓問題，F(xiàn)link 在數(shù)據(jù)傳輸過程中使用了分布式阻塞隊列。我們知道在一個阻塞隊列中，當隊列滿了以后發(fā)送者會被天然阻塞住，這種阻塞功能相當于給這個阻塞隊列提供了反壓的能力。
當你的任務出現(xiàn)反壓時，如果你的上游是類似 Kafka 的消息系統(tǒng)，很明顯的表現(xiàn)就是消費速度變慢，Kafka 消息出現(xiàn)堆積。
如果你的業(yè)務對數(shù)據(jù)延遲要求并不高，那么反壓其實并沒有很大的影響。但是對于規(guī)模很大的集群中的大作業(yè)，反壓會造成嚴重的“并發(fā)癥”。首先任務狀態(tài)會變得很大，因為數(shù)據(jù)大規(guī)模堆積在系統(tǒng)中，這些暫時不被處理的數(shù)據(jù)同樣會被放到“狀態(tài)”中。另外，F(xiàn)link 會因為數(shù)據(jù)堆積和處理速度變慢導致 checkpoint 超時，而 checkpoint 是 Flink 保證數(shù)據(jù)一致性的關(guān)鍵所在，最終會導致數(shù)據(jù)的不一致發(fā)生。
Flink Web UI
Flink 的后臺頁面是我們發(fā)現(xiàn)反壓問題的第一選擇。Flink 的后臺頁面可以直觀、清晰地看到當前作業(yè)的運行狀態(tài)。
Web UI，需要注意的是，只有用戶在訪問點擊某一個作業(yè)時，才會觸發(fā)反壓狀態(tài)的計算。在默認的設置下，F(xiàn)link的TaskManager會每隔50ms觸發(fā)一次反壓狀態(tài)監(jiān)測，共監(jiān)測100次，并將計算結(jié)果反饋給JobManager，最后由JobManager進行反壓比例的計算，然后進行展示。
在生產(chǎn)環(huán)境中Flink任務有反壓有三種OK、LOW、HIGH
OK正常
LOW一般
HIGH高負載
Flink的優(yōu)化執(zhí)行其實是借鑒的數(shù)據(jù)庫的優(yōu)化器來生成的執(zhí)行計劃。
CBO，成本優(yōu)化器，代價最小的執(zhí)行計劃就是最好的執(zhí)行計劃。傳統(tǒng)的數(shù)據(jù)庫，成本優(yōu)化器做出最優(yōu)化的執(zhí)行計劃是依據(jù)統(tǒng)計信息來計算的。Flink 的成本優(yōu)化器也一樣。Flink 在提供最終執(zhí)行前，優(yōu)化每個查詢的執(zhí)行邏輯和物理執(zhí)行計劃。這些優(yōu)化工作是交給底層來完成的。根據(jù)查詢成本執(zhí)行進一步的優(yōu)化，從而產(chǎn)生潛在的不同決策：如何排序連接，執(zhí)行哪種類型的連接，并行度等等。
// TODO
valueState 用于保存單個值
ListState 用于保存list元素
MapState 用于保存一組鍵值對
ReducingState 提供了和ListState相同的方法，返回一個ReducingFunction聚合后的值。
AggregatingState和 ReducingState類似，返回一個AggregatingState內(nèi)部聚合后的值
Memery、RocksDB、HDFS
異常數(shù)據(jù)在我們的場景中，一般分為缺失字段和異常值數(shù)據(jù)。
異常值：例如寶寶的年齡的數(shù)據(jù)，例如對于母嬰行業(yè)來講，一個寶寶的年齡是一個至關(guān)重要的數(shù)據(jù)，可以說是最重要的，因為寶寶大于3歲幾乎就不會在母嬰上面購買物品。像我們的有當日、未知、以及很久的時間。這樣都屬于異常字段，這些數(shù)據(jù)我們會展示出來給店長和區(qū)域經(jīng)理看，讓他們知道多少個年齡是不準的。如果要處理的話，可以根據(jù)他購買的時間來進行實時矯正，例如孕婦服裝、奶粉的段位、紙尿褲的大小，以及奶嘴啊一些能夠區(qū)分年齡段的來進行處理。我們并沒有實時處理這些數(shù)據(jù)，我們會有一個底層的策略任務夜維去跑，一個星期跑一次。
缺失字段：例如有的字段真的缺失的很厲害，能修補就修補。不能修補就放棄，就像上家公司中的新聞推薦過濾器。
1、我們監(jiān)控了Flink的任務是否停止
2、我們監(jiān)控了Flink的Kafka的LAG
3、我們會進行實時數(shù)據(jù)對賬，例如銷售額。
Flink有三種數(shù)據(jù)消費語義：
At Most Once 最多消費一次 發(fā)生故障有可能丟失
At Least Once 最少一次 發(fā)生故障有可能重復
Exactly-Once 精確一次 如果產(chǎn)生故障，也能保證數(shù)據(jù)不丟失不重復。
flink 新版本已經(jīng)不提供 At-Most-Once 語義。
DataStreamkeyed1 = ds1.keyBy(o -> o.getString("key")) DataStream keyed2 = ds2.keyBy(o -> o.getString("key")) //右邊時間戳-5s<=左邊流時間戳<=右邊時間戳-1s keyed1.intervalJoin(keyed2).between(Time.milliseconds(-5), Time.milliseconds(5))
并行度根據(jù)kafka topic的并行度，一個并行度3個G
利用 broadcast State 將維度數(shù)據(jù)流廣播到下游所有 task 中。這個 broadcast 的流可以與我們的事件流進行 connect，然后在后續(xù)的 process 算子中進行關(guān)聯(lián)操作即可。
會有報警，監(jiān)控的kafka偏移量也就是LAG。
window join 啊 cogroup 啊 map flatmap，async io 等
Flink 的watermark是一種延遲觸發(fā)的機制。
一般watermark是和window結(jié)合來進行處理亂序數(shù)據(jù)的，Watermark最根本就是一個時間機制，例如我設置最大亂序時間為2s，窗口時間為5秒，那么就是當事件時間大于7s的時候會觸發(fā)窗口。當然假如有數(shù)據(jù)分區(qū)的情況下，例如kafka中接入watermake的話，那么watermake是會流動的，取的是所有分區(qū)中最小的watermake進行流動，因為只有最小的能夠保證，之前的數(shù)據(jù)都已經(jīng)來到了，可以觸發(fā)計算了。
默認情況下，如果設置了Checkpoint選項，F(xiàn)link只保留最近成功生成的1個Checkpoint。當Flink程序失敗時，可以從最近的這個Checkpoint來進行恢復。但是，如果我們希望保留多個Checkpoint，并能夠根據(jù)實際需要選擇其中一個進行恢復，這樣會更加靈活。Flink支持保留多個Checkpoint，需要在Flink的配置文件conf/flink-conf.yaml中，添加如下配置指定最多需要保存Checkpoint的個數(shù)。
關(guān)于小文件問題可以參考代達羅斯之殤-大數(shù)據(jù)領(lǐng)域小文件問題解決攻略。
Spark 默認使用的是 Java序列化機制，同時還有優(yōu)化的機制，也就是kryo
Flink是自己實現(xiàn)的序列化機制，也就是TypeInformation
Flink 的watermark是一種延遲觸發(fā)的機制。
一般watermark是和window結(jié)合來進行處理亂序數(shù)據(jù)的，Watermark最根本就是一個時間機制，例如我設置最大亂序時間為2s，窗口時間為5秒，那么就是當事件時間大于7s的時候會觸發(fā)窗口。當然假如有數(shù)據(jù)分區(qū)的情況下，例如kafka中接入watermake的話，那么watermake是會流動的，取的是所有分區(qū)中最小的watermake進行流動，因為只有最小的能夠保證，之前的數(shù)據(jù)都已經(jīng)來到了，可以觸發(fā)計算了。
Flink的狀態(tài)后端是Flink在做checkpoint的時候?qū)顟B(tài)快照持久化，有三種狀態(tài)后端 Memery、HDFS、RocksDB
Flink 未來的目標是批處理和流處理一體化，因為批處理的數(shù)據(jù)集你可以理解為是一個有限的數(shù)據(jù)流。Flink 在批出理方面，尤其是在今年 Flink 1.9 Release 之后，合入大量在 Hive 方面的功能，你可以使用 Flink SQL 來讀取 Hive 中的元數(shù)據(jù)和數(shù)據(jù)集，并且使用 Flink SQL 對其進行邏輯加工，不過目前 Flink 在批處理方面的性能，還是干不過 Spark的。
目前看來，F(xiàn)link 在批處理方面還有很多內(nèi)容要做，當然，如果是實時計算引擎的引入，F(xiàn)link 當然是首選。
可以使用布隆過濾器。
還有kafka數(shù)據(jù)順序消費的處理。
我們之前設置的水位線是6s
Flink任務提交后，Client向HDFS上傳Flink的jar包和配置，之后向Yarn ResourceManager提交任務，ResourceManager分配Container資源并通知對應的NodeManager啟動 ApplicationMaster，ApplicationMaster啟動后加載Flink的jar包和配置構(gòu)建環(huán)境，然后啟動JobManager；之后Application Master向ResourceManager申請資源啟動TaskManager ，ResourceManager分配Container資源后，由ApplicationMaster通知資源所在的節(jié)點的NodeManager啟動TaskManager，NodeManager加載Flink的Jar包和配置構(gòu)建環(huán)境并啟動TaskManager，TaskManager啟動向JobManager發(fā)送心跳，并等待JobManager向其分配任務。
一般join是發(fā)生在window上面的:
1、window join，即按照指定的字段和滾動滑動窗口和會話窗口進行 inner join
2、是coGoup 其實就是left join 和 right join，
3、interval join 也就是 在窗口中進行join 有一些問題，因為有些數(shù)據(jù)是真的會后到的，時間還很長，那么這個時候就有了interval join但是必須要是事件時間，并且還要指定watermark和水位以及獲取事件時間戳。并且要設置 偏移區(qū)間，因為join 也不能一直等的。
內(nèi)存管理及配置優(yōu)化
Flink 目前的 TaskExecutor 內(nèi)存模型存在著一些缺陷，導致優(yōu)化資源利用率比較困難，例如：
流和批處理內(nèi)存占用的配置模型不同
流處理中的 RocksDB state backend 需要依賴用戶進行復雜的配置
為了讓內(nèi)存配置變的對于用戶更加清晰、直觀，F(xiàn)link 1.10 對 TaskExecutor 的內(nèi)存模型和配置邏輯進行了較大的改動 （FLIP-49 [7]）。這些改動使得 Flink 能夠更好地適配所有部署環(huán)境（例如 Kubernetes, Yarn, Mesos），讓用戶能夠更加嚴格的控制其內(nèi)存開銷。
Managed 內(nèi)存擴展
Managed 內(nèi)存的范圍有所擴展，還涵蓋了 RocksDB state backend 使用的內(nèi)存。盡管批處理作業(yè)既可以使用堆內(nèi)內(nèi)存也可以使用堆外內(nèi)存，使用 RocksDB state backend 的流處理作業(yè)卻只能利用堆外內(nèi)存。因此為了讓用戶執(zhí)行流和批處理作業(yè)時無需更改集群的配置，我們規(guī)定從現(xiàn)在起 managed 內(nèi)存只能在堆外。
簡化 RocksDB 配置
此前，配置像 RocksDB 這樣的堆外 state backend 需要進行大量的手動調(diào)試，例如減小 JVM 堆空間、設置 Flink 使用堆外內(nèi)存等?，F(xiàn)在，F(xiàn)link 的開箱配置即可支持這一切，且只需要簡單地改變 managed 內(nèi)存的大小即可調(diào)整 RocksDB state backend 的內(nèi)存預算。
另一個重要的優(yōu)化是，F(xiàn)link 現(xiàn)在可以限制 RocksDB 的 native 內(nèi)存占用，以避免超過總的內(nèi)存預算—這對于 Kubernetes 等容器化部署環(huán)境尤為重要。
統(tǒng)一的作業(yè)提交邏輯在此之前，提交作業(yè)是由執(zhí)行環(huán)境負責的，且與不同的部署目標（例如 Yarn, Kubernetes, Mesos）緊密相關(guān)。這導致用戶需要針對不同環(huán)境保留多套配置，增加了管理的成本。
在 Flink 1.10 中，作業(yè)提交邏輯被抽象到了通用的 Executor 接口。新增加的 ExecutorCLI （引入了為任意執(zhí)行目標指定配置參數(shù)的統(tǒng)一方法。此外，隨著引入 JobClient負責獲取 JobExecutionResult，獲取作業(yè)執(zhí)行結(jié)果的邏輯也得以與作業(yè)提交解耦。
原生 Kubernetes 集成（Beta）
對于想要在容器化環(huán)境中嘗試 Flink 的用戶來說，想要在 Kubernetes 上部署和管理一個 Flink standalone 集群，首先需要對容器、算子及像 kubectl 這樣的環(huán)境工具有所了解。
在 Flink 1.10 中，我們推出了初步的支持 session 模式的主動 Kubernetes 集成（FLINK-9953）。其中，“主動”指 Flink ResourceManager (K8sResMngr) 原生地與 Kubernetes 通信，像 Flink 在 Yarn 和 Mesos 上一樣按需申請 pod。用戶可以利用 namespace，在多租戶環(huán)境中以較少的資源開銷啟動 Flink。這需要用戶提前配置好 RBAC 角色和有足夠權(quán)限的服務賬號。
Table API/SQL: 生產(chǎn)可用的 Hive 集成
Flink 1.9 推出了預覽版的 Hive 集成。該版本允許用戶使用 SQL DDL 將 Flink 特有的元數(shù)據(jù)持久化到 Hive Metastore、調(diào)用 Hive 中定義的 UDF 以及讀、寫 Hive 中的表。Flink 1.10 進一步開發(fā)和完善了這一特性，帶來了全面兼容 Hive 主要版本的生產(chǎn)可用的 Hive 集成。
Batch SQL 原生分區(qū)支持
此前，F(xiàn)link 只支持寫入未分區(qū)的 Hive 表。在 Flink 1.10 中，F(xiàn)link SQL 擴展支持了 INSERT OVERWRITE 和 PARTITION 的語法（FLIP-63 ），允許用戶寫入 Hive 中的靜態(tài)和動態(tài)分區(qū)。
寫入靜態(tài)分區(qū)
重慶分公司
重慶分公司
INSERT { INTO | OVERWRITE } TABLE tablename1 [PARTITION (partcol1=val1, partcol2=val2 ...)] select_statement1 FROM from_statement;寫入動態(tài)分區(qū)
INSERT { INTO | OVERWRITE } TABLE tablename1 select_statement1 FROM from_statement;對分區(qū)表的全面支持，使得用戶在讀取數(shù)據(jù)時能夠受益于分區(qū)剪枝，減少了需要掃描的數(shù)據(jù)量，從而大幅提升了這些操作的性能。
另外，除了分區(qū)剪枝，F(xiàn)link 1.10 的 Hive 集成還引入了許多數(shù)據(jù)讀取方面的優(yōu)化，例如：
投影下推：Flink 采用了投影下推技術(shù)，通過在掃描表時忽略不必要的域，最小化 Flink 和 Hive 表之間的數(shù)據(jù)傳輸量。這一優(yōu)化在表的列數(shù)較多時尤為有效。
LIMIT 下推：對于包含 LIMIT 語句的查詢，F(xiàn)link 在所有可能的地方限制返回的數(shù)據(jù)條數(shù)，以降低通過網(wǎng)絡傳輸?shù)臄?shù)據(jù)量。
讀取數(shù)據(jù)時的 ORC 向量化： 為了提高讀取 ORC 文件的性能，對于 Hive 2.0.0 及以上版本以及非復合數(shù)據(jù)類型的列，F(xiàn)link 現(xiàn)在默認使用原生的 ORC 向量化讀取器。
固定延遲重啟策略
固定延遲重啟策略是嘗試給定次數(shù)重新啟動作業(yè)。如果超過最大嘗試次數(shù)，則作業(yè)失敗。在兩次連續(xù)重啟嘗試之間，會有一個固定的延遲等待時間。
故障率重啟策略
故障率重啟策略在故障后重新作業(yè)，當設置的故障率（failure rate）超過每個時間間隔的故障時，作業(yè)最終失敗。在兩次連續(xù)重啟嘗試之間，重啟策略延遲等待一段時間。
無重啟策略
作業(yè)直接失敗，不嘗試重啟。
后備重啟策略
使用群集定義的重新啟動策略。這對于啟用檢查點的流式傳輸程序很有幫助。默認情況下，如果沒有定義其他重啟策略，則選擇固定延遲重啟策略。
aggregate：增量聚合
process：全量聚合
當計算累加操作時候可以使用aggregate操作。
當計算窗口內(nèi)全量數(shù)據(jù)的時候使用process，例如排序等操作。
到此，相信大家對“Flink的面試題有哪些”有了更深的了解，不妨來實際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進入相關(guān)頻道進行查詢，關(guān)注我們，繼續(xù)學習！
