天天看點

Flink介紹、特點及和與其他大資料架構對比Flink 是什麼為什麼要用Flink應用場景特點和優勢流式計算架構對比

文章目錄

  • Flink 是什麼
    • Flink定義
    • 有界流和無界流
    • 有狀态的計算架構
  • 為什麼要用Flink
  • 應用場景
  • 特點和優勢
  • 流式計算架構對比

Flink 是什麼

在資料量激增的時代,各種業務場景都有大量的業務資料産生,對于這些不斷産生的資料應該如何進行有效的處理,成為當下大多數公司所面臨的問題。目前比較流行的大資料處理引擎 Apache Spark,基本上已經取代了 MapReduce 成為目前大資料處理的标準。但對實時資料處理來說,Apache Spark 的 Spark-Streaming 還有性能改進的空間。Spark-Streaming 的流計算本質上還是批(微批)計算,Apache Flink 就是近年來在開源社群不斷發展的技術中的能夠同時支援高吞吐、低延遲、高性能的純實時的分布式處理架構。

Flink定義

Apache Flink 是一個架構和分布式處理引擎,用于在無邊界和有邊界資料流上進行有狀态的計算。Flink 能在所有常見叢集環境中運作,并能以記憶體速度和任意規模進行計算。

Apache Flink is a framework and distributed processing engine for stateful computations over unbounded and bounded data streams. Flink has been designed torun in all common cluster environments, perform computations at in-memory speed and at any scale.

有界流和無界流

無界流: 有定義流的開始,但沒有定義流的結束。它們會無休止地産生資料。無界流的資料必須持續處理,即資料被攝取後需要立刻處理。不能等到所有資料都到達再處理,因為輸入是無限的,在任何時候輸入都不會結束。處理無界資料通常要求以特定順序攝取事件,例如事件發生的順序,以便能夠推斷結果的完整性。

有界流: 有定義流的開始,也有定義流的結束。有界流可以在攝取所有資料後再進行計算。有界流中所有資料可以被排序,是以并不需要有序攝取。有界流處理通常被稱為批處理

有狀态的計算架構

資料流就是是一條條真實存在的事件按照時間順序源源不斷的産生。我們很難在資料産生的過程中直接進行計算并産生統計結果,因為這不僅對系統有非常高的要求,還必須要滿足高性能、高吞吐、低延時等衆多目标。

有狀态流計算架構(如圖所示)的提出,從一定程度上滿足了企業的這種需求,基于實時的流式資料,維護所有計算過程的狀态(所謂狀态就是計算過程中産生的中間計算結果),每次新的資料進入到系統中,都基于中間狀态結果進行運算,最終産生正确的統計結果。

基于有狀态計算最大的優勢是不需要将原始資料重新從外部存儲中拿出來進行全量計算(這種計算方式代價非常高)。同時,使用者無須通過排程和協調各種批量計算工具,從資料倉庫中擷取資料統計結果,可以極大地減輕系統對其他架構的依賴,減少資料計算過程中的時間損耗以及硬體存儲。

為什麼要用Flink

有狀态流計算将會逐漸成為企業作為建構資料平台的架構模式,而目前從社群來看,能夠滿足的隻有 Apache Flink。Flink 通過實作 Google Dataflow 流式計算模型實作了高吞吐、低延遲、高性能兼具實時流式計算架構。同時 Flink 支援高度容錯的狀态管理,防止狀态在計算過程中因為系統異常而出現丢失,Flink 周期性地通過分布式快照技術Checkpoints 實作狀态的持久化維護,使得即使在系統停機或者異常的情況下都能計算出正确的結果

應用場景

理論上所有大資料場景都可以使用Flink,例如金融交易資料、網際網路訂單資料、GPS 定位資料、傳感器信号、移動終端産生的資料、通信信号資料等,以及我們熟悉的網絡流量監控、伺服器産生的日志資料,這些資料最大的共同點就是實時從不同的資料源中産生,然後再傳輸到下遊的分析系統。主要包括實時智能推薦、複雜事件處理、實時欺詐檢測、實時數倉與 ETL 類型、流資料分析類型、實時報表類型等實時業務場景

特點和優勢

Flink具有以下特點

1. 同時支援高吞吐、低延遲、高性能

Flink 是目前開源社群中唯一一套集高吞吐、低延遲、高性能三者于一身的分布式流式資料處理架構。像 Apache Spark 也隻能兼顧高吞吐和高性能特性而流式計算架構 Apache Storm 隻能支援低延遲和高性能特性,但是無法滿足高吞吐的要求

2. 支援事件時間(Event Time)概念

目前大多數架構視窗計算采用的都是系統時間(Process Time),也是事件傳輸到計算架構處理時,系統主機的目前時間。Flink 能夠支援基于事件時間(Event Time)語義進行視窗計算,也就是使用事件産生的時間,這種基于事件驅動的機制使得事件即使亂序到達,流系統也能夠計算出精确的結果,保持了事件原本産生時的時序性,盡可能避免網絡傳輸或硬體系統的影響

