一、flink概述

1.1 流處理技術(shù)語義

At most once（最多一次）：每條數(shù)據(jù)記錄最多被處理一次，潛臺詞也表明數(shù)據(jù)會有丟失（沒被處理掉）的可能。

10年積累的成都網(wǎng)站設(shè)計、成都網(wǎng)站制作經(jīng)驗，可以快速應(yīng)對客戶對網(wǎng)站的新想法和需求。提供各種問題對應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認識你，你也不認識我。但先網(wǎng)站制作后付款的網(wǎng)站建設(shè)流程，更有湖濱免費網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。

At least once（最少一次）：每條數(shù)據(jù)記錄至少被處理一次。這個比上一點強的地方在于這里至少保證數(shù)據(jù)不會丟，至少被處理過，唯一不足之處在于數(shù)據(jù)可能會被重復(fù)處理。

Exactly once（恰好一次）：每條數(shù)據(jù)記錄正好被處理一次。沒有數(shù)據(jù)丟失，也沒有重復(fù)的數(shù)據(jù)處理。這一點是3個語義里要求最高的。

1.2 flink是什么

? Flink主頁在其頂部展示了該項目的理念：“Apache Flink是為分布式、高性能、隨時可用以及準確的流處理應(yīng)用程序打造的開源流處理框架”。Apache Flink是一個框架和分布式處理引擎，用于對***和有界數(shù)據(jù)流進行有狀態(tài)計算。Flink被設(shè)計在所有常見的集群環(huán)境中運行，以內(nèi)存執(zhí)行速度和任意規(guī)模來執(zhí)行計算。

1.3 flink基本框架

? 批處理的特點是有界、持久、大量，批處理非常適合需要訪問全套記錄才能完成的計算工作，一般用于離線統(tǒng)計。流處理的特點是***、實時，流處理方式無需針對整個數(shù)據(jù)集執(zhí)行操作，而是對通過系統(tǒng)傳輸?shù)拿總€數(shù)據(jù)項執(zhí)行操作，一般用于實時統(tǒng)計。
在Spark生態(tài)體系中，對于批處理和流處理采用了不同的技術(shù)框架，批處理由SparkSQL實現(xiàn)，流處理由Spark Streaming實現(xiàn)，這也是大部分框架采用的策略，使用獨立的處理器實現(xiàn)批處理和流處理，而Flink可以同時實現(xiàn)批處理和流處理。
? Flink是如何同時實現(xiàn)批處理與流處理的呢？答案是，F(xiàn)link將批處理（即處理有限的靜態(tài)數(shù)據(jù)）視作一種特殊的流處理。
? Flink的核心計算架構(gòu)是下圖中的Flink Runtime執(zhí)行引擎，它是一個分布式系統(tǒng)，能夠接受數(shù)據(jù)流程序并在一臺或多臺機器上以容錯方式執(zhí)行。
? Flink Runtime執(zhí)行引擎可以作為YARN（Yet Another Resource Negotiator）的應(yīng)用程序在集群上運行，也可以在Mesos集群上運行，還可以在單機上運行（這對于調(diào)試Flink應(yīng)用程序來說非常有用）。

? 圖1.1 flink--基本架構(gòu)

? 上圖為Flink技術(shù)棧的核心組成部分，值得一提的是，F(xiàn)link分別提供了面向流式處理的接口（DataStream API）和面向批處理的接口（DataSet API）。因此，F(xiàn)link既可以完成流處理，也可以完成批處理。Flink支持的拓展庫涉及機器學(xué)習(xí)（FlinkML）、復(fù)雜事件處理（CEP）、以及圖計算（Gelly），還有分別針對流處理和批處理的Table API。
? 能被Flink Runtime執(zhí)行引擎接受的程序很強大，但是這樣的程序有著冗長的代碼，編寫起來也很費力，基于這個原因，F(xiàn)link提供了封裝在Runtime執(zhí)行引擎之上的API，以幫助用戶方便地生成流式計算程序。Flink 提供了用于流處理的DataStream API和用于批處理的DataSet API。值得注意的是，盡管Flink Runtime執(zhí)行引擎是基于流處理的，但是DataSet API先于DataStream API被開發(fā)出來，這是因為工業(yè)界對無限流處理的需求在Flink誕生之初并不大。
? DataStream API可以流暢地分析無限數(shù)據(jù)流，并且可以用Java或者Scala來實現(xiàn)。開發(fā)人員需要基于一個叫DataStream的數(shù)據(jù)結(jié)構(gòu)來開發(fā)，這個數(shù)據(jù)結(jié)構(gòu)用于表示永不停止的分布式數(shù)據(jù)流。
? Flink的分布式特點體現(xiàn)在它能夠在成百上千臺機器上運行，它將大型的計算任務(wù)分成許多小的部分，每個機器執(zhí)行一部分。Flink能夠自動地確保發(fā)生機器故障或者其他錯誤時計算能夠持續(xù)進行，或者在修復(fù)bug或進行版本升級后有計劃地再執(zhí)行一次。這種能力使得開發(fā)人員不需要擔(dān)心運行失敗。Flink本質(zhì)上使用容錯性數(shù)據(jù)流，這使得開發(fā)人員可以分析持續(xù)生成且永遠不結(jié)束的數(shù)據(jù)（即流處理）。

