溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章主要講解了“Flink面試題有哪些”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“Flink面試題有哪些”吧！
問題：公司怎么提交的實時任務，有多少 Job Manager？
解答：
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 的使用，來達到高可用。
問題：怎么做壓力測試和監控？
解答：我們一般碰到的壓力來自以下幾個方面：
一，產生數據流的速度如果過快，而下游的算子消費不過來的話，會產生背壓。 背壓的監控可以使用 Flink Web UI(localhost:8081) 來可視化監控，一旦報警就能知道。一般情況下背壓問題的產生可能是由于 sink 這個 操作符沒有優化好，做一下 優化就可以了。比如如果是寫入 ElasticSearch， 那么可以改成批量寫入，可以調 大 ElasticSearch 隊列的大小等等策略。
二，設置 watermark 的最大延遲時間這個參數，如果設置的過大，可能會造成內存的壓力。可以設置最大延遲時間小一些，然后把遲到元素發送到側輸出流中去。 晚一點更新結果。或者使用類似于 RocksDB 這樣的狀態后端， RocksDB 會開辟堆外存儲空間，但 IO 速度會變慢，需要權衡。
三，還有就是滑動窗口的長度如果過長，而滑動距離很短的話，Flink 的性能會下降的很厲害。我們主要通過時間分片的方法，將每個元素只存入一個“重疊窗 口”，這樣就可以減少窗口處理中狀態的寫入。（詳情鏈接：Flink 滑動窗口優化）
四，狀態后端使用 RocksDB，還沒有碰到被撐爆的問題
問題：為什么使用 Flink 替代 Spark？
解答：主要考慮的是 flink 的低延遲、高吞吐量和對流式數據應用場景更好的支持；另外，flink 可以很好地處理亂序數據，而且可以保證 exactly-once 的狀態一致性。
問題：如何理解Flink的checkpoint
解答：Checkpoint是Flink實現容錯機制最核心的功能，它能夠根據配置周期性地基于Stream中各個Operator/task的狀態來生成快照，從而將這些狀態數據定期持久化存儲下來，當Flink程序一旦意外崩潰時，重新運行程序時可以有選擇地從這些快照進行恢復，從而修正因為故障帶來的程序數據異常。他可以存在內存，文件系統，或者 RocksDB。
問題：如果下級存儲不支持事務，Flink 怎么保證 exactly-once？
解答：端到端的 exactly-once 對 sink 要求比較高，具體實現主要有冪等寫入和 事務性寫入兩種方式。冪等寫入的場景依賴于業務邏輯，更常見的是用事務性寫入。 而事務性寫入又有預寫日志（WAL）和兩階段提交（2PC）兩種方式。
如果外部系統不支持事務，那么可以用預寫日志的方式，把結果數據先當成狀態保存，然后在收到 checkpoint 完成的通知時，一次性寫入 sink 系統。
問題：說一下 Flink 狀態機制？
解答：Flink 內置的很多算子，包括源 source，數據存儲 sink 都是有狀態的。在 Flink 中，狀態始終與特定算子相關聯。Flink 會以 checkpoint 的形式對各個任務的 狀態進行快照，用于保證故障恢復時的狀態一致性。Flink 通過狀態后端來管理狀態 和 checkpoint 的存儲，狀態后端也可以有不同的配置選擇。
問題：怎么去重？考慮一個實時場景：雙十一場景，滑動窗口長度為 1 小時， 滑動距離為 10 秒鐘，億級用戶，怎樣計算 UV？
解答：使用類似于 scala 的 set 數據結構或者 redis 的 set 顯然是不行的， 因為可能有上億個 Key，內存放不下。所以可以考慮使用布隆過濾器（Bloom Filter） 來去重。
問題：Flink 的 checkpoint 機制對比 spark 有什么不同和優勢？
解答： spark streaming 的 checkpoint 僅僅是針對 driver 的故障恢復做了數據和元數據的checkpoint。而 flink 的 checkpoint 機制要復雜了很多，它采用的是輕量級的分布式快照，實現了每個算子的快照，及流動中的數據的快照。
問題：請詳細解釋一下 Flink 的 Watermark 機制。
解答：在使用 EventTime 處理 Stream 數據的時候會遇到數據亂序的問題，流處理從 Event（事 件）產生，流經 Source，再到 Operator，這中間需要一定的時間。雖然大部分情況下，傳輸到 Operator 的數據都是按照事件產生的時間順序來的，但是也不排除由于網絡延遲等原因而導致亂序的產生，特別是使用 Kafka 的時候，多個分區之間的數據無法保證有序。因此， 在進行 Window 計算的時候，不能無限期地等下去，必須要有個機制來保證在特定的時間后， 必須觸發 Window 進行計算，這個特別的機制就是 Watermark（水位線）。Watermark是用于處理亂序事件的。
在 Flink 的窗口處理過程中，如果確定全部數據到達，就可以對 Window 的所有數據做窗口計算操作（如匯總、分組等），如果數據沒有全部到達，則繼續等待該窗口中的數據全部到達才開始處理。這種情況下就需要用到水位線(WaterMarks)機制，它能夠衡量數據處理進度（表達數據到達的完整性），保證事件數據（全部）到達 Flink 系統，或者在亂序及延遲到達時，也能夠像預期一樣計算出正確并且連續的結果。
問題：Flink 中 exactly-once 語義是如何實現的，狀態是如何存儲的？
解答：Flink 依靠 checkpoint 機制來實現 exactly-once 語義，如果要實現端到端 的 exactly-once，還需要外部 source 和 sink 滿足一定的條件。狀態的存儲通過狀態 后端來管理，Flink 中可以配置不同的狀態后端。
問題：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
問題：Flink 程序在面對數據高峰期時如何處理？
解答：使用大容量的 Kafka 把數據先放到消息隊列里面作為數據源，再使用 Flink 進行消費，不過這樣會影響到一點實時性。
感謝各位的閱讀，以上就是“Flink面試題有哪些”的內容了，經過本文的學習后，相信大家對Flink面試題有哪些這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
