Apache Flink是什么？
? 在當代資料量激增的時代，各種業務場景都有大量的業務資料產生，對于這些不斷產生的資料應該如何進行有效的處理，成為當下大多數公司所面臨的問題，隨著雅虎對hadoop的開源，越來越多的大資料處理技術開始涌入人們的視線，例如目前比較流行的大資料處理引擎Apache Spark,基本上已經取代了MapReduce成為當前大資料處理的標準，但是隨著資料的不斷增長，新技術的不斷發展，人們逐漸意識到對實時資料處理的重要性，相對于傳統的資料處理模式，流式資料處理有著更高的處理效率和成本控制能力，Flink 就是近年來在開源社區不斷發展的技術中的能夠同時支持高吞吐、低延遲、高性能的分布式處理框架，
資料架構的演變
如圖所示，傳統的單體資料架構最大的特點便是 集中式資料存盤，大多數將架構分為計算層和存盤層，
單體架構的初期效率很高，但是隨著時間的推移，業務越來越多，系統逐漸變得很大，越來越難以維護和升級，資料庫是唯一的準確資料源，每個應用都需要訪問資料庫來獲取對應的資料，如果資料庫發生改變或者出現問題，則將對整個業務系統產生影響，
后來隨著微服務架構的出現，企業開始采用微服務作為企業業務系統的架構體系，微服務架構的核心思想是：一個應用是由多個小的、相互獨立的微服務組成，這些服務運行在自己的行程中，開發和發布都沒有依賴，不同的服務能依據不同的業務需求，構建的不同的技術架構之上，能夠聚焦在有限的業務功能， 如圖
微服務架構
起初資料倉庫主要還是構建在關系型資料庫之上，例如Oracle、Mysql等資料庫，但是隨著企業資料量的增長，關系型資料庫已經無法支撐大規模資料集的存盤和分析，因為越來越多的企業開始選擇基于Hadoop構建企業級大資料平臺，同時眾多的Sql_on_hadhoop上構建不同型別的資料應用變得簡單而高效，
在構建企業資料倉庫的程序中，資料往往都是周期性的從業務系統中同步到大資料平臺，完成一系列的ETL轉換動作之后，最終形成了資料集市等應用，但是對于一些時間要求比較高的應用，例如實時報表統計，則必須有非常低的延時展示統計結果，為此業界提出了一套Lambda架構方案來處理不同型別的資料，
大資料lambada架構
大資料平臺中包含批量計算的Batch Layer和實時計算的Speed Layer，通過在一套平臺中將批計算和流計算整合在一起，例如使用Hadoop MapReduce進行批量資料的處理，使用Apache Storm進行實時資料的處理，這種架構在一定程度上解決了不同計算型別的問題，但是帶來的問題是框架太多會導致平臺復雜度過高、運維成本高等，在一套資源管理平臺中管理不同型別的計算框架使用也是非常困難的事情，
后來隨著Apache Spark的分布式記憶體處理框架的出現，提出了將資料切分成微批的處理模式進行流式資料處理，從而能夠在一套計算框架內完成批量計算和流式計算，但因為Spark本身是基于批處理模式的原因，并不能完美且高效的處理原生的資料流，因此對流式計算支持的相對較弱，可以說Spark的出現本質上是在一定程度上對Hadoop架構進行了一定的升級和優化，
有狀態流計算架構
資料產生的本質，其實是一條條真實存在的事件，前面提到的不同的架構其實都是在一定程度違背了這種本質，需要通過在一定時延的情況下對業務資料進行處理，然后得到基于業務資料統計的準確結果，實際上，基于流式計算技術局限性，我們很難再資料產生的程序中進行計算并直接產生統計結果，因為這不僅對系統有非常高的要求，還必須要滿足高性能、高吞吐、低延時等眾多目標，
基于有狀態計算的方式最大的優勢是不需要將原始資料重新從外部存盤中拿出來，從而進行全量計算，因為這種計算方式的代價可能是非常高的，
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技術可以讓用戶更好地管理和運維實時流式應用，
更多實時計算,Flink,Kafka,ES等相關技術博文，歡迎關注實時流式計算
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/231954.html
標籤：其他
上一篇：Bug 28450914 : ORA-600: [KDLRCI_GET_INLINE_DATA] SELECTING FROM CDB_FEATURE_USAGE_STATISTICS