一、流處理

無界數(shù)據(jù)流

顧名思義，無界數(shù)據(jù)流就是指有始無終的數(shù)據(jù)，數(shù)據(jù)一旦開始生成就會持續(xù)不斷的產(chǎn)生新的數(shù)據(jù)，即數(shù)據(jù)沒有時間邊界。無界數(shù)據(jù)流需要持續(xù)不斷地處理。

有界數(shù)據(jù)流

相對而言，有界數(shù)據(jù)流就是指輸入的數(shù)據(jù)有始有終。例如數(shù)據(jù)可能是一分鐘或者一天的交易數(shù)據(jù)等等。處理這種有界數(shù)據(jù)流的方式也被稱之為批處理。

二、Flink程序三大邏輯結(jié)構(gòu)

• source：數(shù)據(jù)源，flink 在流處理和批處理上的 source 大概有 4 類：本地集合、文件、socket，自定義的 source（比如：kafka等）。
• transformations：各種類型的裝換操作（比如：map, flatmap, reduce等）。
• sink：數(shù)據(jù)的匯或者是接收器，也有4中類型：文件、socket、打印出來、自定義sink（比如：kafka等）

通常，程序代碼中的 transformation 和 dataflow 中的算子（operator）之間是一一對應(yīng)的。但有時也會出現(xiàn)一個 transformation 包含多個算子的情況，如上圖所示。

并行 Dataflows

Flink 程序本質(zhì)上是分布式并行程序。在程序執(zhí)行期間，一個流有一個或多個流分區(qū)（Stream Partition），每個算子有一個或多個算子子任務(wù)（Operator Subtask）。每個子任務(wù)彼此獨立，并在不同的線程中運行，或在不同的計算機或容器中運行。

算子子任務(wù)數(shù)就是其對應(yīng)算子的并行度。在同一程序中，不同算子也可能具有不同的并行度。

Flink 算子之間可以通過一對一（直傳）模式或重新分發(fā)模式傳輸數(shù)據(jù)：

一對一(One-to-one)模式（例如上圖中的 Source 和 map() 算子之間）可以保留元素的分區(qū)和順序信息。這意味著 map() 算子的 subtask[1] 輸入的數(shù)據(jù)以及其順序與 Source 算子的 subtask[1] 輸出的數(shù)據(jù)和順序完全相同，即同一分區(qū)的數(shù)據(jù)只會進入到下游算子的同一分區(qū)。

重新分發(fā)(Redistribution)模式（例如上圖中的 map() 和 keyBy/window 之間，以及 keyBy/window 和 Sink 之間）則會更改數(shù)據(jù)所在的流分區(qū)。當(dāng)你在程序中選擇使用不同的 transformation，每個算子子任務(wù)也會根據(jù)不同的 transformation 將數(shù)據(jù)發(fā)送到不同的目標(biāo)子任務(wù)。例如以下這幾種 transformation 和其對應(yīng)分發(fā)數(shù)據(jù)的模式：keyBy()（通過散列鍵重新分區(qū)）、broadcast()（廣播）或 rebalance()（隨機重新分發(fā)）。在重新分發(fā)數(shù)據(jù)的過程中，元素只有在每對輸出和輸入子任務(wù)之間才能保留其之間的順序信息（例如，keyBy/window 的 subtask[2] 接收到的 map() 的 subtask[1] 中的元素都是有序的）。因此，上圖所示的 keyBy/window 和 Sink 算子之間數(shù)據(jù)的重新分發(fā)時，不同鍵（key）的聚合結(jié)果到達 Sink 的順序是不確定的。

三、窗口

窗口是無限流處理中的一個概念，它將流拆分成一個個的“桶”，我們再基于這些桶的數(shù)據(jù)做計算。

流處理中的聚合操作（counts,sums等等）不同于批處理，因為數(shù)據(jù)流是無限，無法在其上應(yīng)用聚合，所以通過限定窗口(window)的范圍，來進行流的聚合操作。例如：5分鐘的數(shù)據(jù)計數(shù)，或者計算100個元素的總和等等。