1.4 無窮數(shù)據(jù)流和有限數(shù)據(jù)流

無窮數(shù)據(jù)集：無窮的持續(xù)集合的數(shù)據(jù)集合
有限數(shù)據(jù)集：有限不會改變的數(shù)據(jù)集合

常見的無窮數(shù)據(jù)集合有：
用戶與客戶端的實時交互數(shù)據(jù)
應(yīng)用實時產(chǎn)生的日志
金融市場的實時交易記錄

1.5 Flink和storm對比

1.6 flink特性

1、高吞吐和低延遲性

2、支持 Event Time 和亂序事件
Flink 支持了流處理和 Event Time 語義的窗口機制。
Event time 使得計算亂序到達的事件或可能延遲到達的事件更加簡單。

3、狀態(tài)計算的 exactly-once 語義
故障狀態(tài)下，需要重啟計算任務(wù)，這時候需要避免已經(jīng)處理過的數(shù)據(jù)的重復(fù)處理。
流程序可以在計算過程中維護自定義狀態(tài)。
Flink 的 checkpointing 機制保證了即時在故障發(fā)生下也能保障狀態(tài)的 exactly once 語義。

4、高度靈活的流式窗口
Flink 支持在時間窗口，統(tǒng)計窗口，session 窗口，以及數(shù)據(jù)驅(qū)動的窗口
窗口可以通過靈活的觸發(fā)條件來定制，以支持復(fù)雜的流計算模式。

5、帶反壓的連續(xù)流模型
數(shù)據(jù)流應(yīng)用執(zhí)行的是不間斷的（常駐）operators。
Flink streaming 在運行時有著天然的流控：慢的數(shù)據(jù) sink 節(jié)點會反壓（backpressure）快的數(shù)據(jù)源（sources）。

6、容錯性
Flink 的容錯機制是基于 Chandy-Lamport distributed snapshots 來實現(xiàn)的。
這種機制是非常輕量級的，允許系統(tǒng)擁有高吞吐率的同時還能提供強一致性的保障。

7、Batch 和 Streaming 一個系統(tǒng)流處理和批處理共用一個引擎
Flink 為流處理和批處理應(yīng)用公用一個通用的引擎。批處理應(yīng)用可以以一種特殊的流處理應(yīng)用高效地運行。

8、內(nèi)存管理
Flink 在 JVM 中實現(xiàn)了自己的內(nèi)存管理。
應(yīng)用可以超出主內(nèi)存的大小限制，并且承受更少的垃圾收集的開銷。

9、迭代和增量迭代
Flink 具有迭代計算的專門支持（比如在機器學(xué)習(xí)和圖計算中）。
增量迭代可以利用依賴計算來更快地收斂。

10、程序調(diào)優(yōu)
批處理程序會自動地優(yōu)化一些場景，比如避免一些昂貴的操作（如 shuffles 和 sorts），還有緩存一些中間數(shù)據(jù)。

1.7 flink應(yīng)用場景

