Flink介紹：

很多人可能都是在 2015 年才聽到 Flink 這個詞，其實早在 2008 年，Flink 的前身已經是柏林理工大學一個研究性專案， 在 2014 被 Apache 孵化器所接受，然後迅速地成為了 ASF（Apache Software Foundation）的頂級專案之一。Flink 的最新版本目前已經更新到了 0.10.0 了，在很多人感慨 Spark 的快速發展的同時，或許我們也該為 Flink 的發展速度點個贊。

Flink 是一個針對流資料和批資料的分散式處理引擎。它主要是由 Java 程式碼實現。目前主要還是依靠開源社群的貢獻而發展。對 Flink 而言，其所要處理的主要場景就是流資料，批資料只是流資料的一個極限特例而已。再換句話說，Flink 會把所有任務當成流來處理，這也是其最大的特點。Flink 可以支援本地的快速迭代，以及一些環形的迭代任務。

Flink的特性：

   Flink是個分散式流處理開源框架：

       1： 即使資料來源是無序的或者晚到達的資料，也能保持結果準確性

       2：有狀態並且容錯，可以無縫的從失敗中恢復，並可以保持exactly-once

       3：大規模分散式

Flink可以確保僅一次語義狀態計算；Flink有狀態意味著，程式可以保持已經處理過的資料；

Flink支援流處理和視窗事件時間語義，Flink支援靈活的基於時間視窗,計數,或會話資料驅動的窗戶；

Flink容錯是輕量級和在同一時間允許系統維持高吞吐率和提供僅一次的一致性保證，Flink從失敗中恢復，零資料丟失；

Flink能夠高吞吐量和低延遲；

Flink儲存點提供版本控制機制,從而能夠更新應用程式或再加工歷史資料沒有丟失並在最小的停機時間。

Flink相關概念：

Parallel Dataflows

Flink中把整個流處理過程叫做Stream Dataflow,從資料來源提取資料的操作叫做Source Operator,中間的map(),聚合、統計等操作可以統稱為Tranformation Operators,最後結果資料的流出被稱為sink operators,具體可以見下方圖示：

Flink的程式內在是並行和分散式的，資料流可以被分割槽成stream partitions，operators被劃分為operator subtasks;這些subtasks在不同的機器或容器中分不同的執行緒獨立執行；operator subtasks的數量在具體的operator就是平行計算數，程式不同的operator階段可能有不同的並行數；如下圖所示，source operator的並行數為2，但最後的sink operator為1；

資料在兩個operator之間傳遞的時候有兩種模式：

一：one-to-one 模式：兩個operator用此模式傳遞的時候，會保持資料的分割槽數和資料的排序；

二：Redistributing 模式：這種模式會改變資料的分割槽數；每個一個operator subtask會根據選擇transformation把資料傳送到不同的目標subtasks,比如keyBy()會通過hashcode重新分割槽,broadcast()和rebalance()方法會隨機重新分割槽；

Tasks & Operator Chains

對於分散式計算，Flink封裝operator subtasks 鏈化為tasks;每個task由一個執行緒執行；把tasks鏈化有助於優化，它減少了開銷執行緒和執行緒之間的交接和緩衝；增加了吞吐量和減少延遲時間；鏈化的作用可以見下圖：在沒有鏈化之前，source operator和map operator 是兩個執行緒執行的兩個task，也就是說下面的dataflow 最初應該有7個subtasks;

但經過優化鏈化後，source和map合併為一個task，有一個執行緒執行，這樣優化可以減少source operator 和map operator兩個執行緒之間的交接和快取開銷；鏈化後只有5個task；對於鏈化這個優化，筆者也有疑問：是否是operator之間資料傳遞模式相同才能鏈化？

Distributed Execution

Flink runTime 包括兩種型別程序（類似於第一代hadoop架構）：

   master程序；也叫作JobManager,協調各個節點工作；master排程task，協調checkpoints和容災；機器群中至少有一個master，高可用機器中可以有多個master，但要保證一個是leader,其他是standby;

    work 型別程序；也叫taskManagers;具體執行tasks;

   client 雖然不是執行和程式的一部分，但是客戶端常被用作準備和傳送dataflow給master；

flink作業提交架構流程可見下圖：

Workers, Slots, Resources

  每一個TaskManager是個jvm,每個jvm中可以執行一個或者多個subtasks,jvm中taskSlot的數量決定了接受多少個task;每個tasksolt都有固定的資源，比如TaskManager有三個task solts,taskManager把平均把管理的記憶體分配到三個task slot中，這樣solt中的task不會跟其他的job競爭資源；預設上Flink許可subtasks去分享同一個是slots;但要保證這些subtask是不同的task，並且來自相同的Job；極端情況下，一個slot中執行整個job的task；solt分享有兩個重要的好處：

   1：flink 機群中可以用到的最高的平行計算數，就是taskSolt的數量

   2：可以容易的達到資源利用；

 solt 資源共享是可以在api中設定種控制；resource group機制可以設定哪些tasks 共享slots;

Configuring TaskManager processing slots

slot的數量通常設定是成正比的每個TaskManager可用CPU核的數量；一般建議,可用CPU核的數量正好是taskmanager.numberOfTaskSlots的數量，當開始Flink應用程式中,使用者可以提供slot的數量，可以在命令中加入-p(for paralleism)引數指定；另外也可以在API中設定；例如taskManager有三臺機器，並在flink-config.yaml中設定 taskmanager.numberOfTaskSlots:3(建議是cpu的核數)；這樣每臺機器有3個slot,機器中共有9個processing taskslots,見下圖所示：

當設定parallelism.default:2 或者啟動的時候指定-p引數-./bin/flink -p2 或者程式碼中設定env.setParallelism(2),那邊task分配如下圖所示：

當然也可以把某個operator的並行度另外設定，比如把sink的並行度設定為1，那多task分配就會如下圖：