2021年大數(shù)據(jù)面試題系列全面開肝
感謝讀者胖子大佬提供的企業(yè)面試題。本文因為時間關(guān)系只有部分答案，后續(xù)的答案小編會持續(xù)補全，請持續(xù)關(guān)注本系列。部分答案可以參考《Flink面試通關(guān)手冊》。
年后升職加薪就靠它了。胖子大佬就在交流群里，需要加群的公眾號回復(fù)【加群】。
【開了贊賞，大家可以隨意打賞，小編會用打賞金額??10倍獎勵給我們的胖子大佬】
1、Flink如何保證精確一次性消費
Flink 保證精確一次性消費主要依賴于兩種Flink機制
主要是當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)預(yù)提交，CheckpointListyener中有notifyCheckpointComplete方法，checkpoint完成之后的通知方法，這里可以做一些額外的操作。例如FLinkKafkaConumerBase使用這個來完成Kafka offset的提交，在這個方法里面可以實現(xiàn)提交操作。在2PC中提到如果對應(yīng)流程例如某個checkpoint失敗的話，那么checkpoint就會回滾，不會影響數(shù)據(jù)一致性，那么如果在通知checkpoint成功的之后失敗了，那么就會在initalizeSate方法中完成事務(wù)的提交，這樣可以保證數(shù)據(jù)的一致性。最主要是根據(jù)checkpoint的狀態(tài)文件來判斷的。
2、flink和spark區(qū)別
flink是一個類似spark的“開源技術(shù)棧”，因為它也提供了批處理，流式計算，圖計算，交互式查詢，機器學(xué)習(xí)等。flink也是內(nèi)存計算，比較類似spark，但是不一樣的是，spark的計算模型基于RDD，將流式計算看成是特殊的批處理，他的DStream其實還是RDD。而flink吧批處理當成是特殊的流式計算，但是批處理和流式計算的層的引擎是兩個，抽象了DataSet和DataStream。flink在性能上也表現(xiàn)的很好，流式計算延遲比spark少，能做到真正的流式計算，而spark只能是準流式計算。而且在批處理上，當?shù)螖?shù)變多，flink的速度比spark還要快，所以如果flink早一點出來，或許比現(xiàn)在的Spark更火。
3、Flink的狀態(tài)可以用來做什么？
checkpoint的數(shù)據(jù)恢復(fù)
邏輯計算
4、Flink的waterMark機制，F(xiàn)link watermark傳遞機制
Flink 中的watermark機制是用來處理亂序的，flink的時間必須是event time ，有一個簡單的例子就是，假如窗口是5秒，watermark是2秒，那么 總共就是7秒，這個時候什么時候會觸發(fā)計算呢，假設(shè)數(shù)據(jù)初始時間是1000，那么等到6999的時候會觸發(fā)5999窗口的計算，那么下一個就是13999的時候觸發(fā)10999的窗口
其實這個就是watermark的機制，在多并行度中，例如在kafka中會所有的分區(qū)都達到才會觸發(fā)窗口
5、Flink的時間語義
Ingestion time 事件進入Flink的時間
processing time 事件進入算子的時間
6、Flink window join
1、window join，即按照指定的字段和滾動滑動窗口和會話窗口進行 inner join
2、是coGoup 其實就是left join 和 right join，
3、interval join 也就是 在窗口中進行join 有一些問題，因為有些數(shù)據(jù)是真的會后到的，時間還很長，那么這個時候就有了interval join但是必須要是事件時間，并且還要指定watermark和水位以及獲取事件時間戳。并且要設(shè)置 偏移區(qū)間，因為join 也不能一直等的。
7、flink窗口函數(shù)有哪些
8、keyedProcessFunction 是如何工作的。假如是event time的話
keyedProcessFunction 是有一個ontime 操作的，假如是 event時間的時候 那么 調(diào)用的時間就是查看，event的watermark 是否大于 trigger time 的時間，如果大于則進行計算，不大于就等著，如果是kafka的話，那么默認是分區(qū)鍵最小的時間來進行觸發(fā)。
9、flink是怎么處理離線數(shù)據(jù)的例如和離線數(shù)據(jù)的關(guān)聯(lián)？
4、open方法中讀取，然后定時線程刷新，緩存更新是先刪除，之后再來一條之后再負責寫入緩存
10、flink支持的數(shù)據(jù)類型
DataSet Api 和 DataStream Api、Table Api
11、Flink出現(xiàn)數(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）。
12、flink 維表關(guān)聯(lián)怎么做的
4、open方法中讀取，然后定時線程刷新，緩存更新是先刪除，之后再來一條之后再負責寫入緩存
13、Flink checkpoint的超時問題 如何解決。
3、查看webui，是否有數(shù)據(jù)傾斜
4、有數(shù)據(jù)傾斜的話，那么解決數(shù)據(jù)傾斜后，會有改善，
14、flinkTopN與離線的TopN的區(qū)別
topn 無論是在離線還是在實時計算中都是比較常見的功能，不同于離線計算中的topn，實時數(shù)據(jù)是持續(xù)不斷的，這樣就給topn的計算帶來很大的困難，因為要持續(xù)在內(nèi)存中維持一個topn的數(shù)據(jù)結(jié)構(gòu)，當有新數(shù)據(jù)來的時候，更新這個數(shù)據(jù)結(jié)構(gòu)
15、sparkstreaming 和flink 里checkpoint的區(qū)別
sparkstreaming 的checkpoint會導(dǎo)致數(shù)據(jù)重復(fù)消費
但是flink的 checkpoint可以 保證精確一次性，同時可以進行增量，快速的checkpoint的，有三個狀態(tài)后端，memery、rocksdb、hdfs
16、簡單介紹一下cep狀態(tài)編程
Complex Event Processing（CEP）：
FLink Cep 是在FLink中實現(xiàn)的復(fù)雜時間處理庫，CEP允許在無休止的時間流中檢測事件模式，讓我們有機會掌握數(shù)據(jù)中重要的部分，一個或多個由簡單事件構(gòu)成的時間流通過一定的規(guī)則匹配，然后輸出用戶想得到的數(shù)據(jù)，也就是滿足規(guī)則的復(fù)雜事件。
17、 Flink cep連續(xù)事件的可選項有什么
18、如何通過flink的CEP來實現(xiàn)支付延遲提醒
19、Flink cep 你用過哪些業(yè)務(wù)場景
20、cep底層如何工作
21、cep怎么老化
22、cep性能調(diào)優(yōu)
23、Flink的背壓，介紹一下Flink的反壓，你們是如何監(jiān)控和發(fā)現(xiàn)的呢。
Flink 沒有使用任何復(fù)雜的機制來解決反壓問題，F(xiàn)link 在數(shù)據(jù)傳輸過程中使用了分布式阻塞隊列。我們知道在一個阻塞隊列中，當隊列滿了以后發(fā)送者會被天然阻塞住，這種阻塞功能相當于給這個阻塞隊列提供了反壓的能力。
當你的任務(wù)出現(xiàn)反壓時，如果你的上游是類似 Kafka 的消息系統(tǒng)，很明顯的表現(xiàn)就是消費速度變慢，Kafka 消息出現(xiàn)堆積。
如果你的業(yè)務(wù)對數(shù)據(jù)延遲要求并不高，那么反壓其實并沒有很大的影響。但是對于規(guī)模很大的集群中的大作業(yè)，反壓會造成嚴重的“并發(fā)癥”。首先任務(wù)狀態(tài)會變得很大，因為數(shù)據(jù)大規(guī)模堆積在系統(tǒng)中，這些暫時不被處理的數(shù)據(jù)同樣會被放到“狀態(tài)”中。另外，F(xiàn)link 會因為數(shù)據(jù)堆積和處理速度變慢導(dǎo)致 checkpoint 超時，而 checkpoint 是 Flink 保證數(shù)據(jù)一致性的關(guān)鍵所在，最終會導(dǎo)致數(shù)據(jù)的不一致發(fā)生。
Flink 的后臺頁面是我們發(fā)現(xiàn)反壓問題的第一選擇。Flink 的后臺頁面可以直觀、清晰地看到當前作業(yè)的運行狀態(tài)。
Web UI，需要注意的是，只有用戶在訪問點擊某一個作業(yè)時，才會觸發(fā)反壓狀態(tài)的計算。在默認的設(shè)置下，F(xiàn)link的TaskManager會每隔50ms觸發(fā)一次反壓狀態(tài)監(jiān)測，共監(jiān)測100次，并將計算結(jié)果反饋給JobManager，最后由JobManager進行反壓比例的計算，然后進行展示。
在生產(chǎn)環(huán)境中Flink任務(wù)有反壓有三種OK、LOW、HIGH
24、Flink的CBO，邏輯執(zhí)行計劃和物理執(zhí)行計劃
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í)行哪種類型的連接，并行度等等。
25、Flink中數(shù)據(jù)聚合，不使用窗口怎么實現(xiàn)聚合
26、Flink中state有哪幾種存儲方式
27、Flink 異常數(shù)據(jù)怎么處理
異常數(shù)據(jù)在我們的場景中，一般分為缺失字段和異常值數(shù)據(jù)。
異常值： 例如寶寶的年齡的數(shù)據(jù)，例如對于母嬰行業(yè)來講，一個寶寶的年齡是一個至關(guān)重要的數(shù)據(jù)，可以說是最重要的，因為寶寶大于3歲幾乎就不會在母嬰上面購買物品。像我們的有當日、未知、以及很久的時間。這樣都屬于異常字段，這些數(shù)據(jù)我們會展示出來給店長和區(qū)域經(jīng)理看，讓他們知道多少個年齡是不準的。如果要處理的話，可以根據(jù)他購買的時間來進行實時矯正，例如孕婦服裝、奶粉的段位、紙尿褲的大小，以及奶嘴啊一些能夠區(qū)分年齡段的來進行處理。我們并沒有實時處理這些數(shù)據(jù)，我們會有一個底層的策略任務(wù)夜維去跑，一個星期跑一次。
缺失字段： 例如有的字段真的缺失的很厲害，能修補就修補。不能修補就放棄，就像上家公司中的新聞推薦過濾器。
28、Flink 監(jiān)控你們怎么做的
1、我們監(jiān)控了Flink的任務(wù)是否停止
2、我們監(jiān)控了Flink的Kafka的LAG
3、我們會進行實時數(shù)據(jù)對賬，例如銷售額。
29、Flink 有數(shù)據(jù)丟失的可能嗎
At Most Once 最多消費一次 發(fā)生故障有可能丟失
At Least Once 最少一次 發(fā)生故障有可能重復(fù)
Exactly-Once 精確一次 如果產(chǎn)生故障，也能保證數(shù)據(jù)不丟失不重復(fù)。
flink 新版本已經(jīng)不提供 At-Most-Once 語義。
30、Flink interval join 你能簡單的寫一寫嗎
DataStream
keyed1 = 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))
31、Flink 提交的時候 并行度如何制定，以及資源如何配置
并行度根據(jù)kafka topic的并行度，一個并行度3個G
32、Flink的boardcast join 的原理是什么
利用 broadcast State 將維度數(shù)據(jù)流廣播到下游所有 task 中。這個 broadcast 的流可以與我們的事件流進行 connect，然后在后續(xù)的 process 算子中進行關(guān)聯(lián)操作即可。
33、flink的source端斷了，比如kafka出故障，沒有數(shù)據(jù)發(fā)過來，怎么處理？
會有報警，監(jiān)控的kafka偏移量也就是LAG。
34、flink有什么常用的流的API?
window join 啊 cogroup 啊 map flatmap，async io 等
35、flink的水位線，你了解嗎，能簡單介紹一下嗎
Flink 的watermark是一種延遲觸發(fā)的機制。
一般watermark是和window結(jié)合來進行處理亂序數(shù)據(jù)的，Watermark最根本就是一個時間機制，例如我設(shè)置最大亂序時間為2s，窗口時間為5秒，那么就是當事件時間大于7s的時候會觸發(fā)窗口。當然假如有數(shù)據(jù)分區(qū)的情況下，例如kafka中接入watermake的話，那么watermake是會流動的，取的是所有分區(qū)中最小的watermake進行流動，因為只有最小的能夠保證，之前的數(shù)據(jù)都已經(jīng)來到了，可以觸發(fā)計算了。
36、Flink怎么維護Checkpoint？在HDFS上存儲的話會有小文件嗎
默認情況下，如果設(shè)置了Checkpoint選項，F(xiàn)link只保留最近成功生成的1個Checkpoint。當Flink程序失敗時，可以從最近的這個Checkpoint來進行恢復(fù)。但是，如果我們希望保留多個Checkpoint，并能夠根據(jù)實際需要選擇其中一個進行恢復(fù)，這樣會更加靈活。Flink支持保留多個Checkpoint，需要在Flink的配置文件conf/flink-conf.yaml中，添加如下配置指定最多需要保存Checkpoint的個數(shù)。
37、Spark和Flink的序列化，有什么區(qū)別嗎？
Spark 默認使用的是 Java序列化機制，同時還有優(yōu)化的機制，也就是kryo
Flink是自己實現(xiàn)的序列化機制，也就是TypeInformation
38、Flink是怎么處理遲到數(shù)據(jù)的？但是實際開發(fā)中不能有數(shù)據(jù)遲到，怎么做？
Flink 的watermark是一種延遲觸發(fā)的機制。
一般watermark是和window結(jié)合來進行處理亂序數(shù)據(jù)的，Watermark最根本就是一個時間機制，例如我設(shè)置最大亂序時間為2s，窗口時間為5秒，那么就是當事件時間大于7s的時候會觸發(fā)窗口。當然假如有數(shù)據(jù)分區(qū)的情況下，例如kafka中接入watermake的話，那么watermake是會流動的，取的是所有分區(qū)中最小的watermake進行流動，因為只有最小的能夠保證，之前的數(shù)據(jù)都已經(jīng)來到了，可以觸發(fā)計算了。
39、畫出flink執(zhí)行時的流程圖。
40、Flink分區(qū)分配策略
41、Flink關(guān)閉后狀態(tài)端數(shù)據(jù)恢復(fù)得慢怎么辦？
42、了解flink的savepoint嗎？講一下savepoint和checkpoint的不同和各有什么優(yōu)勢
43、flink的狀態(tài)后端機制
Flink的狀態(tài)后端是Flink在做checkpoint的時候?qū)顟B(tài)快照持久化，有三種狀態(tài)后端 Memery、HDFS、RocksDB
44、flink中滑動窗口和滾動窗口的區(qū)別，實際應(yīng)用的窗口是哪種？用的是窗口長度和滑動步長是多少？
45、用flink能替代spark的批處理功能嗎
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 當然是首選。
46、flink計算的UV你們是如何設(shè)置狀態(tài)后端保存數(shù)據(jù)
47、sparkstreaming和flink在執(zhí)行任務(wù)上有啥區(qū)別，不是簡單的流處理和微批，sparkstreaming提交任務(wù)是分解成stage，flink是轉(zhuǎn)換graph，有啥區(qū)別？
48、flink把streamgraph轉(zhuǎn)化成jobGraph是在哪個階段？
49、Flink中的watermark除了處理亂序數(shù)據(jù)還有其他作用嗎？
還有kafka數(shù)據(jù)順序消費的處理。
50、flink你一般設(shè)置水位線設(shè)置多少
52、Flink任務(wù)提交流程
Flink任務(wù)提交后，Client向HDFS上傳Flink的jar包和配置，之后向Yarn ResourceManager提交任務(wù)，ResourceManager分配Container資源并通知對應(yīng)的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向其分配任務(wù)。
53、Flink技術(shù)架構(gòu)圖
54、flink如何實現(xiàn)在指定時間進行計算。
55、手寫Flink topN
57、Flink的Join算子有哪些
1、window join，即按照指定的字段和滾動滑動窗口和會話窗口進行 inner join
2、是coGoup 其實就是left join 和 right join，
3、interval join 也就是 在窗口中進行join 有一些問題，因為有些數(shù)據(jù)是真的會后到的，時間還很長，那么這個時候就有了interval join但是必須要是事件時間，并且還要指定watermark和水位以及獲取事件時間戳。并且要設(shè)置 偏移區(qū)間，因為join 也不能一直等的。
58、Flink1.10 有什么新特性嗎？
Flink 目前的 TaskExecutor 內(nèi)存模型存在著一些缺陷，導(dǎo)致優(yōu)化資源利用率比較困難，例如：
為了讓內(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)存的范圍有所擴展，還涵蓋了 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 這樣的堆外 state backend 需要進行大量的手動調(diào)試，例如減小 JVM 堆空間、設(shè)置 Flink 使用堆外內(nèi)存等。現(xiàn)在，F(xiàn)link 的開箱配置即可支持這一切，且只需要簡單地改變 managed 內(nèi)存的大小即可調(diào)整 RocksDB state backend 的內(nèi)存預(yù)算。
另一個重要的優(yōu)化是，F(xiàn)link 現(xiàn)在可以限制 RocksDB 的 native 內(nèi)存占用，以避免超過總的內(nèi)存預(yù)算—這對于 Kubernetes 等容器化部署環(huán)境尤為重要。
在此之前，提交作業(yè)是由執(zhí)行環(huán)境負責的，且與不同的部署目標（例如 Yarn, Kubernetes, Mesos）緊密相關(guān)。這導(dǎo)致用戶需要針對不同環(huán)境保留多套配置，增加了管理的成本。
在 Flink 1.10 中，作業(yè)提交邏輯被抽象到了通用的 Executor 接口。新增加的 ExecutorCLI （引入了為任意執(zhí)行目標指定配置參數(shù)的統(tǒng)一方法。此外，隨著引入 JobClient負責獲取 JobExecutionResult，獲取作業(yè)執(zhí)行結(jié)果的邏輯也得以與作業(yè)提交解耦。
對于想要在容器化環(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)限的服務(wù)賬號。
Table API/SQL: 生產(chǎn)可用的 Hive 集成
Flink 1.9 推出了預(yù)覽版的 Hive 集成。該版本允許用戶使用 SQL DDL 將 Flink 特有的元數(shù)據(jù)持久化到 Hive Metastore、調(diào)用 Hive 中定義的 UDF 以及讀、寫 Hive 中的表。Flink 1.10 進一步開發(fā)和完善了這一特性，帶來了全面兼容 Hive 主要版本的生產(chǎn)可用的 Hive 集成。
此前，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)絡(luò)傳輸?shù)臄?shù)據(jù)量。
讀取數(shù)據(jù)時的 ORC 向量化：為了提高讀取 ORC 文件的性能，對于 Hive 2.0.0 及以上版本以及非復(fù)合數(shù)據(jù)類型的列，F(xiàn)link 現(xiàn)在默認使用原生的 ORC 向量化讀取器。
59、Flink的重啟策略
固定延遲重啟策略是嘗試給定次數(shù)重新啟動作業(yè)。如果超過最大嘗試次數(shù)，則作業(yè)失敗。在兩次連續(xù)重啟嘗試之間，會有一個固定的延遲等待時間。
故障率重啟策略在故障后重新作業(yè)，當設(shè)置的故障率（failure rate）超過每個時間間隔的故障時，作業(yè)最終失敗。在兩次連續(xù)重啟嘗試之間，重啟策略延遲等待一段時間。
使用群集定義的重新啟動策略。這對于啟用檢查點的流式傳輸程序很有幫助。默認情況下，如果沒有定義其他重啟策略，則選擇固定延遲重啟策略。
60、Flink什么時候用aggregate()或者process()
當計算累加操作時候可以使用aggregate操作。
當計算窗口內(nèi)全量數(shù)據(jù)的時候使用process，例如排序等操作。
61、Flink優(yōu)化 你了解多少
62、Flink內(nèi)存溢出怎么辦
63、說說Flink中的keyState包含哪些數(shù)據(jù)結(jié)構(gòu)
64、Flink shardGroup的概念
版權(quán)聲明：本文為大數(shù)據(jù)技術(shù)與架構(gòu)原創(chuàng)整理，轉(zhuǎn)載需作者授權(quán)。未經(jīng)作者允許轉(zhuǎn)載追究侵權(quán)責任。
編輯 | 《大數(shù)據(jù)技術(shù)與架構(gòu)》
歡迎點贊+收藏+轉(zhuǎn)發(fā)朋友圈素質(zhì)三連
