一、概述
1、架構簡介
Apache Flink 是一個框架和分布式處理引擎，用於在無邊界和有邊界數據流上進行有狀態的計算。Flink 能在所有常見集群環境中運行，並能以內存速度和任意規模進行計算。Flink 集成了所有常見的集群資源管理器，例如 Hadoop YARN、 Apache Mesos 和 Kubernetes，但同時也可以作為獨立集群運行。特點如下：
1）無邊界：數據流有開始沒有結束，持續處理到來的數據（實時處理）
2）有邊界：數據的批處理（如等待一定量的數據到達后進行處理、存儲后處理）
3）有狀態：處理后一個數據時會用到之前處理過的數據的特點，該特點即為狀態，需要保存。任務的狀態始終保留在內存中，如果狀態大小超過可用內存，則會保存在能高效訪問的磁盤數據結構中。
2、Flink狀態特點
1）多種狀態基礎類型：多種狀態基礎類型，例如原子值（value），列表（list）以及映射（map）。
2）插件化的State Backend：State Backend 負責管理應用程序狀態，並在需要的時候進行 checkpoint。可以將狀態存在內存或者 RocksDB。RocksDB 是一種高效的嵌入式、持久化鍵值存儲引擎。Flink 也支持插件式的自定義 state backend 進行狀態存儲。
3）精確一次語義：checkpoint 和故障恢復算法保證了故障發生后應用狀態的一致性。
4）超大數據量狀態：利用其異步以及增量式的 checkpoint 算法，存儲數 TB 級別的應用狀態。
5）可彈性伸縮的應用：Flink 能夠通過在更多或更少的工作節點上對狀態進行重新分布，支持有狀態應用的分布式的橫向伸縮。
3、Flink時間語義
1）事件時間模式：使用事件時間語義的流處理應用根據事件本身自帶的時間戳進行結果的計算。因此，無論處理的是歷史記錄的事件還是實時的事件，事件時間模式的處理總能保證結果的准確性和一致性。如，用戶點擊某一頁面后一個小時內再次返回該頁面的次數，此時使用事件時間。
2）Watermark 支持：衡量事件時間進展，是一種平衡處理延時和完整性的靈活機制。如處理數據的順序（判斷是否等待更早的數據到來）可以根據水印判斷。
3）遲到數據處理：當以帶有 watermark 的事件時間模式處理數據流時，在計算完成之后仍會有相關數據到達。這樣的事件被稱為遲到事件。Flink 提供了多種處理遲到數據的選項，如將這些數據重定向到旁路輸出（side output）或者更新之前完成計算的結果。
4）處理時間模式：處理時間模式根據處理引擎的機器時鍾觸發計算，一般適用於有着嚴格的低延遲需求，並且能夠容忍近似結果的流處理應用。如處理11：00-12：00內的頁面點擊數。
4、分層API
根據抽象程度分層，提供了三種不同的 API。每一種 API 在簡潔性和表達力上有着不同的側重，並且針對不同的應用場景。
二、Flink架構
1、 進程組成
1）JobManager：它決定何時安排下一個任務（或任務組），對任務的完成或失敗采取動作，協調檢查點與故障恢復，等等。此過程包含三個不同的組件：
——ResourceManager：負責在集群中分配資源和配置文件，管理任務slots（資源調度單元）
——Dispatcher：提供了一個提交執行Flink任務的接口，還運行Flink WebUI以提供有關作業執行的信息。
——JobMaster：一個JobMaster負責管理一個單一的 JobGraph執行。Flink群集中可以同時運行多個作業，每個作業都有自己的JobMaster。
始終至少有一個JobManager。高可用性設置可能有多個JobManager，其中一個始終是領導者，而其他則 處於待機狀態
2）TaskManagers：執行數據流的任務，以及緩沖和交換數據流。TaskManager中資源調度的最小單位是任務slot。TaskManager中任務slot的數量指示並發處理任務的數量。請注意，多個operator可以在一個任務slot中執行
2、Tasks and Operator Chains
每個任務由一個線程執行。將operator鏈接到任務是一個有用的優化：它減少了線程到線程的切換和緩沖的開銷，並在降低延遲的同時提高了總體吞吐量。可以配置鏈接行為。
3、Task Slots and Resources
每個工作程序（TaskManager）是一個JVM進程，並且可以在單獨的線程中執行一個或多個子任務。為了控制TaskManager接受多少個任務，它具有所謂的任務slot（至少一個）。
每個任務slot代表TaskManager資源的固定子集。例如，具有三個slot的TaskManager會將其托管內存的1/3專用於每個插槽。分配資源意味着子任務不會與其他作業的子任務競爭托管內存，而是具有一定數量的保留托管內存。請注意，此處沒有發生CPU隔離。當前插槽僅將任務的托管內存分開。
通過調整任務slot的數量，用戶可以定義子任務如何相互隔離。每個TaskManager具有一個插槽，意味着每個任務組都在單獨的JVM中運行（例如，可以在單獨的容器中啟動）。具有多個插槽意味着更多子任務共享同一JVM。同一JVM中的任務共享TCP連接（通過多路復用）和心跳消息。它們還可以共享數據集和數據結構，從而減少每個任務的開銷。
默認情況下，Flink允許子任務共享插槽，即使它們是不同任務的子任務也是如此，只要它們來自同一job即可。
4、Flink執行的集群環境
1）Flink會話集群
——生命周期：在Flink會話群集中，客戶端連接到可以接受多個作業提交的、預先存在的、長時間運行的群集。即使所有作業完成后，群集（和JobManager）也將繼續運行，直到手動停止會話為止。因此，Flink會話群集的生存期不與任何Flink作業的生存期綁定。
——資源隔離：TaskManager slots由ResourceManager在作業提交時分配，並在作業完成后釋放。由於所有作業都共享同一個群集，因此在群集資源方面存在一些競爭，例如提交作業階段中的網絡帶寬。此共享設置的局限性在於，如果一個TaskManager崩潰，則所有在此TaskManager上運行任務的作業都將失敗；以類似的方式，如果JobManager發生一些致命錯誤，它將影響集群中正在運行的所有作業。
——其他注意事項：擁有預先存在的群集可以節省大量時間來申請資源和啟動TaskManager。在作業執行時間非常短且啟動時間過長會對端到端用戶體驗產生負面影響的情況下（如對短查詢進行交互式分析的情況），這很重要，在這種情況下，希望作業可以快速使用現有資源執行計算。
2）Flink工作集群
——生命周期：在Flink作業群集中，可用的集群管理器（例如YARN或Kubernetes）用於為每個提交的作業啟動一個群集，並且該群集僅可用於該作業。在這里，客戶端首先從集群管理器請求資源以啟動JobManager，然后將作業提交給在此過程中運行的Dispatcher。然后根據作業的資源需求延遲分配TaskManager。作業完成后，Flink作業群集將被拆除。
——資源隔離：JobManager中的致命錯誤僅影響在Flink Job Cluster中運行的一個作業。
——其他注意事項：由於ResourceManager必須應用並等待外部資源管理組件來啟動TaskManager進程並分配資源，因此Flink作業集群更適合於長期運行，具有高穩定性要求且不敏感的大型作業更長的啟動時間。
3）Flink Application集群
——群集生命周期：Flink應用程序群集是專用的Flink群集，它僅從一個Flink應用程序執行作業，並且該 main()方法在群集上而不是客戶端上運行。作業提交是一個單步過程：您無需先啟動Flink集群，然后再將作業提交到現有的集群會話；相反，您將應用程序邏輯和相關性打包到可執行的作業JAR中，集群入口點（ApplicationClusterEntryPoint）負責調用main()方法以提取JobGraph。例如，這使您可以像在Kubernetes上部署任何其他應用程序一樣部署Flink應用程序。因此，Flink應用程序集群的生存期與Flink應用程序的生存期綁定在一起。
——資源隔離：在Flink應用程序集群中，ResourceManager和Dispatcher的作用域為單個Flink應用程序，與Flink會話集群相比，它提供了更好的關注點分離。
三、故障恢復
1、可持續運行及其一致性
1）檢查點的一致性: 建立分布式應用服務狀態一致性檢查，當有故障產生時，應用服務會重啟后，再重新加載上一次成功備份的狀態檢查點信息。結合可重放的數據源，該特性可保證精確一次（exactly-once）的狀態一致性。
2）高效的檢查點: 如果一個應用要維護一個TB級的狀態信息，對此應用的狀態建立檢查點服務的資源開銷是很高的，為了減小因檢查點服務對應用的延遲性（SLAs服務等級協議）的影響，采用異步及增量的方式構建檢查點服務。
3）端到端的精確一次: Flink 為某些特定的存儲支持了事務型輸出的功能，及時在發生故障的情況下，也能夠保證精確一次的輸出。
4）集成多種集群管理服務:與多種集群管理服務緊密集成，如 Hadoop YARN, Mesos, 以及 Kubernetes。當集群中某個流程任務失敗后，一個新的流程服務會自動啟動並替代它繼續執行。
5）內置高可用服務:內置了為解決單點故障問題的高可用性服務模塊，此模塊是基於Apache ZooKeeper 技術實現的，是一種可靠的、交互式的、分布式協調服務組件。
2、升級、遷移、暫停、恢復應用服務
Savepoint 服務是為解決升級服務過程中記錄流應用狀態信息及其相關難題而產生的一種唯一的、強大的組件。一個 Savepoint，就是一個應用服務狀態的一致性快照，因此其與checkpoint組件的很相似，但是與checkpoint相比，Savepoint 需要手動觸發啟動，而且當流應用服務停止時，它並不會自動刪除。Savepoint 常被應用於啟動一個已含有狀態的流服務，並初始化其（備份時）狀態。Savepoint 有以下特點：
1）便於升級應用服務版本: Savepoint 常在應用版本升級時使用，當前應用的新版本更新升級時，可以根據之前版本程序記錄的 Savepoint 內的服務狀態信息來重啟服務。
2）方便集群服務移植: 通過使用 Savepoint，流服務應用可以自由的在不同集群中遷移部署。
3）方便Flink版本升級: 通過使用 Savepoint，可以使應用服務在升級Flink時，更加安全便捷。
4）增加應用並行服務的擴展性: Savepoint 也常在增加或減少應用服務集群的並行度時使用。
5）便於A/B測試及假設分析場景對比結果: 通過把同一應用在使用不同版本的應用程序，基於同一個 Savepoint 還原點啟動服務時，可以測試對比2個或多個版本程序的性能及服務質量。
6）暫停和恢復服務: 一個應用服務可以在新建一個 Savepoint 后再停止服務，以便於后面任何時間點再根據這個實時刷新的 Savepoint 還原點進行恢復服務。
7）歸檔服務: Savepoint 還提供還原點的歸檔服務，以便於用戶能夠指定時間點的 Savepoint 的服務數據進行重置應用服務的狀態，進行恢復服務。
3、監控和控制應用服務
Flink與許多常見的日志記錄和監視服務集成得很好，並提供了一個REST API來控制應用服務和查詢應用信息。具體表現如下：
1）Web UI方式: Flink提供了一個web UI來觀察、監視和調試正在運行的應用服務。並且還可以執行或取消組件或任務的執行。
2）日志集成服務:Flink實現了流行的slf4j日志接口，並與日志框架log4j或logback集成。
3）指標服務: Flink提供了一個復雜的度量系統來收集和報告系統和用戶定義的度量指標信息。度量信息可以導出到多個報表組件服務，包括 JMX, Ganglia, Graphite, Prometheus, StatsD, Datadog, 和 Slf4j.
4）標准的WEB REST API接口服務: Flink提供多種REST API接口，有提交新應用程序、獲取正在運行的應用程序的Savepoint服務信息、取消應用服務等接口。REST API還提供元數據信息和已采集的運行中或完成后的應用服務的指標信息。
4、checkpoint
異步及增量式快照。
1）State Backends：生成checkpoint之前保存狀態信息。由 Flink 管理的 keyed state 是一種分片的鍵/值存儲，每個 keyed state 的工作副本都保存在負責該鍵的 taskmanager 本地中。另外，Operator state 也保存在機器節點本地。Flink 定期獲取所有狀態的快照，並將這些快照復制到持久化的位置，例如分布式文件系統。Flink 管理的狀態存儲在 state backend 中。Flink 有兩種 state backend 的實現 ：
——基於 RocksDB 內嵌 key/value 存儲將其工作狀態保存在磁盤上的；
——另一種基於堆的 state backend，將其工作狀態保存在 Java 的堆內存中。這種基於堆的 state backend 有兩種類型：FsStateBackend，將其狀態快照持久化到分布式文件系統；MemoryStateBackend，它使用 JobManager 的堆保存狀態快照。
2）快照：快照包括指向每個數據源的指針（例如，到文件或 Kafka 分區的偏移量）以及每個作業的有狀態運算符的狀態副本，該狀態副本是處理了 sources 偏移位置之前所有的事件后而生成的狀態
3）barriers：當 checkpoint coordinator（job manager 的一部分）指示 task manager 開始 checkpoint 時，它會讓所有 sources 記錄它們的偏移量，並將編號的 checkpoint barriers 插入到它們的流中。Flink 的 state backends 利用寫時復制（copy-on-write）機制允許當異步生成舊版本的狀態快照時，能夠不受影響地繼續流處理。只有當快照被持久保存后，這些舊版本的狀態才會被當做垃圾回收。
4）批處理程序的容錯功能不使用檢查點。通過完全重播流來進行恢復；DataSet API中的狀態操作使用簡化的內存/核外數據結構；DataSet API引入了特殊的同步（基於超步）迭代
5、實時處理
1）window：窗口分為滾動窗口、滑動窗口、時間窗口。
2）水印：Flink的數據源在確認所有小於某個時間戳的消息都已輸出到Flink流處理系統后，會生成一個包含該時間戳的WaterMark，插入到消息流中輸出到Flink流處理系統中，Flink operator算子按照時間窗口緩存所有流入的消息。
3）水印產生：
——Punctuated：數據流中每一個遞增的EventTime都會產生一個Watermark。在實際的生產中Punctuated方式在TPS很高的場景下會產生大量的Watermark在一定程度上對下游算子造成壓力，所以只有在實時性要求非常高的場景才會選擇Punctuated的方式進行Watermark的生成。
——Periodic：周期性的（一定時間間隔或者達到一定的記錄條數）產生一個Watermark。在實際的生產中Periodic的方式必須結合時間和積累條數兩個維度繼續周期性產生Watermark，否則在極端情況下會有很大的延時。