3. 支援有狀态計算

所謂狀态就是在流式計算過程中将算子的中間結果資料儲存在記憶體或者檔案系統中,等下一個事件進入算子後可以從之前的狀态中擷取中間結果中計算目前的結果,進而無須每次都基于全部的原始資料來統計結果,這種方式極大地提升了系統的性能,并降低了資料計算過程的資源消耗

4. 支援高度靈活的視窗(Window)操作

在流處理應用中,資料是連續不斷的,需要通過視窗的方式對流資料進行一定範圍的聚合計算,例如統計在過去的 1 分鐘内有多少使用者點選某一網頁,在這種情況下,我們必須定義一個視窗,用來收集最近一分鐘内的資料,并對這個視窗内的資料進行再計算。Flink 将視窗劃分為基于 Time、Count、Session,以及 Data-driven 等類型的視窗操作,視窗可以用靈活的觸發條件定制化來達到對複雜的流傳輸模式的支援,使用者可以定義不同的視窗觸發機制來滿足不同的需求

5. 基于輕量級分布式快照(CheckPoint)實作的容錯

Flink 能夠分布式運作在上千個節點上,将一個大型計算任務的流程拆解成小的計算過程,然後将 tesk 分布到并行節點上進行處理。在任務執行過程中,能夠自動發現事件處理過程中的錯誤而導緻資料不一緻的問題,比如:節點當機、網路傳輸問題,或是由于使用者因為更新或修複問題而導緻計算服務重新開機等。在這些情況下,通過基于分布式快照技術的 Checkpoints,将執行過程中的狀态資訊進行持久化存儲,一旦任務出現異常停止,Flink 就能夠從 Checkpoints 中進行任務的自動恢複,以確定資料在處理過程中的一緻性(Exactly-Once)

6. 基于 JVM 實作獨立的記憶體管理

Flink 實作了自身管理記憶體的機制,盡可能減少 JVM GC 對系統的影響。另外,Flink 通過序列化/反序列化方法将所有的資料對象轉換成二進制在記憶體中存儲,降低資料存儲的大小的同時,能夠更加有效地對記憶體空間進行利用,降低 GC 帶來的性能下降或任務異常的風險,是以Flink 較其他分布式處理的架構會顯得更加穩定,不會因為 JVM GC 等問題而影響整個應用的運作

7. Save Points(儲存點)

對于 7*24 小時運作的流式應用,資料源源不斷地接入,在一段時間内應用的終止有可能導緻資料的丢失或者計算結果的不準确,例如進行叢集版本的更新、停機運維等操作。Flink 通過 Save Points 技術将任務執行的快照儲存在存儲媒體上,當任務重新開機的時候可以直接從事先儲存的 Save Points 恢複原有的計算狀态,使得任務繼續按照停機之前的狀态運作,Save Points 技術可以讓使用者更好地管理和運維實時流式應用

流式計算架構對比

計算引擎的發展經曆了幾個過程,從第 1 代的 MapReduce,到第 2 代基于有向無環圖的 Tez,第 3 代基于記憶體計算的 Spark,再到第 4 代的 Flink,各架構對比如下:

Flink介紹、特點及和與其他大資料架構對比Flink 是什麼為什麼要用Flink應用場景特點和優勢流式計算架構對比

模型: Storm 和 Flink 是真正的一條一條處理資料;而 Trident(Storm 的封裝架構)和 Spark Streaming 其實都是小批處理,一次處理一批資料(小批量)。

API : Storm 和 Trident 都使用基礎 API 進行開發,操作相對複雜;而 Spark Streaming 和 Flink 中都提供封裝後的高階函數,可以直接拿來使用,這樣就比較友善了。

保證次數: 在資料處理方面,Storm 可以實作至少處理一次,但不能保證僅處理一次,這樣就會導緻資料重複處理問題,是以針對計數類的需求,可能會産生一些誤差;Trident 通過事務可以保證對資料實作僅一次的處理,Spark Streaming 和 Flink 也是如此。

容錯機制: Storm和Trident可以通過ACK機制實作資料的容錯機制,而Spark Streaming和 Flink 可以通過 CheckPoint 機制實作容錯。

狀态管理: Storm 中沒有實作狀态管理,Spark Streaming 實作了基于 DStream 的狀态管理,而 Trident 和 Flink 實作了基于操作的狀态管理。

延時: 表示資料處理的延時情況,因為 Storm 和 Flink 接收到一條資料就處理一條資料,其資料處理的延時性是很低的;而 Trident 和 Spark Streaming 都是小型批處理,它們資料處理的延時性相對會偏高。

吞吐量: Storm 的吞吐量其實也不低,隻是相對于其他幾個架構而言較低;Trident 屬于中等;而 Spark Streaming 和 Flink 的吞吐量是比較高的。

繼續閱讀