Flink介紹-《Fink原理、實戰與性能優化》讀書筆記
1.1 Apache Flink是什么？
在當代數據量激增的時代，各種業務場景都有大量的業務數據產生，對於這些不斷產生的數據應該如何進行有效的處理，成為當下大多數公司所面臨的問題。隨着雅虎對hadoop的開源，越來越多的大數據處理技術開始涌入人們的視線，例如目前比較流行的大數據處理引擎Apache Spark,基本上已經取代了MapReduce成為當前大數據處理的標准。但是隨着數據的不斷增長，新技術的不斷發展，人們逐漸意識到對實時數據處理的重要性。相對於傳統的數據處理模式，流式數據處理有着更高的處理效率和成本控制能力。Flink 就是近年來在開源社區不斷發展的技術中的能夠同時支持高吞吐、低延遲、高性能的分布式處理框架
1.2數據架構的演變
圖1-1 傳統的數據結構
如圖1-1所示，傳統的單體數據架構最大的特點便是 集中式數據存儲，大多數將架構分為計算層和存儲層。
單體架構的初期效率很高，但是隨着時間的推移，業務越來越多，系統逐漸變得很大，越來越難以維護和升級，數據庫是唯一的准確數據源，每個應用都需要訪問數據庫來獲取對應的數據，如果數據庫發生改變或者出現問題，則將對整個業務系統產生影響。
后來隨着微服務架構的出現，企業開始采用微服務作為企業業務系統的架構體系。微服務架構的核心思想是：一個應用是由多個小的、相互獨立的微服務組成，這些服務運行在自己的進程中，開發和發布都沒有依賴。不同的服務能依據不同的業務需求，構建的不同的技術架構之上，能夠聚焦在有限的業務功能。 如圖1-2
圖1-2 微服務架構
起初數據倉庫主要還是構建在關系型數據庫之上。例如Oracle、Mysql等數據庫，但是隨着企業數據量的增長，關系型數據庫已經無法支撐大規模數據集的存儲和分析，因為越來越多的企業開始選擇基於Hadoop構建企業級大數據平台。同時眾多的Sql_on_hadhoop上構建不同類型的數據應用變得簡單而高效。
在構建企業數據倉庫的過程中，數據往往都是周期性的從業務系統中同步到大數據平台，完成一系列的ETL轉換動作之后，最終形成了數據集市等應用。但是對於一些時間要求比較高的應用，例如實時報表統計，則必須有非常低的延時展示統計結果，為此業界提出了一套Lambda架構方案來處理不同類型的數據。
圖1-3 大數據lambada架構
圖1-3解釋：大數據平台中包含批量計算的Batch Layer和實時計算的Speed Layer，通過在一套平台中將批計算和流計算整合在一起，例如使用Hadoop MapReduce進行批量數據的處理，使用Apache Storm進行實時數據的處理。這種架構在一定程度上解決了不同計算類型的問題，但是帶來的問題是框架太多會導致平台復雜度過高、運維成本高等。在一套資源管理平台中管理不同類型的計算框架使用也是非常困難的事情。
后來隨着Apache Spark的分布式內存處理框架的出現，提出了將數據切分成微批的處理模式進行流式數據處理，從而能夠在一套計算框架內完成批量計算和流式計算。但因為Spark本身是基於批處理模式的原因，並不能完美且高效的處理原生的數據流，因此對流式計算支持的相對較弱，可以說Spark的出現本質上是在一定程度上對Hadoop架構進行了一定的升級和優化。
1.2.3有狀態流計算架構
數據產生的本質，其實是一條條真實存在的事件，前面提到的不同的架構其實都是在一定程度違背了這種本質，需要通過在一定時延的情況下對業務數據進行處理，然后得到基於業務數據統計的准確結果。實際上，基於流式計算技術局限性，我們很難再數據產生的過程中進行計算並直接產生統計結果，因為這不僅對系統有非常高的要求，還必須要滿足高性能、高吞吐、低延時等眾多目標。
圖1-4 有狀態計算架構
基於有狀態計算的方式最大的優勢是不需要將原始數據重新從外部存儲中拿出來，從而進行全量計算，因為這種計算方式的代價可能是非常高的。
1.2.4為什么會是Flink
Flink通過實現Google Dataflow流式計算模型實現了高吞吐、低延遲、高性能兼具實時流式計算框架。同時Flink支持高度容錯的狀態管理，防止狀態在計算過程中因為系統異常而出現丟失，Flink周期性地通過分布式快照技術Checkpoints實現狀態的持久化維護，使得即使在系統停機或者異常的情況下都能計算出正確的結果。
Flink的具體優勢有以下幾點：
-
同時支持高吞吐、低延遲、高性能
Flink是目前開源社區中唯一一套集高吞吐、低延遲、高性能三者於一身的分布式流式數據處理框架。像Apache Spark也只能兼顧高吞吐和高性能特性，主要因為在Spark Streaming流式計算中無法做到低延遲保障；而流式計算框架Apache Storm只能支持低延遲和高性能特性，但是無法滿足高吞吐的要求。而滿足高吞吐、低延遲、高性能這三個目標對分布式流式計算框架來說是非常重要的。 -
支持事件時間（Event Time）概念
在流式計算領域中，窗口計算的地位舉足輕重，但目前大多數框架窗口計算采用的都是系統時間（Process Time），也是事件傳輸到計算框架處理時，系統主機的當前時間。Flink能夠支持基於事件時間（Event Time）語義進行窗口計算，也就是使用事件產生的時間，這種基於事件驅動的機制使得事件即使亂序到達，流系統也能夠計算出精確的結果，保持了事件原本產生時的時序性，盡可能避免網絡傳輸或硬件系統的影響。 -
支持有狀態計算
Flink在1.4版本中實現了狀態管理，所謂狀態就是在流式計算過程中將算子的中間結果數據保存在內存或者文件系統中，等下一個事件進入算子后可以從之前的狀態中獲取中間結果中計算當前的結果，從而無須每次都基於全部的原始數據來統計結果，這種方式極大地提升了系統的性能，並降低了數據計算過程的資源消耗。對於數據量大且運算邏輯非常復雜的流式計算場景，有狀態計算發揮了非常重要的作用。 -
支持高度靈活的窗口（windows）操作
在流處理應用中，數據是連續不斷的，需要通過窗口的方式對流數據進行一定范圍的聚合計算，例如統計在過去的1分鍾內有多少用戶點擊某一網頁，在這種情況下，我們必須定義一個窗口，用來收集最近一分鍾內的數據，並對這個窗口內的數據進行再計算。Flink將窗口划分為基於Time、Count、Session，以及Data-driven等類型的窗口操作，窗口可以用靈活的觸發條件定制化來達到對復雜的流傳輸模式的支持，用戶可以定義不同的窗口觸發機制來滿足不同的需求。
-
基於輕量級分布式快照（Snapshot）實現的容錯
Flink能夠分布式運行在上千個節點上，將一個大型計算任務的流程拆解成小的計算過程，然后將tesk分布到並行節點上進行處理。在任務執行過程中，能夠自動發現事件處理過程中的錯誤而導致數據不一致的問題，比如：節點宕機、網路傳輸問題，或是由於用戶因為升級或修復問題而導致計算服務重啟等。在這些情況下，通過基於分布式快照技術的Checkpoints，將執行過程中的狀態信息進行持久化存儲，一旦任務出現異常停止，Flink就能夠從Checkpoints中進行任務的自動恢復，以確保數據在處理過程中的一致性。 -
基於JVM實現獨立的內存管理
內存管理是所有計算框架需要重點考慮的部分，尤其對於計算量比較大的計算場景，數據在內存中該如何進行管理顯得至關重要。針對內存管理，Flink實現了自身管理內存的機制，盡可能減少JVM GC對系統的影響。另外，Flink通過序列化/反序列化方法將所有的數據對象轉換成二進制在內存中存儲，降低數據存儲的大小的同時，能夠更加有效地對內存空間進行利用，降低GC帶來的性能下降或任務異常的風險，因此Flink較其他分布式處理的框架會顯得更加穩定，不會因為JVM GC等問題而影響整個應用的運行。 -
Save Points（保存點）
對於7*24小時運行的流式應用，數據源源不斷地接入，在一段時間內應用的終止有可能導致數據的丟失或者計算結果的不准確，例如進行集群版本的升級、停機運維操作等操作。值得一提的是，Flink通過Save Points技術將任務執行的快照保存在存儲介質上，當任務重啟的時候可以直接從事先保存的Save Points恢復原有的計算狀態，使得任務繼續按照停機之前的狀態運行，Save Points技術可以讓用戶更好地管理和運維實時流式應用。
1.3 Flink應用場景
- 實時智能推薦
- 復雜事件處理
- 實時欺詐檢測
- 實時數倉與ETL
- 流數據分析
- 實時報表分析
1.4 Flink基本架構
1.4.1 基本組件棧
圖1-5 Flink基本組件棧
flink分為架構分為三層，由上往下依次是API&Libraries層、Runtime核心層以及物理部署層
API&Libraries層
作為分布式數據處理框架，Flink同時提供了支撐計算和批計算的接口，同時在此基礎上抽象出不同的應用類型的組件庫，如基於流處理的CEP(復雜事件處理庫)、SQL&Table庫和基於批處理的FlinkML(機器學習庫)等、Gelly(圖處理庫)等。API層包括構建流計算應用的DataStream API和批計算應用的DataSet API，兩者都提供給用戶豐富的數據處理高級API，例如Map、FlatMap操作等，同時也提供比較低級的Process Function API，用戶可以直接操作狀態和時間等底層數據。
Runtime核心層
該層主要負責對上層不同接口提供基礎服務，也是Flink分布式計算框架的核心實現層，支持分布式Stream作業的執行、JobGraph到ExecutionGraph的映射轉換、任務調度等。將DataSteam和DataSet轉成統一的可執行的Task Operator，達到在流式引擎下同時處理批量計算和流式計算的目的。
物理部署層
該層主要涉及Flink的部署模式，目前Flink支持多種部署模式：本地、集群(Standalone、YARN)、雲(GCE/EC2)、Kubenetes。Flink能夠通過該層能夠支持不同平台的部署，用戶可以根據需要選擇使用對應的部署模式。
1.4.2基本架構圖
圖1-6 Flink基本架構圖
Flink系統主要由兩個組件組成，分別為JobManager和TaskManager，Flink架構也遵循Master-Slave架構設計原則，JobManager為Master節點，TaskManager為Worker(Slave)節點。所有組件之間的通信都是借助於Akka Framework，包括任務的狀態以及Checkpoint觸發等信息。
1.Client客戶端
客戶端負責將任務提交到集群，與JobManager構建Akka連接，然后將任務提交到JobManager，通過和JobManager之間進行交互獲取任務執行狀態。客戶端提交任務可以采用CLI方式或者通過使用Flink WebUI提交，也可以在應用程序中指定JobManager的RPC網絡端口構建ExecutionEnvironment提交Flink應用。
2.JobManager
JobManager負責整個Flink集群任務的調度以及資源的管理，從客戶端中獲取提交的應用，然后根據集群中TaskManager上TaskSlot的使用情況，為提交的應用分配相應的TaskSlots資源並命令TaskManager啟動從客戶端中獲取的應用。JobManager相當於整個集群的Master節點，且整個集群中有且僅有一個活躍的JobManager，負責整個集群的任務管理和資源管理。JobManager和TaskManager之間通過Actor System進行通信，獲取任務執行的情況並通過Actor System將應用的任務執行情況發送給客戶端。同時在任務執行過程中，Flink JobManager會觸發Checkpoints操作，每個TaskManager節點收到Checkpoint觸發指令后，完成Checkpoint操作，所有的Checkpoint協調過程都是在Flink JobManager中完成。當任務完成后，Flink會將任務執行的信息反饋給客戶端，並且釋放掉TaskManager中的資源以供下一次提交任務使用。
3.TaskManager
TaskManager相當於整個集群的Slave節點，負責具體的任務執行和對應任務在每個節點上的資源申請與管理。客戶端通過將編寫好的Flink應用編譯打包，提交到JobManager，然后JobManager會根據已經注冊在JobManager中TaskManager的資源情況，將任務分配給有資源的TaskManager節點，然后啟動並運行任務。TaskManager從JobManager接收需要部署的任務，然后使用Slot資源啟動Task，建立數據接入的網絡連接，接收數據並開始數據處理。同時TaskManager之間的數據交互都是通過數據流的方式進行的。
可以看出，Flink的任務運行其實是采用多線程的方式，這和MapReduce多JVM進程的方式有很大的區別Flink能夠極大提高CPU使用效率，在多個任務和Task之間通過TaskSlot方式共享系統資源，每個TaskManager中管理多個TaskSlot資源池進行對資源進行有效管理。
總結：
本章主要是對Flink有個初步的認識和了解。