因為我不知道大數(shù)據(jù)相關(guān)的東西奶栖，F(xiàn)link也僅僅看了點皮毛盐捷，所以不敢把標(biāo)題叫做 “指北”棘捣、“指南”之類的...
今天辜腺，我們不談大數(shù)據(jù)其他相關(guān)的東西，只說說 什么是 Flink乍恐。
在Apache Flink的官方網(wǎng)站上我們可以看到這樣的項目理念：

Apache Flink is a framework and distributed processing engine for stateful computations over unbounded and bounded data streams.

相信能看到這篇文章的都是文化人评疗，我就不翻譯了（因為我看不懂）。
然而茵烈，我們好像并不能通過這簡單的一句話對Flink有個大體的認識百匆，所以請看下面這個圖

What is Flink

Lambda 架構(gòu)是構(gòu)建大數(shù)據(jù)應(yīng)用程序的一種很有效的框架，但它還不夠好乃戈。舉例來說褂痰，基于MapReduce 和 HDFS 的 Lambda 系統(tǒng)有一個長達數(shù)小時的時間窗口，在這個窗口內(nèi)症虑，由于實時任務(wù)失敗而產(chǎn)生的不準確的結(jié)果會一直存在缩歪。Lambda 架構(gòu)需要在兩個不同的 API（applicationprogramming interface，應(yīng)用程序編程接口）中對同樣的業(yè)務(wù)邏輯進行兩次編程：一次為批量計算的系統(tǒng)谍憔，一次為流式計算的系統(tǒng)匪蝙。針對同一個業(yè)務(wù)問題產(chǎn)生了兩個代碼庫主籍，各有不同的漏洞。這種系統(tǒng)實際上非常難維護逛球。------摘自《Flink基礎(chǔ)教程》

難以維護只是Lambda架構(gòu)的一個局限千元，實際上在低延遲和高吞吐的流處理系統(tǒng)中維持良好的容錯是相當(dāng)困難的，為了得到有保障的準確狀態(tài)颤绕，人們又想出了一個鬼主意：將連續(xù)事件中的流數(shù)據(jù)分割成一系列微小的批量作業(yè)幸海，有點像用積分求面積的感覺，當(dāng)你分割的足夠小它就是一條線奥务。這就是傳說中的Spark Streaming所使用的方法物独。然而

在 Spark Streaming 中，處理數(shù)據(jù)的單位是一批而不是單條氯葬，而數(shù)據(jù)采集卻是逐條進行的挡篓，因此 Spark Streaming 系統(tǒng)需要設(shè)置間隔使得數(shù)據(jù)匯總到一定的量后再一并操作，這個間隔就是批處理間隔帚称。批處理間隔是 Spark Streaming 的核心概念和關(guān)鍵參數(shù)官研，它決定了 Spark Streaming 提交作業(yè)的頻率和數(shù)據(jù)處理的延遲，同時也影響著數(shù)據(jù)處理的吞吐量和性能世杀。 ------- 摘自IBM《Spark Streaming 新手指南》

于是乎阀参，又有人想出了一些鬼主意，綜合了之前所有大數(shù)據(jù)處理引擎的優(yōu)勢瞻坝，完善了各種缺點蛛壳，造就了一款能夠同時支持高吞吐和Exactly-Once語義（有點像事務(wù)隔離級別，剛好一次的意思所刀，就是很準確衙荐，剛好一次就完成。）的實時計算浮创，還能提供批量數(shù)據(jù)處理（在Flink看來忧吟，批處理就是對有限數(shù)據(jù)進行流處理）。
上述內(nèi)容基本解釋了What is Flink 的那張圖斩披，但還有些原理上的疑點溜族。
所以我要祭出 云邪 的另一張圖，大佬的圖整的就是好吖垦沉。

Flink 基石

從后往前說哈

Window（窗口）

窗口是一種機制煌抒，我記得TCP好像還有什么滑動窗口的概念，感興趣可以自行搜索厕倍。

時間窗口（以下摘自《Flink基礎(chǔ)教程》）

時間窗口是最簡單和最有用的一種窗口寡壮。它支持滾動和滑動。舉一個例子，假設(shè)要對傳感器輸出的數(shù)值求和况既。一分鐘滾動窗口收集最近一分鐘的數(shù)值这溅，并在一分鐘結(jié)束時輸出總和，如

image.png

一分鐘滑動窗口計算最近一分鐘的數(shù)值總和棒仍，但每半分鐘滑動一次并輸出結(jié)果悲靴，如

image.png

stream.timeWindow(Time.minutes(1))淫茵；
每半分鐘（即 30 秒）滑動一次的一分鐘滑動窗口如下所示。
lstream.timeWindow(Time.minutes(1), Time.seconds(30))

計數(shù)窗口

Flink支持的另一種常見窗口叫做計數(shù)窗口蹬跃。采用計數(shù)窗口時匙瘪，分組依據(jù)不再是時間戳，而是元素的數(shù)量蝶缀。例如在上圖中每半分鐘滑動一次的滑動窗口也可解釋為由4個元素組成的計數(shù)窗口丹喻，并且每兩個元素滑動一次。滾動和滑動的計數(shù)窗口分別定義如下：