? Apache Flink 功能強大，支持開發(fā)和運行多種不同種類的應(yīng)用程序。它的主要特性包括：批流一體化、精密的狀態(tài)管理、事件時間支持以及精確一次的狀態(tài)一致性保障等。Flink 不僅可以運行在包括 YARN、 Mesos、Kubernetes 在內(nèi)的多種資源管理框架上，還支持在裸機集群上獨立部署。在啟用高可用選項的情況下，它不存在單點失效問題。事實證明，F(xiàn)link 已經(jīng)可以擴展到數(shù)千核心，其狀態(tài)可以達到 TB 級別，且仍能保持高吞吐、低延遲的特性。世界各地有很多要求嚴苛的流處理應(yīng)用都運行在 Flink 之上。

1.7.1 事件驅(qū)動型應(yīng)用

反欺詐
異常檢測
基于規(guī)則的報警
業(yè)務(wù)流程監(jiān)控
Web應(yīng)用

1.7.2 數(shù)據(jù)分析應(yīng)用

電信網(wǎng)路質(zhì)量監(jiān)控
移動應(yīng)用中的產(chǎn)品更新及實驗評估分析
大規(guī)模圖分析

1.7.3 數(shù)據(jù)管道應(yīng)用

電子商務(wù)中的實時查詢索引構(gòu)建
電子商務(wù)中的持續(xù)ETL

二、Flink基本架構(gòu)

2.1 flink中的角色

Flink運行時包含了兩種類型的處理器：
JobManager處理器：也稱之為Master，用于協(xié)調(diào)分布式執(zhí)行，它們用來調(diào)度task，協(xié)調(diào)檢查點，協(xié)調(diào)失敗時恢復(fù)等。Flink運行時至少存在一個master處理器，如果配置高可用模式則會存在多個master處理器，它們其中有一個是leader，而其他的都是standby。

TaskManager處理器：也稱之為Worker，用于執(zhí)行一個dataflow的task(或者特殊的subtask)、數(shù)據(jù)緩沖和data stream的交換，F(xiàn)link運行時至少會存在一個worker處理器。

? 圖2.1 flink--JobManager與TaskManager

Master和Worker處理器可以直接在物理機上啟動，或者通過像YARN這樣的資源調(diào)度框架。Worker連接到Master，告知自身的可用性進而獲得任務(wù)分配。

2.2 ***數(shù)據(jù)流與有界數(shù)據(jù)流

***數(shù)據(jù)流：
***數(shù)據(jù)流有一個開始但是沒有結(jié)束，它們不會在生成時終止并提供數(shù)據(jù)，必須連續(xù)處理***流，也就是說必須在獲取后立即處理event。對于***數(shù)據(jù)流我們無法等待所有數(shù)據(jù)都到達，因為輸入是***的，并且在任何時間點都不會完成。處理***數(shù)據(jù)通常要求以特定順序（例如事件發(fā)生的順序）獲取event，以便能夠推斷結(jié)果完整性。

有界數(shù)據(jù)流：
有界數(shù)據(jù)流有明確定義的開始和結(jié)束，可以在執(zhí)行任何計算之前通過獲取所有數(shù)據(jù)來處理有界流，處理有界流不需要有序獲取，因為可以始終對有界數(shù)據(jù)集進行排序，有界流的處理也稱為批處理。

? Apache Flink是一個面向分布式數(shù)據(jù)流處理和批量數(shù)據(jù)處理的開源計算平臺，它能夠基于同一個Flink運行時(Flink Runtime)，提供支持流處理和批處理兩種類型應(yīng)用的功能?，F(xiàn)有的開源計算方案，會把流處理和批處理作為兩種不同的應(yīng)用類型，因為它們要實現(xiàn)的目標是完全不相同的：流處理一般需要支持低延遲、Exactly-once保證，而批處理需要支持高吞吐、高效處理，所以在實現(xiàn)的時候通常是分別給出兩套實現(xiàn)方法，或者通過一個獨立的開源框架來實現(xiàn)其中每一種處理方案。例如，實現(xiàn)批處理的開源方案有MapReduce、Tez、Crunch、Spark，實現(xiàn)流處理的開源方案有Samza、Storm。
Flink在實現(xiàn)流處理和批處理時，與傳統(tǒng)的一些方案完全不同，它從另一個視角看待流處理和批處理，將二者統(tǒng)一起來：Flink是完全支持流處理，也就是說作為流處理看待時輸入數(shù)據(jù)流是***的；批處理被作為一種特殊的流處理，只是它的輸入數(shù)據(jù)流被定義為有界的?；谕粋€Flink運行時(Flink Runtime)，分別提供了流處理和批處理API，而這兩種API也是實現(xiàn)上層面向流處理、批處理類型應(yīng)用框架的基礎(chǔ)。