窗口可以由時間驅(qū)動 (every 30 seconds) 或者數(shù)據(jù)驅(qū)動(every 100 elements)。如：滾動窗口tumbling windows（無疊加），滑動窗口sliding windows（有疊加），以及會話窗口session windows(被無事件活動的間隔隔開)

四、檢查點

基于檢查點的容錯是Flink的關(guān)鍵特征之一，正式基于這樣的設(shè)計，F(xiàn)link才可以統(tǒng)一批流處理。Flink 容錯機制的核心就是持續(xù)創(chuàng)建分布式數(shù)據(jù)流及其狀態(tài)的一致快照。這些快照在系統(tǒng)遇到故障時，充當(dāng)可以回退的一致性檢查點（checkpoint）

分布式快照引入了數(shù)據(jù)柵欄（barrier）的概念，barrier 被插入到數(shù)據(jù)流中，作為數(shù)據(jù)流的一部分和數(shù)據(jù)一起向下流動。Barrier 不會干擾正常數(shù)據(jù)，數(shù)據(jù)流嚴(yán)格有序。一個 barrier 把數(shù)據(jù)流分割成兩部分：一部分進入到當(dāng)前快照，另一部分進入下一個快照。每一個 barrier 都帶有快照 ID，并且 barrier 之前的數(shù)據(jù)都進入了此快照。Barrier 不會干擾數(shù)據(jù)流處理，所以非常輕量。多個不同快照的多個 barrier 會在流中同時出現(xiàn)，即多個快照可能同時創(chuàng)建。

Barrier 在數(shù)據(jù)源端插入，當(dāng) snapshot n 的 barrier 插入后，系統(tǒng)會記錄當(dāng)前 snapshot 位置值 n (用Sn表示)。例如，在 Apache Kafka 中，這個變量表示某個分區(qū)中最后一條數(shù)據(jù)的偏移量。這個位置值 Sn 會被發(fā)送到一個稱為 checkpoint coordinator 的模塊。

然后 barrier 繼續(xù)往下流動，當(dāng)一個 operator 從其輸入流接收到所有標(biāo)識 snapshot n 的 barrier 時，它會向其所有輸出流插入一個標(biāo)識 snapshot n 的 barrier。當(dāng) sink operator （DAG 流的終點）從其輸入流接收到所有 barrier n 時，它向 the checkpoint coordinator 確認 snapshot n 已完成。當(dāng)所有 sink 都確認了這個快照，快照就被標(biāo)識為完成。

接收超過一個輸入流的 operator 需要基于 barrier 對齊（align）輸入。參見上圖：

• operator 只要一接收到某個輸入流的 barrier n，它就不能繼續(xù)處理此數(shù)據(jù)流后續(xù)的數(shù)據(jù)，直到 operator 接收到其余流的 barrier n。否則會將屬于 snapshot n 的數(shù)據(jù)和 snapshot n+1的搞混
• barrier n 所屬的數(shù)據(jù)流先不處理，從這些數(shù)據(jù)流中接收到的數(shù)據(jù)被放入接收緩存里（input buffer）
• 當(dāng)從最后一個流中提取到 barrier n 時，operator 會發(fā)射出所有等待向后發(fā)送的數(shù)據(jù)，然后發(fā)射snapshot n 所屬的 barrier
  *經(jīng)過以上步驟，operator 恢復(fù)所有輸入流數(shù)據(jù)的處理，優(yōu)先處理輸入緩存中的數(shù)據(jù)

五、狀態(tài)

只有在每一個單獨的事件上進行轉(zhuǎn)換操作的應(yīng)用才不需要狀態(tài)，換言之，每一個具有一定復(fù)雜度的流處理應(yīng)用都是有狀態(tài)的。任何運行基本業(yè)務(wù)邏輯的流處理應(yīng)用都需要在一定時間內(nèi)存儲所接收的事件或中間結(jié)果，以供后續(xù)的某個時間點（例如收到下一個事件或者經(jīng)過一段特定時間）進行訪問并進行后續(xù)處理。狀態(tài)有兩種形式：

• 用戶自定義狀態(tài)：由 算子直接創(chuàng)建或者修改的狀態(tài)。

• 系統(tǒng)狀態(tài)：這種狀態(tài)是指作為算子計算中一部分緩存數(shù)據(jù)。