不一樣的Flink入門教程

Java3y發表於2020-11-26

前言

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

文字已收錄至我的GitHubhttps://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生產資料,發給BrokerConsumer消費,完事。

在消費的時候,我們需要管什麼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得繼續計算一遍,程式繼續往下走。

看文章有的同學可能會認為:精確一次性指的不是某一段程式碼只會執行一次,不會執行多次或不執行。這53這兩個數,你不是重複計算了嗎?怎麼就精確一次了?

顯然,程式碼只執行一次肯定是不可能的嘛。我們無法控制系統在哪一行程式碼掛掉的,你要是在掛的時候,當前方法還沒執行完,你還是得重新執行該方法的。

所以,狀態只持久化一次最終的儲存介質中(本地資料庫/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文件的內容均為手打,有任何的不懂都可以直接來問我

相關文章