2.3 flink數(shù)據(jù)流編程接口抽象

Flink提供了不同級別的抽象，以開發(fā)流或批處理作業(yè)，如下圖所示：

? 圖2.3 flink編程接口抽象
? 最底層級的抽象僅僅提供了有狀態(tài)流，它將通過過程函數(shù)（Process Function）被嵌入到DataStream API中。底層過程函數(shù)（Process Function） 與 DataStream API 相集成，使其可以對某些特定的操作進行底層的抽象，它允許用戶可以自由地處理來自一個或多個數(shù)據(jù)流的事件，并使用一致的容錯的狀態(tài)。除此之外，用戶可以注冊事件時間并處理時間回調(diào)，從而使程序可以處理復(fù)雜的計算。
? 實際上，大多數(shù)應(yīng)用并不需要上述的底層抽象，而是針對核心API（Core APIs） 進行編程，比如DataStream API（有界或***流數(shù)據(jù)）以及DataSet API（有界數(shù)據(jù)集）。這些API為數(shù)據(jù)處理提供了通用的構(gòu)建模塊，比如由用戶定義的多種形式的轉(zhuǎn)換（transformations），連接（joins），聚合（aggregations），窗口操作（windows）等等。DataSet API 為有界數(shù)據(jù)集提供了額外的支持，例如循環(huán)與迭代。這些API處理的數(shù)據(jù)類型以類（classes）的形式由各自的編程語言所表示。
? Table API 是以表為中心的聲明式編程，其中表可能會動態(tài)變化（在表達流數(shù)據(jù)時）。Table API遵循（擴展的）關(guān)系模型：表有二維數(shù)據(jù)結(jié)構(gòu)（schema）（類似于關(guān)系數(shù)據(jù)庫中的表），同時API提供可比較的操作，例如select、project、join、group-by、aggregate等。Table API程序聲明式地定義了什么邏輯操作應(yīng)該執(zhí)行，而不是準確地確定這些操作代碼的看上去如何 。 盡管Table API可以通過多種類型的用戶自定義函數(shù)（UDF）進行擴展，其仍不如核心API更具表達能力，但是使用起來卻更加簡潔（代碼量更少）。除此之外，Table API程序在執(zhí)行之前會經(jīng)過內(nèi)置優(yōu)化器進行優(yōu)化。
你可以在表與 DataStream/DataSet 之間無縫切換，以允許程序?qū)?Table API 與 DataStream 以及 DataSet 混合使用。
? Flink提供的最高層級的抽象是 SQL 。這一層抽象在語法與表達能力上與 Table API 類似，但是是以SQL查詢表達式的形式表現(xiàn)程序。SQL抽象與Table API交互密切，同時SQL查詢可以直接在Table API定義的表上執(zhí)行。

三、flink運行架構(gòu)

3.1 提交任務(wù)到y(tǒng)arn的流程

flink在生產(chǎn)中，一般是使用yarn作為資源調(diào)度平臺，比較少使用standalone的方式進行資源調(diào)度。所以這里以yarn為例，說明flink提交任務(wù)到y(tǒng)arn的流程。

? 圖3.1 flink--提交任務(wù)到y(tǒng)arn流程
? Flink任務(wù)提交后，Client向HDFS上傳Flink的Jar包和配置，之后向Yarn ResourceManager提交任務(wù)，ResourceManager分配Container資源并通知對應(yīng)的NodeManager啟動ApplicationMaster，ApplicationMaster啟動后加載Flink的Jar包和配置構(gòu)建環(huán)境，然后啟動JobManager，之后ApplicationMaster向ResourceManager申請資源啟動TaskManager，ResourceManager分配Container資源后，由ApplicationMaster通知資源所在節(jié)點的NodeManager啟動TaskManager，NodeManager加載Flink的Jar包和配置構(gòu)建環(huán)境并啟動TaskManager，TaskManager啟動后向JobManager發(fā)送心跳包，并等待JobManager向其分配任務(wù)。

