不一樣的Flink入門教程

前言

微信搜【Java3y】關注這個樸實無華的男人，點贊關注是對我最大的支持！

文本已收錄至我的GitHub：https://github.com/ZhongFuCheng3y/3y，有300多篇原創文章，最近在連載面試和專案系列！

在前段時間寫了一篇《Storm》入門的文章，很多同學給我說：“大人，時代變了”，

最近公司要把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頁！點擊下方鏈接直接取就好了

• GitHub
• Gitee訪問更快

PDF檔案的內容均為手打，有任何的不懂都可以直接來問我