stream.countWindow(4);
stream.countWindow(4, 2);
雖然計數(shù)窗口有用翁都，但其定義不如時間窗口嚴謹碍论，因此要謹慎使用。時間不會停止柄慰，而且時間窗口總會“關(guān)閉”鳍悠。但就計數(shù)窗口而言，假設(shè)其定義的元素數(shù)量為100坐搔，而某個key對應(yīng)的元素永遠達不到100個藏研，那么窗口就永遠不會關(guān)閉，該窗口占用的內(nèi)存也就浪費了薯蝎。（當(dāng)然這個是有解的）

會話窗口

Flink支持的另一種很有用的窗口是會話窗口遥倦。會話指的是活動階段，其前后都是非活動階段（做Web開發(fā)的應(yīng)該很容易理解這種概念，就是Session）袒哥。
在Flink中缩筛，會話窗口由超時時間設(shè)定，即希望等待多久才認為會話已經(jīng)結(jié)束堡称。舉例來說瞎抛，以下代碼表示，如果用戶處于非活動狀態(tài)長達5分鐘却紧，則認為會話結(jié)束桐臊。

stream.window(SessionWindows.withGap(Time.minutes(5)));

Time（時間）

在流處理中，主要有兩個時間概念晓殊。

• 事件時間断凶，即事件實際發(fā)生時間。

• 處理時間巫俺，即事件被處理的時間认烁。

  
  
  圖
  
  

  以《星球大戰(zhàn)》系列電影為例。首先上映的3部電影是該系列中的第4介汹、5却嗡、6 部（這是事件時間），它們的上映年份分別是 1977 年嘹承、1980 年和 1983 年（這是處理時間）窗价。之后按事件時間上映的第 1、2叹卷、3撼港、7 部，對應(yīng)的處理時間分別是 1999 年豪娜、2002 年餐胀、2005 年和 2015 年。由此可見瘤载，事件流的順序可能是亂的（盡管年份順序一般不會亂）否灾。
  通常還有第 3 個時間概念，即攝取時間鸣奔，也叫作進入時間墨技。它指的是事件進入流處理框架的時間。缺乏真實事件時間的數(shù)據(jù)會被流處理器附上時間戳挎狸，即流處理器第一次看到它的時間（這個操作由 source 函數(shù)完成扣汪，它是程序的第一個處理節(jié)點）。在現(xiàn)實世界中锨匆，許多因素（如連接暫時中斷崭别，不同原因?qū)е碌木W(wǎng)絡(luò)延遲冬筒，分布式系統(tǒng)中的時鐘不同步，數(shù)據(jù)速率陡增茅主，物理原因舞痰，或者運氣差）使得事件時間和處理時間存在偏差（即事件時間偏差）。事件時間順序和處理時間順序通常不一致诀姚，這意味著事件以亂序到達流處理器响牛。根據(jù)應(yīng)用程序的不同，兩個時間概念都很有用赫段。有些應(yīng)用程序（如一些預(yù)警應(yīng)用程序）需要盡可能快地得到結(jié)果呀打，即使有小的誤差也沒關(guān)系。它們不必等待遲到的事件糯笙，因此適合采用處理時間語義贬丛。其他一些應(yīng)用程序（如欺詐檢測系統(tǒng)或者賬單系統(tǒng)）則對準確性有要求：只有在時間窗口內(nèi)發(fā)生的事件才能被算進來。對于這些應(yīng)用程序來說炬丸，事件時間語義才是正確的
  選擇瘫寝。也有兩者都采用的情況蜒蕾，比如既要準確地計數(shù)稠炬，又要提供異常預(yù)警。

關(guān)于時間和窗口機制還有好幾個點的概念沒有抄過來咪啡，感興趣可自行搜索首启。

State（狀態(tài)）

流式計算分為無狀態(tài)和有狀態(tài)兩種情況。
其實舊的流處理系統(tǒng)并不支持有狀態(tài)撤摸，下圖說明了有狀態(tài)和無狀態(tài)的區(qū)別

圖

書上說在分布式系統(tǒng)中引入狀態(tài)時自然就引入了一致性問題毅桃，就是前文中提到的Exactly-Once 的概念。在流處理中准夷，一致性分為3個級別：

• at-most-once: 這其實是沒有正確性保障的委婉說法——故障發(fā)生后钥飞，計數(shù)結(jié)果可能丟失。
• at-least-once: 這表示計數(shù)結(jié)果可能大于正確值衫嵌，但絕不會小于正確值读宙。也就是說，技術(shù)程序在發(fā)生故障后可能多算楔绞，但是絕對不會少算结闸。
• exactly-once: 這表示系統(tǒng)發(fā)生故障后得到的計算結(jié)果與正確結(jié)果一致。

Checkpoint（檢查點）

Flink保證exactly-once語義是靠檢查點這一特性來實現(xiàn)的酒朵，它可以在出現(xiàn)故障時將系統(tǒng)重置回正確的狀態(tài)桦锄。

Flink 檢查點的核心作用是確保狀態(tài)正確，即使遇到程序中斷蔫耽，也要正確结耀。
Flink 檢查點算法的正式名稱是異步屏障快照（asynchronous barrier snapshotting）。該算法大致基于 Chandy-Lamport 分布式快照算法。
檢查點由 Flink 自動生成图甜，用來在故障發(fā)生時重新處理記錄香伴，從而修正狀態(tài)。

累了具则，我不想寫了即纲，咋這么多概念吖，好煩哦~

參考：
Apache Flink官網(wǎng)
《Flink基礎(chǔ)教程》
Spark Streaming 新手指南 IBM