3.2 任務(wù)調(diào)度組件

? 圖3.2 flink--任務(wù)調(diào)度
1、 Program Code：我們編寫的 Flink 應(yīng)用程序代碼

2、 Job Client：Job Client 不是 Flink 程序執(zhí)行的內(nèi)部部分，但它是任務(wù)執(zhí)行的起點。 Job Client 負責(zé)接受用戶的程序代碼，然后創(chuàng)建數(shù)據(jù)流，將數(shù)據(jù)流提交給 Job Manager 以便進一步執(zhí)行。 執(zhí)行完成后，Job Client 將結(jié)果返回給用戶

3、 JobManager：主進程（也稱為作業(yè)管理器）協(xié)調(diào)和管理程序的執(zhí)行。 它的主要職責(zé)包括安排任務(wù)，管理checkpoint ，故障恢復(fù)等。機器集群中至少要有一個 master，master 負責(zé)調(diào)度 task，協(xié)調(diào) checkpoints 和容災(zāi)，高可用設(shè)置的話可以有多個 master，但要保證一個是active, 其他是 standby; Job Manager 包含 Actor system(通信系統(tǒng))、Scheduler（調(diào)度）、Check pointing 三個重要的組件

4、 Task Manager：從 Job Manager 處接收需要部署的 Task。Task Manager 是在 JVM 中的一個或多個線程中執(zhí)行任務(wù)的工作節(jié)點。 任務(wù)執(zhí)行的并行性由每個 Task Manager 上可用的任務(wù)槽（task slot）決定。 每個任務(wù)代表分配給任務(wù)槽的一組資源。 例如，如果 Task Manager 有四個插槽，那么它將為每個插槽分配 25％ 的內(nèi)存。 可以在任務(wù)槽中運行一個或多個線程。 同一插槽中的線程共享相同的 JVM。 同一 JVM 中的任務(wù)共享 TCP 連接和心跳消息。Task Manager 的一個 Slot 代表一個可用線程，該線程具有固定的內(nèi)存，注意 Slot 只對內(nèi)存隔離，沒有對 CPU 隔離。默認情況下，F(xiàn)link 允許子任務(wù)共享 Slot，即使它們是不同 task 的 subtask，只要它們來自相同的 job。這種共享可以有更好的資源利用率。

3.3 TaskManager和slots原理

? 每一個worker(TaskManager)是一個JVM進程，它可能會在獨立的線程上執(zhí)行一個或多個subtask。為了控制一個worker能接收多少個task，worker通過task slot來進行控制（一個worker至少有一個task slot）。
? 每個task slot表示TaskManager擁有資源的一個固定大小的子集。假如一個TaskManager有三個slot，那么它會將其管理的內(nèi)存平均分成三份給各個slot。資源slot化意味著一個subtask將不需要跟來自其他job的subtask競爭被管理的內(nèi)存，取而代之的是它將擁有一定數(shù)量的內(nèi)存儲備。需要注意的是，這里不會涉及到CPU的隔離，slot目前僅僅用來隔離task的受管理的內(nèi)存。
? 通過調(diào)整task slot的數(shù)量，允許用戶定義subtask之間如何互相隔離。如果一個TaskManager一個slot，那將意味著每個task group運行在獨立的JVM中（該JVM可能是通過一個特定的容器啟動的），而一個TaskManager多個slot意味著更多的subtask可以共享同一個JVM。而在同一個JVM進程中的task將共享TCP連接（基于多路復(fù)用）和心跳消息。它們也可能共享數(shù)據(jù)集和數(shù)據(jù)結(jié)構(gòu)，因此這減少了每個task的負載。

? 圖3.3 taskManager和slots
? Task Slot是靜態(tài)的概念，是指TaskManager具有的并發(fā)執(zhí)行能力，可以通過參數(shù)taskmanager.numberOfTaskSlots進行配置，而并行度parallelism是動態(tài)概念，即TaskManager運行程序時實際使用的并發(fā)能力，可以通過參數(shù)parallelism.default進行配置。
? 也就是說，假設(shè)一共有3個TaskManager，每一個TaskManager中的分配3個TaskSlot，也就是每個TaskManager可以接收3個task，一共9個TaskSlot，如果我們設(shè)置parallelism.default=1，即運行程序默認的并行度為1，9個TaskSlot只用了1個，有8個空閑，因此，設(shè)置合適的并行度才能提高效率。實際上slots限制的限制了該taskmanager在整個集群中能夠并行運行task的數(shù)目，而parallelism.default則是限制單個job能夠使用slot的數(shù)量，但是允許多個job同時運行，所以實際上是對單個job的并發(fā)限制。

