Flink入門（一）——Apache Flink介紹

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的具體優點有如下幾點：

1. 同時支持高吞吐、低延遲、高性能 Flink是目前開源社區中惟一一套集高吞吐、低延遲、高性能三者於一身的分佈式流式數據處理框架。像Apache Spark也只能兼顧高吞吐和高性能特性，主要由於在Spark Streaming流式計算中沒法作到低延遲保障；而流式計算框架Apache Storm只能支持低延遲和高性能特性，可是沒法知足高吞吐的要求。而知足高吞吐、低延遲、高性能這三個目標對分佈式流式計算框架來講是很是重要的。

2. 支持事件時間（Event Time）概念 在流式計算領域中，窗口計算的地位舉足輕重，但目前大多數框架窗口計算採用的都是系統時間（Process Time），也是事件傳輸到計算框架處理時，系統主機的當前時間。Flink可以支持基於事件時間（Event Time）語義進行窗口計算，也就是使用事件產生的時間，這種基於事件驅動的機制使得事件即便亂序到達，流系統也可以計算出精確的結果，保持了事件本來產生時的時序性，儘量避免網絡傳輸或硬件系統的影響。

3. 支持有狀態計算 Flink在1.4版本中實現了狀態管理，所謂狀態就是在流式計算過程當中將算子的中間結果數據保存在內存或者文件系統中，等下一個事件進入算子後能夠從以前的狀態中獲取中間結果中計算當前的結果，從而無須每次都基於所有的原始數據來統計結果，這種方式極大地提高了系統的性能，並下降了數據計算過程的資源消耗。對於數據量大且運算邏輯很是複雜的流式計算場景，有狀態計算髮揮了很是重要的做用。

4. 支持高度靈活的窗口（windows）操做

   在流處理應用中，數據是接二連三的，須要經過窗口的方式對流數據進行必定範圍的聚合計算，例如統計在過去的1分鐘內有多少用戶點擊某一網頁，在這種狀況下，咱們必須定義一個窗口，用來收集最近一分鐘內的數據，並對這個窗口內的數據進行再計算。Flink將窗口劃分爲基於Time、Count、Session，以及Data-driven等類型的窗口操做，窗口能夠用靈活的觸發條件定製化來達到對複雜的流傳輸模式的支持，用戶能夠定義不一樣的窗口觸發機制來知足不一樣的需求。

5. 基於輕量級分佈式快照（Snapshot）實現的容錯 Flink可以分佈式運行在上千個節點上，將一個大型計算任務的流程拆解成小的計算過程，而後將tesk分佈到並行節點上進行處理。在任務執行過程當中，可以自動發現事件處理過程當中的錯誤而致使數據不一致的問題，好比：節點宕機、網路傳輸問題，或是因爲用戶由於升級或修復問題而致使計算服務重啓等。在這些狀況下，經過基於分佈式快照技術的Checkpoints，將執行過程當中的狀態信息進行持久化存儲，一旦任務出現異常中止，Flink就可以從Checkpoints中進行任務的自動恢復，以確保數據在處理過程當中的一致性。

6. 基於JVM實現獨立的內存管理 內存管理是全部計算框架須要重點考慮的部分，尤爲對於計算量比較大的計算場景，數據在內存中該如何進行管理顯得相當重要。針對內存管理，Flink實現了自身管理內存的機制，儘量減小JVM GC對系統的影響。另外，Flink經過序列化/反序列化方法將全部的數據對象轉換成二進制在內存中存儲，下降數據存儲的大小的同時，可以更加有效地對內存空間進行利用，下降GC帶來的性能降低或任務異常的風險，所以Flink較其餘分佈式處理的框架會顯得更加穩定，不會由於JVM GC等問題而影響整個應用的運行。

7. Save Points（保存點） 對於7*24小時運行的流式應用，數據源源不斷地接入，在一段時間內應用的終止有可能致使數據的丟失或者計算結果的不許確，例如進行集羣版本的升級、停機運維操做等操做。值得一提的是，Flink經過Save Points技術將任務執行的快照保存在存儲介質上，當任務重啓的時候能夠直接從事先保存的Save Points恢復原有的計算狀態，使得任務繼續按照停機以前的狀態運行，Save Points技術可讓用戶更好地管理和運維實時流式應用。

更多實時計算,Flink,Kafka,ES等相關技術博文，歡迎關注實時流式計算

本文由博客一文多發平臺 OpenWrite 發佈！