三歪鴿了一個(gè)季度的Flink入門教程
三歪第401篇原創(chuàng)文章
在前段時(shí)間寫了一篇《Storm》入門的文章，很多同學(xué)給我說：“大人，時(shí)代變了”。
最近公司要把Storm集群給下線啦，所以我們都得把Storm的任務(wù)都改成Flink。
于是最近入門了一把Flink，現(xiàn)在來分享一下Flink入門的相關(guān)知識(shí)。
（寫上面這一段話的時(shí)候，到發(fā)文章這個(gè)時(shí)候已經(jīng)過了一個(gè)季度了，不好意思，我這篇文章拖了一個(gè)季度）
不得不說，F(xiàn)link這兩年是真的火?這篇文章主要講講Flink入門時(shí)一些可能看不太懂的點(diǎn)又或是看官方介紹看不太懂的點(diǎn)（API我就不細(xì)說了，多用用應(yīng)該都能看懂）。
什么是Flink？
在Flink的官網(wǎng)上，可以把官方文檔語(yǔ)言設(shè)置為中文，于是我們可以看到官方是這樣介紹的：
上面的圖我們每個(gè)字都能看得懂，但連起來就看不懂了。
不管怎么樣，我們可以了解到：Flink是一個(gè)分布式的計(jì)算處理引擎
分布式：「它的存儲(chǔ)或者計(jì)算交由多臺(tái)服務(wù)器上完成，最后匯總起來達(dá)到最終的效果」。
實(shí)時(shí)：處理速度是毫秒級(jí)或者秒級(jí)的
計(jì)算：可以簡(jiǎn)單理解為對(duì)數(shù)據(jù)進(jìn)行處理，比如清洗數(shù)據(jù)（對(duì)數(shù)據(jù)進(jìn)行規(guī)整，取出有用的數(shù)據(jù)）
基于官網(wǎng)的一句話介紹，我們就可以聯(lián)想出很多東西。
這篇文章可以帶你簡(jiǎn)單認(rèn)識(shí)一下Flink的一些基礎(chǔ)概念，等你真正用到的時(shí)候就可以依據(jù)這篇文章來對(duì)Flink進(jìn)行入門，現(xiàn)在Storm都被很多人給拋棄掉了，那么Flink優(yōu)于Storm的地方有哪些呢？接下來我們一起來看看Flink吧。
什么是有邊界和無邊界？
Apache Flink 是一個(gè)框架和分布式處理引擎，用于在無邊界和有邊界數(shù)據(jù)流上進(jìn)行有狀態(tài)的計(jì)算。
官方其實(shí)也有介紹，但對(duì)初學(xué)者來說不太好理解，我來幼兒園化一下。
大家學(xué)到Flink了，消息隊(duì)列肯定有用過吧？那你們是怎么用消息隊(duì)列的呢？Producer生產(chǎn)數(shù)據(jù)，發(fā)給Broker，Consumer消費(fèi)，完事。
在消費(fèi)的時(shí)候，我們需要管什么Producer什么時(shí)候發(fā)消息嗎？不需要吧。反正來一條，我就處理一條，沒毛病吧。
這種沒有做任何處理的消息，默認(rèn)就是無邊界的。
那有邊界就很好理解了：無邊界的基礎(chǔ)上加上條件，那就是有邊界的。加什么條件呢？比如我要加個(gè)時(shí)間：我要消費(fèi)從8月8號(hào)到8月9號(hào)的數(shù)據(jù)，那就是有邊界的。
什么時(shí)候用無邊界，什么時(shí)候用有邊界？那也很好理解。我做數(shù)據(jù)清洗：來一條，我處理一條，這種無邊界的就好了。我要做數(shù)據(jù)統(tǒng)計(jì)：每個(gè)小時(shí)的pv(page view)是多少，那我就設(shè)置1小時(shí)的邊界，攢著一小時(shí)的數(shù)據(jù)來處理一次。
在Flink上，設(shè)置“邊界”這種操作叫做開窗口(Windows)，窗口可簡(jiǎn)單分為兩種類型：
時(shí)間窗口( TimeWindows)：按照時(shí)間窗口進(jìn)行聚合，比如上面所講得攥著一個(gè)小時(shí)的數(shù)據(jù)處理一次。計(jì)數(shù)窗口( CountWindows)：按照指定的條數(shù)來進(jìn)行聚合，比如每來了10條數(shù)據(jù)處理一次。
看著就非常人性化（媽媽再也不用擔(dān)心我需要聚合了）...
不僅如此，在Flink使用窗口聚合的時(shí)候，還考慮到了數(shù)據(jù)的準(zhǔn)確性問題。比如說：現(xiàn)在我在11:06分產(chǎn)生了5條數(shù)據(jù)，在11:07分 產(chǎn)生了4條數(shù)據(jù)，我現(xiàn)在是按每分鐘的維度來進(jìn)行聚合計(jì)算。
理論上來講：Flink應(yīng)該是在06分聚合了5條數(shù)據(jù)，在07分聚合了4條數(shù)據(jù)。但是，可能由于網(wǎng)絡(luò)的延遲性等原因，導(dǎo)致06分的3條數(shù)據(jù)在07分時(shí)Flink才接收到。如果不做任何處理，那07分有可能處理了7條條數(shù)據(jù)。
某些需要準(zhǔn)確結(jié)果的場(chǎng)景來說，這就不太合理了。所以Flink可以給我們指定”時(shí)間語(yǔ)義“，不指定默認(rèn)是「數(shù)據(jù)到Flink的時(shí)間」Processing Time來進(jìn)行聚合處理，可以給我們指定聚合的時(shí)間以「事件發(fā)生的時(shí)間」Event Time來進(jìn)行處理。
事件發(fā)生的時(shí)間指的就是：日志真正記錄的時(shí)間
2020-11-22?00:00:02.552?INFO??[http-nio-7001-exec-28]?c.m.t.rye.admin.web.aop.LogAspect?
雖然指定了聚合的時(shí)間為「事件發(fā)生的時(shí)間」Event Time，但還是沒解決數(shù)據(jù)亂序的問題（06分產(chǎn)生了5條數(shù)據(jù)，實(shí)際上06分只收到了3條，而剩下的兩條在07分才收到，那此時(shí)怎么辦呢？在06分時(shí)該不該聚合，07分收到的兩條06分?jǐn)?shù)據(jù)怎么辦？）
Flink又可以給我們?cè)O(shè)置水位線(waterMarks)，F(xiàn)link意思就是：存在網(wǎng)絡(luò)延遲等情況導(dǎo)致數(shù)據(jù)接收不是有序，這種情況我都能理解。你這樣吧，根據(jù)自身的情況，你可以設(shè)置一個(gè)「延遲時(shí)間」，等延遲的時(shí)間到了，我再聚合統(tǒng)一聚合。
比如說：現(xiàn)在我知道數(shù)據(jù)有可能會(huì)延遲一分鐘，那我將水位線waterMarks設(shè)置延遲一分鐘。
解讀：因?yàn)樵O(shè)置了「事件發(fā)生的時(shí)間」Event Time，所以Flink可以檢測(cè)到每一條記錄發(fā)生的時(shí)間，而設(shè)置了水位線waterMarks設(shè)置延遲一分鐘，等到Flink發(fā)現(xiàn)07分:59秒的數(shù)據(jù)來到了Flink，那就確信06分的數(shù)據(jù)都來了（因?yàn)樵O(shè)置了1分鐘延遲），此時(shí)才聚合06分的窗口數(shù)據(jù)。
什么叫做有狀態(tài)？
Apache Flink 是一個(gè)框架和分布式處理引擎，用于在無邊界和有邊界數(shù)據(jù)流上進(jìn)行有狀態(tài)的計(jì)算。
什么是有狀態(tài)，什么是無狀態(tài)？
無狀態(tài)我們可以簡(jiǎn)單認(rèn)為：每次的執(zhí)行都不依賴上一次或上N次的執(zhí)行結(jié)果，每次的執(zhí)行都是獨(dú)立的。
有狀態(tài)我們可以簡(jiǎn)單認(rèn)為：執(zhí)行需要依賴上一次或上N次的執(zhí)行結(jié)果，某次的執(zhí)行需要依賴前面事件的處理結(jié)果。
比如，我們現(xiàn)在要統(tǒng)計(jì)文章的閱讀PV(page view)，現(xiàn)在只要有一個(gè)點(diǎn)擊了文章，在Kafka就會(huì)有一條消息。現(xiàn)在我要在流式處理平臺(tái)上進(jìn)行統(tǒng)計(jì)，那此時(shí)是有狀態(tài)的還是無狀態(tài)的？
假設(shè)我們要在Storm做，那我們可能將每次的處理結(jié)果放到一個(gè)“外部存儲(chǔ)”中，然后基于這個(gè)“外部存儲(chǔ)”進(jìn)行計(jì)算（這里我們不用Storm Trident），那此時(shí)Storm是無狀態(tài)的。
比如說：我存儲(chǔ)將每次得到的數(shù)據(jù)存儲(chǔ)到 Redis中，來一條數(shù)據(jù)，我就先查一下Redis目前的值是多少，跟Redis的值和現(xiàn)在的值做一次累加就完事了。
假設(shè)要在Flink做，Flink本身就提供了這種功能給我們使用，我們可以依賴Flink的“存儲(chǔ)”，將每次的處理結(jié)果交由Flink管理，執(zhí)行計(jì)算的邏輯。
可以簡(jiǎn)單的認(rèn)為：Flink本身就給我們提供了”存儲(chǔ)“的功能，而我們每次執(zhí)行是可以依賴Flink的”存儲(chǔ)”的，所以它是有狀態(tài)的。
那Flink是把這些有狀態(tài)的數(shù)據(jù)存儲(chǔ)在哪的呢？
主要有三個(gè)地方：
內(nèi)存 文件系統(tǒng)（HDFS） 本地?cái)?shù)據(jù)庫(kù)
如果假設(shè)Flink掛了，可能內(nèi)存的數(shù)據(jù)沒了，磁盤可能存儲(chǔ)了部分的數(shù)據(jù)，那再重啟的時(shí)候（比如消息隊(duì)列會(huì)重新拉取），就不怕會(huì)丟了或多了數(shù)據(jù)嗎？
看到這里，你可能在會(huì)在別的地方看過Flink的另外一個(gè)比較出名的特性：精確一次性
（簡(jiǎn)單來說就是：Flink遇到意外事件掛了以后，有什么機(jī)制來盡可能保證處理數(shù)據(jù)不重復(fù)和不丟失的呢）
什么是精確一次性（exactly once）？
眾所周知，流的語(yǔ)義性有三種：
精確一次性（exactly once）：有且只有一條，不多不少 至少一次（at least once）：最少會(huì)有一條，只多不少 最多一次（at most once）：最多只有一條，可能會(huì)沒有
Flink實(shí)現(xiàn)了精確一次性，這個(gè)精確一次性是什么意思呢？
Flink的精確一次性指的是：狀態(tài)只持久化一次到最終的存儲(chǔ)介質(zhì)中（本地?cái)?shù)據(jù)庫(kù)/HDFS...)
以上面的圖為例：Source數(shù)據(jù)流有以下數(shù)字21,13,8,5,3,2,1,1，然后在Flink需要做累加操作（求和）
現(xiàn)在處理完2,1,1了，所以累加的值是4，現(xiàn)在Flink把累積后的狀態(tài)4已經(jīng)存儲(chǔ)起來了（認(rèn)為前面2,1,1這幾個(gè)數(shù)字已經(jīng)完全處理過了）。
程序一直往下走，處理了5,3，現(xiàn)在累加的值是12，但現(xiàn)在Flink還沒來得及把12存儲(chǔ)到最終的介質(zhì)，此時(shí)系統(tǒng)掛掉了。
Flink重啟后會(huì)重新把系統(tǒng)恢復(fù)到累加的值是4的狀態(tài)，所以5,3得繼續(xù)計(jì)算一遍，程序繼續(xù)往下走。
看文章有的同學(xué)可能會(huì)認(rèn)為：精確一次性指的不是某一段代碼只會(huì)執(zhí)行一次，不會(huì)執(zhí)行多次或不執(zhí)行。這5和3這兩個(gè)數(shù)，你不是重復(fù)計(jì)算了嗎？怎么就精確一次了？
顯然，代碼只執(zhí)行一次肯定是不可能的嘛。我們無法控制系統(tǒng)在哪一行代碼掛掉的，你要是在掛的時(shí)候，當(dāng)前方法還沒執(zhí)行完，你還是得重新執(zhí)行該方法的。
所以，狀態(tài)只持久化一次到最終的存儲(chǔ)介質(zhì)中（本地?cái)?shù)據(jù)庫(kù)/HDFS)，在Flink下就叫做exactly once（計(jì)算的數(shù)據(jù)可能會(huì)重復(fù)（無法避免），但狀態(tài)在存儲(chǔ)介質(zhì)上只會(huì)存儲(chǔ)一次）。
那么Flink是在多長(zhǎng)時(shí)間存儲(chǔ)一次的呢？這個(gè)是我們自己手動(dòng)配置的。
所謂的CheckPoint其實(shí)就是Flink會(huì)在指定的時(shí)間段上保存狀態(tài)的信息，假設(shè)Flink掛了可以將上一次狀態(tài)信息再撈出來，重放還沒保存的數(shù)據(jù)來執(zhí)行計(jì)算，最終實(shí)現(xiàn)exactly once。
那CheckPonit是怎么辦到的呢？想想我們?cè)?code style="font-size: 14px;padding: 2px 4px;border-radius: 4px;margin-right: 2px;margin-left: 2px;color: rgb(30, 107, 184);background-color: rgba(27, 31, 35, 0.05);font-family: "Operator Mono", Consolas, Monaco, Menlo, monospace;word-break: break-all;">Kafka在業(yè)務(wù)上實(shí)現(xiàn)「至少一次」是怎么做的？我們從Kafka把數(shù)據(jù)拉下來，處理完業(yè)務(wù)了以后，手動(dòng)提交offset (告訴Kafka我已經(jīng)處理完了)
我們是做完了業(yè)務(wù)規(guī)則才將offset進(jìn)行commit的，checkponit其實(shí)也是一樣的（等拉下來該條數(shù)據(jù)所有的流程走完，才進(jìn)行真正的checkponit）。
問題又來了，那checkpoint是怎么知道拉下來的數(shù)據(jù)已經(jīng)走完了呢？Flink在流處理過程中插入了barrier，每個(gè)環(huán)節(jié)處理到barrier都會(huì)上報(bào)，等到sink都上報(bào)了barrier就說明這次checkpoint已經(jīng)走完了。
要注意的是，Flink實(shí)現(xiàn)的精確一次性只是保證內(nèi)部的狀態(tài)是精確一次的，如果想要端到端精確一次，需要端的支持
數(shù)據(jù)源需要可回放，發(fā)證故障可以重新讀取未確認(rèn)的數(shù)據(jù) Flink需要把數(shù)據(jù)存到磁盤介質(zhì)（不能用內(nèi)存），發(fā)生故障可以恢復(fù)發(fā)送源需要支持事務(wù)（從讀到寫需要事務(wù)的支持保證中途不失敗）
最后
這篇文章對(duì)Flink做了一次簡(jiǎn)單的介紹，希望對(duì)大家在入門的時(shí)候有所幫助。后續(xù)打算會(huì)再寫一篇Flink文章對(duì)CheckPoint機(jī)制做更加深入的了解，有興趣的同學(xué)可以點(diǎn)個(gè)關(guān)注第一時(shí)間能接收到。
原創(chuàng)電子書
原創(chuàng)思維導(dǎo)圖
已經(jīng)有8756個(gè)初學(xué)者都下載了！?三歪把【大廠面試知識(shí)點(diǎn)】、【簡(jiǎn)歷模板】、【原創(chuàng)文章】全部整理成電子書，共有1263頁(yè)！掃碼或微信搜 Java3y?回復(fù)「888」領(lǐng)取
 |
|