3.4 程序與數(shù)據(jù)流

? Flink程序的基礎(chǔ)構(gòu)建模塊是 流（streams） 與 轉(zhuǎn)換（transformations）（需要注意的是，F(xiàn)link的DataSet API所使用的DataSets其內(nèi)部也是stream）。一個stream可以看成一個中間結(jié)果，而一個transformations是以一個或多個stream作為輸入的某種operation，該operation利用這些stream進行計算從而產(chǎn)生一個或多個result stream。
? 在運行時，F(xiàn)link上運行的程序會被映射成streaming dataflows，它包含了streams和transformations operators。每一個dataflow以一個或多個sources開始以一個或多個sinks結(jié)束。dataflow類似于任意的有向無環(huán)圖（DAG），當(dāng)然特定形式的環(huán)可以通過iteration構(gòu)建。在大部分情況下，程序中的transformations跟dataflow中的operator是一一對應(yīng)的關(guān)系，但有時候，一個transformation可能對應(yīng)多個operator。

? 圖3.4 程序與數(shù)據(jù)流

3.5 并行數(shù)據(jù)流（operator并行）

? Flink程序的執(zhí)行具有并行、分布式的特性。在執(zhí)行過程中，一個 stream 包含一個或多個 stream partition ，而每一個 operator 包含一個或多個 operator subtask，這些operator subtasks在不同的線程、不同的物理機或不同的容器中彼此互不依賴得執(zhí)行。
? 一個特定operator的subtask的個數(shù)被稱之為其parallelism(并行度)。一個stream的并行度總是等同于其producing operator的并行度。一個程序中，不同的operator可能具有不同的并行度。

? 圖3.5 并行數(shù)據(jù)流
? Stream在operator之間傳輸數(shù)據(jù)的形式可以是one-to-one(forwarding)的模式也可以是redistributing的模式，具體是哪一種形式，取決于operator的種類。
? One-to-one：stream(比如在source和map operator之間)維護著分區(qū)以及元素的順序。那意味著map operator的subtask看到的元素的個數(shù)以及順序跟source operator的subtask生產(chǎn)的元素的個數(shù)、順序相同，map、fliter、flatMap等算子都是one-to-one的對應(yīng)關(guān)系。不會改變分區(qū)的情況下，才能是該模式。
? Redistributing：stream(map()跟keyBy/window之間或者keyBy/window跟sink之間)的分區(qū)會發(fā)生改變。每一個operator subtask依據(jù)所選擇的transformation發(fā)送數(shù)據(jù)到不同的目標subtask。例如，keyBy() 基于hashCode重分區(qū)、broadcast和rebalance會隨機重新分區(qū)，這些算子都會引起redistribute過程，而redistribute過程就類似于Spark中的shuffle過程。

3.6 task和operator chains

? 出于分布式執(zhí)行的目的，F(xiàn)link將同一類operator的subtask鏈接在一起形成task，每個task在一個線程中執(zhí)行。將operators鏈接成task是非常有效的優(yōu)化：它能減少線程之間的切換和基于緩存區(qū)的數(shù)據(jù)交換，在減少時延的同時提升吞吐量。鏈接的行為可以在編程API中進行指定。這個task鏈的方式其實和spark中的劃分stage，然后構(gòu)建task鏈的方式是一模一樣的，如果理解不了，可以看之前spark的文章。
下面這幅圖，展示了5個subtask以5個并行的線程來執(zhí)行：

? 圖3.6 flink--operator chains
看到上面的圖，因為keyBy這個算子是會導(dǎo)致重分區(qū)的，那么以這里為界限，劃分stage，然后前面的 source 和map可以獨立構(gòu)建task鏈，后面的keyBy、window另外構(gòu)建task鏈。加上最后統(tǒng)一的sink操作，其實是5個task鏈，然后根據(jù)先后順序運行。這個機制和spark的一樣。