相信小夥伴們對於Flink必定不會感到陌生，做爲連續三年蟬聯第一，榮膺全球最活躍的 Apache 開源項目，Flink在中國的熱度也一直是居高不下。近幾年，在社區的推進下，Flink 技術棧在愈來愈多的公司開始獲得應用，所以在大數據的求職招聘中，對於Flink的着重考察也變得愈來愈重要。本期文章，菌哥就帶你們來總結一下，在面試過程當中，Flink常被問到的知識點有哪些？若是本文對你有幫助，記得在看完以後，一鍵三連(✧◡✧)
web
一、應用架構
問題：公司怎麼提交的實時任務，有多少 Job Manager？面試
解答：redis
1. 咱們使用 yarn session 模式提交任務。每次提交都會建立一個新的 Flink 集羣，爲每個 job 提供一個 yarn-session，任務之間互相獨立，互不影響， 方便管理。任務執行完成以後建立的集羣也會消失。線上命令腳本以下：編程
bin/yarn-session.sh -n 7 -s 8 -jm 3072 -tm 32768 -qu root.*.* -nm *-* -d
其中申請 7 個 taskManager，每一個 8 核，每一個 taskmanager 有 32768M 內存。後端
2. 集羣默認只有一個 Job Manager。但爲了防止單點故障，咱們配置了高可用。 咱們公司通常配置一個主 Job Manager，兩個備用 Job Manager，而後結合 ZooKeeper 的使用，來達到高可用。bash
二、壓測和監控
問題：怎麼作壓力測試和監控？微信
解答：咱們通常碰到的壓力來自如下幾個方面：網絡
一，產生數據流的速度若是過快，而下游的算子消費不過來的話，會產生背壓。 背壓的監控可使用 Flink Web UI(localhost:8081) 來可視化監控，一旦報警就能知道。通常狀況下背壓問題的產生多是因爲 sink 這個 操做符沒有優化好，作一下 優化就能夠了。好比若是是寫入 ElasticSearch， 那麼能夠改爲批量寫入，能夠調 大 ElasticSearch 隊列的大小等等策略。session
二，設置 watermark 的最大延遲時間這個參數，若是設置的過大，可能會形成內存的壓力。能夠設置最大延遲時間小一些，而後把遲到元素髮送到側輸出流中去。 晚一點更新結果。或者使用相似於 RocksDB 這樣的狀態後端， RocksDB 會開闢堆外存儲空間，但 IO 速度會變慢，須要權衡。數據結構
三，還有就是滑動窗口的長度若是過長，而滑動距離很短的話，Flink 的性能會降低的很厲害。咱們主要經過時間分片的方法，將每一個元素只存入一個「重疊窗 口」，這樣就能夠減小窗口處理中狀態的寫入。（詳情連接：Flink 滑動窗口優化）
四，狀態後端使用 RocksDB，尚未碰到被撐爆的問題
三、爲何用 Flink
問題：爲何使用 Flink 替代 Spark？
解答：主要考慮的是 flink 的低延遲、高吞吐量和對流式數據應用場景更好的支持；另外，flink 能夠很好地處理亂序數據，並且能夠保證 exactly-once 的狀態一致性。
四、checkpoint 的理解
問題：如何理解Flink的checkpoint
解答：Checkpoint是Flink實現容錯機制最核心的功能，它可以根據配置週期性地基於Stream中各個Operator/task的狀態來生成快照，從而將這些狀態數據按期持久化存儲下來，當Flink程序一旦意外崩潰時，從新運行程序時能夠有選擇地從這些快照進行恢復，從而修正由於故障帶來的程序數據異常。他能夠存在內存，文件系統，或者 RocksDB。
五、exactly-once 的保證
問題：若是下級存儲不支持事務，Flink 怎麼保證 exactly-once？
解答：端到端的 exactly-once 對 sink 要求比較高，具體實現主要有冪等寫入和 事務性寫入兩種方式。冪等寫入的場景依賴於業務邏輯，更常見的是用事務性寫入。 而事務性寫入又有預寫日誌（WAL）和兩階段提交（2PC）兩種方式。
若是外部系統不支持事務，那麼能夠用預寫日誌的方式，把結果數據先當成狀態保存，而後在收到 checkpoint 完成的通知時，一次性寫入 sink 系統。
六、狀態機制
問題：說一下 Flink 狀態機制？
解答：Flink 內置的不少算子，包括源 source，數據存儲 sink 都是有狀態的。在 Flink 中，狀態始終與特定算子相關聯。Flink 會以 checkpoint 的形式對各個任務的 狀態進行快照，用於保證故障恢復時的狀態一致性。Flink 經過狀態後端來管理狀態 和 checkpoint 的存儲，狀態後端也能夠有不一樣的配置選擇。
七、海量 key 去重
問題：怎麼去重？考慮一個實時場景：雙十一場景，滑動窗口長度爲 1 小時， 滑動距離爲 10 秒鐘，億級用戶，怎樣計算 UV？
解答：使用相似於 scala 的 set 數據結構或者 redis 的 set 顯然是不行的， 由於可能有上億個 Key，內存放不下。因此能夠考慮使用布隆過濾器（Bloom Filter） 來去重。
八、checkpoint 與 spark 比較
問題：Flink 的 checkpoint 機制對比 spark 有什麼不一樣和優點？
解答： spark streaming 的 checkpoint 僅僅是針對 driver 的故障恢復作了數據和元數據的checkpoint。而 flink 的 checkpoint 機制要複雜了不少，它採用的是輕量級的分佈式快照，實現了每一個算子的快照，及流動中的數據的快照。
九、watermark 機制
問題：請詳細解釋一下 Flink 的 Watermark 機制。
解答：在使用 EventTime 處理 Stream 數據的時候會遇到數據亂序的問題，流處理從 Event（事 件）產生，流經 Source，再到 Operator，這中間須要必定的時間。雖然大部分狀況下，傳輸到 Operator 的數據都是按照事件產生的時間順序來的，可是也不排除因爲網絡延遲等緣由而致使亂序的產生，特別是使用 Kafka 的時候，多個分區之間的數據沒法保證有序。所以， 在進行 Window 計算的時候，不能無限期地等下去，必需要有個機制來保證在特定的時間後， 必須觸發 Window 進行計算，這個特別的機制就是 Watermark（水位線）。Watermark是用於處理亂序事件的。
在 Flink 的窗口處理過程當中，若是肯定所有數據到達，就能夠對 Window 的全部數據作窗口計算操做（如彙總、分組等），若是數據沒有所有到達，則繼續等待該窗口中的數據所有到達纔開始處理。這種狀況下就須要用到水位線(WaterMarks)機制，它可以衡量數據處理進度（表達數據到達的完整性），保證事件數據（所有）到達 Flink 系統，或者在亂序及延遲到達時，也可以像預期同樣計算出正確而且連續的結果。
十、exactly-once 如何實現
問題：Flink 中 exactly-once 語義是如何實現的，狀態是如何存儲的？
解答：Flink 依靠 checkpoint 機制來實現 exactly-once 語義，若是要實現端到端 的 exactly-once，還須要外部 source 和 sink 知足必定的條件。狀態的存儲經過狀態 後端來管理，Flink 中能夠配置不一樣的狀態後端。
十一、CEP
問題：Flink CEP 編程中當狀態沒有到達的時候會將數據保存在哪裏？
解答：在流式處理中，CEP 固然是要支持 EventTime 的，那麼相對應的也要支持數據的遲到現象，也就是 watermark的處理邏輯。CEP對未匹配成功的事件序 列的處理，和遲到數據是相似的。在 Flink CEP 的處理邏輯中，狀態沒有知足的和遲到的數據，都會存儲在一個 Map 數據結構中，也就是說，若是咱們限定判斷事件 序列的時長爲5 分鐘，那麼內存中就會存儲 5 分鐘的數據，這在我看來，也是對內存的極大損傷之一。
十二、三種時間語義
問題：Flink 三種時間語義是什麼，分別說出應用場景？
解答：
-
Event Time：這是實際應用最多見的時間語義，指的是事件建立的時間，每每跟watermark結合使用
-
Processing Time：指每個執行基於時間操做的算子的本地系統時間，與機器相關。適用場景：沒有事件時間的狀況下，或者對實時性要求超高的狀況
-
Ingestion Time：指數據進入Flink的時間。適用場景：存在多個 Source Operator 的狀況下，每一個 Source Operator 可使用本身本地系統時鐘指派 Ingestion Time。後續基於時間相關的各類操做， 都會使用數據記錄中的 Ingestion Time
1三、數據高峯的處理
問題：Flink 程序在面對數據高峯期時如何處理？
解答：使用大容量的 Kafka 把數據先放到消息隊列裏面做爲數據源，再使用 Flink 進行消費，不過這樣會影響到一點實時性。
小結
本次分享的Flink面試題難度不大，但足夠考驗一個數據工程師對於Flink的基本認知水平。要想職業道路好走，就得跟上技術發展的潮流！本期文章就到這裏，後期會爲你們分享更多幹貨內容，敬請期待！你知道的越多，你不知道的也越多，我是Alice，咱們下一期見！
彩蛋
爲了能鼓勵你們多學會總結，菌在這裏貼上本身平時作的思惟導圖，須要的朋友，能夠關注博主我的微信公衆號【猿人菌】，後臺回覆「思惟導圖」便可獲取。
更有海量面經奉送
本文同步分享在 博客「Alice菌」（CSDN）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。