前言
微信搜【Java3y】關注這個樸實無華的男人，點贊關注是對我最大的支持！git
文本已收錄至個人GitHub：https://github.com/ZhongFuCheng3y/3y，有300多篇原創文章，最近在連載面試和項目系列！github
在前段時間寫了一篇《Storm》入門的文章，不少同窗給我說：「大人，時代變了」。web
最近公司要把Storm集羣給下線啦，因此咱們都得把Storm的任務都改爲Flink。面試
因而最近入門了一把Flink，如今來分享一下Flink入門的相關知識。數據庫
（寫上面這一段話的時候，到發文章這個時候已通過了一個季度了，很差意思，我這篇文章拖了一個季度）服務器
不得不說，Flink這兩年是真的火🔥這篇文章主要講講Flink入門時一些可能看不太懂的點又或是看官方介紹看不太懂的點（API我就不細說了，多用用應該都能看懂）。微信
什麼是Flink？
在Flink的官網上，能夠把官方文檔語言設置爲中文，因而咱們能夠看到官方是這樣介紹的：網絡
上面的圖咱們每一個字都能看得懂，但連起來就看不懂了。框架
無論怎麼樣，咱們能夠了解到：Flink是一個分佈式的計算處理引擎分佈式
-
分佈式：「它的存儲或者計算交由多臺服務器上完成，最後彙總起來達到最終的效果」。
-
實時：處理速度是毫秒級或者秒級的
-
計算：能夠簡單理解爲對數據進行處理，好比清洗數據（對數據進行規整，取出有用的數據）
基於官網的一句話介紹，咱們就能夠聯想出不少東西。
這篇文章能夠帶你簡單認識一下Flink的一些基礎概念，等你真正用到的時候就能夠依據這篇文章來對Flink進行入門，如今Storm都被不少人給拋棄掉了，那麼Flink優於Storm的地方有哪些呢？接下來咱們一塊兒來看看Flink吧。
什麼是有邊界和無邊界？
Apache Flink 是一個框架和分佈式處理引擎，用於在無邊界和有邊界數據流上進行有狀態的計算。
官方其實也有介紹，但對初學者來講不太好理解，我來幼兒園化一下。
你們學到Flink了，消息隊列確定有用過吧？那大家是怎麼用消息隊列的呢？Producer生產數據，發給Broker，Consumer消費，完事。
在消費的時候，咱們須要管什麼Producer何時發消息嗎？不須要吧。反正來一條，我就處理一條，沒毛病吧。
這種沒有作任何處理的消息，默認就是無邊界的。
那有邊界就很好理解了：無邊界的基礎上加上條件，那就是有邊界的。加什麼條件呢？好比我要加個時間：我要消費從8月8號到8月9號的數據，那就是有邊界的。
何時用無邊界，何時用有邊界？那也很好理解。我作數據清洗：來一條，我處理一條，這種無邊界的就行了。我要作數據統計：每一個小時的pv(page view)是多少，那我就設置1小時的邊界，攢着一小時的數據來處理一次。
在Flink上，設置「邊界」這種操做叫作開窗口(Windows)，窗口可簡單分爲兩種類型：
-
時間窗口(
TimeWindows)：按照時間窗口進行聚合，好比上面所講得攥着一個小時的數據處理一次。 -
計數窗口(
CountWindows)：按照指定的條數來進行聚合，好比每來了10條數據處理一次。
看着就很是人性化（媽媽不再用擔憂我須要聚合了）...
不只如此，在Flink使用窗口聚合的時候，還考慮到了數據的準確性問題。好比說：如今我在11:06分產生了5條數據，在11:07分 產生了4條數據，我如今是按每分鐘的維度來進行聚合計算。
理論上來說：Flink應該是在06分聚合了5條數據，在07分聚合了4條數據。可是，可能因爲網絡的延遲性等緣由，致使06分的3條數據在07分時Flink才接收到。若是不作任何處理，那07分有可能處理了7條條數據。
某些須要準確結果的場景來講，這就不太合理了。因此Flink能夠給咱們指定」時間語義「，不指定默認是「數據到Flink的時間」Processing Time來進行聚合處理，能夠給咱們指定聚合的時間以「事件發生的時間」Event Time來進行處理。
事件發生的時間指的就是：日誌真正記錄的時間
2020-11-22 00:00:02.552 INFO [http-nio-7001-exec-28] c.m.t.rye.admin.web.aop.LogAspect
雖然指定了聚合的時間爲「事件發生的時間」Event Time，但仍是沒解決數據亂序的問題（06分產生了5條數據，實際上06分只收到了3條，而剩下的兩條在07分才收到，那此時怎麼辦呢？在06分時該不應聚合，07分收到的兩條06分數據怎麼辦？）
Flink又能夠給咱們設置水位線(waterMarks)，Flink意思就是：存在網絡延遲等狀況致使數據接收不是有序，這種狀況我都能理解。你這樣吧，根據自身的狀況，你能夠設置一個「延遲時間」，等延遲的時間到了，我再聚合統一聚合。
好比說：如今我知道數據有可能會延遲一分鐘，那我將水位線waterMarks設置延遲一分鐘。
解讀：由於設置了「事件發生的時間」Event Time，因此Flink能夠檢測到每一條記錄發生的時間，而設置了水位線waterMarks設置延遲一分鐘，等到Flink發現07分:59秒的數據來到了Flink，那就確信06分的數據都來了（由於設置了1分鐘延遲），此時才聚合06分的窗口數據。
什麼叫作有狀態？
Apache Flink 是一個框架和分佈式處理引擎，用於在無邊界和有邊界數據流上進行有狀態的計算。
什麼是有狀態，什麼是無狀態？
無狀態咱們能夠簡單認爲：每次的執行都不依賴上一次或上N次的執行結果，每次的執行都是獨立的。
有狀態咱們能夠簡單認爲：執行須要依賴上一次或上N次的執行結果，某次的執行須要依賴前面事件的處理結果。
好比，咱們如今要統計文章的閱讀PV(page view)，如今只要有一個點擊了文章，在Kafka就會有一條消息。如今我要在流式處理平臺上進行統計，那此時是有狀態的仍是無狀態的？
假設咱們要在Storm作，那咱們可能將每次的處理結果放到一個「外部存儲」中，而後基於這個「外部存儲」進行計算（這裏咱們不用Storm Trident），那此時Storm是無狀態的。
好比說：我存儲將每次獲得的數據存儲到 Redis中，來一條數據，我就先查一下Redis目前的值是多少，跟Redis的值和如今的值作一次累加就完事了。
假設要在Flink作，Flink自己就提供了這種功能給咱們使用，咱們能夠依賴Flink的「存儲」，將每次的處理結果交由Flink管理，執行計算的邏輯。
能夠簡單的認爲：Flink自己就給咱們提供了」存儲「的功能，而咱們每次執行是能夠依賴Flink的」存儲」的，因此它是有狀態的。
那Flink是把這些有狀態的數據存儲在哪的呢？
主要有三個地方：
-
內存
-
文件系統（HDFS）
-
本地數據庫
若是假設Flink掛了，可能內存的數據沒了，磁盤可能存儲了部分的數據，那再重啓的時候（好比消息隊列會從新拉取），就不怕會丟了或多了數據嗎？
看到這裏，你可能在會在別的地方看過Flink的另一個比較出名的特性：精確一次性
（簡單來講就是：Flink遇到意外事件掛了之後，有什麼機制來儘量保證處理數據不重複和不丟失的呢）
什麼是精確一次性（exactly once）？
衆所周知，流的語義性有三種：
-
精確一次性（exactly once）：有且只有一條，很少很多
-
至少一次（at least once）：最少會有一條，只多很多
-
最多一次（at most once）：最多隻有一條，可能會沒有
Flink實現了精確一次性，這個精確一次性是什麼意思呢？
Flink的精確一次性指的是：狀態只持久化一次到最終的存儲介質中（本地數據庫/HDFS...)
以上面的圖爲例：Source數據流有如下數字21,13,8,5,3,2,1,1，而後在Flink須要作累加操做（求和）
如今處理完2,1,1了，因此累加的值是4，如今Flink把累積後的狀態4已經存儲起來了（認爲前面2,1,1這幾個數字已經徹底處理過了）。
程序一直往下走，處理了5,3，如今累加的值是12，但如今Flink還沒來得及把12存儲到最終的介質，此時系統掛掉了。
Flink重啓後會從新把系統恢復到累加的值是4的狀態，因此5,3得繼續計算一遍，程序繼續往下走。
看文章有的同窗可能會認爲：精確一次性指的不是某一段代碼只會執行一次，不會執行屢次或不執行。這5和3這兩個數，你不是重複計算了嗎？怎麼就精確一次了？
顯然，代碼只執行一次確定是不可能的嘛。咱們沒法控制系統在哪一行代碼掛掉的，你要是在掛的時候，當前方法還沒執行完，你仍是得從新執行該方法的。
因此，狀態只持久化一次到最終的存儲介質中（本地數據庫/HDFS)，在Flink下就叫作exactly once（計算的數據可能會重複（沒法避免），但狀態在存儲介質上只會存儲一次）。
那麼Flink是在多長時間存儲一次的呢？這個是咱們本身手動配置的。
所謂的CheckPoint其實就是Flink會在指定的時間段上保存狀態的信息，假設Flink掛了能夠將上一次狀態信息再撈出來，重放還沒保存的數據來執行計算，最終實現exactly once。
那CheckPonit是怎麼辦到的呢？想一想咱們在Kafka在業務上實現「至少一次」是怎麼作的？咱們從Kafka把數據拉下來，處理完業務了之後，手動提交offset (告訴Kafka我已經處理完了)
咱們是作完了業務規則纔將offset進行commit的，checkponit其實也是同樣的（等拉下來該條數據全部的流程走完，才進行真正的checkponit）。
問題又來了，那checkpoint是怎麼知道拉下來的數據已經走完了呢？Flink在流處理過程當中插入了barrier，每一個環節處理到barrier都會上報，等到sink都上報了barrier就說明此次checkpoint已經走完了。
要注意的是，Flink實現的精確一次性只是保證內部的狀態是精確一次的，若是想要端到端精確一次，須要端的支持
-
數據源須要可回放，發證故障能夠從新讀取未確認的數據
-
Flink須要把數據存到磁盤介質（不能用內存），發生故障能夠恢復 -
發送源須要支持事務（從讀到寫須要事務的支持保證中途不失敗）
最後
這篇文章對Flink作了一次簡單的介紹，但願對你們在入門的時候有所幫助。後續打算會再寫一篇Flink文章對CheckPoint機制作更加深刻的瞭解，有興趣的同窗能夠點個關注第一時間能接收到。
三歪把【大廠面試知識點】、【簡歷模板】、【原創文章】所有整理成電子書，共有1263頁！點擊下方連接直接取就行了
PDF文檔的內容均爲手打，有任何的不懂均可以直接來問我