阿里巴巴主推的 Flink 為什麼火?

Flink項目是大數據計算領域冉冉升起的一顆新星。大數據計算引擎的發展經歷了幾個過程,從第1代的MapReduce,到第2代基於有向無環圖的Tez,第3代基於內存計算的Spark,再到第4代的Flink。因為Flink可以基於Hadoop進行開發和使用,所以Flink並不會取代Hadoop,而是和Hadoop緊密結合。




Flink主要包括DataStream API、DataSet API、Table API、SQL、Graph API和FlinkML等。現在Flink也有自己的生態圈,涉及離線數據處理、實時數據處理、SQL操作、圖計算和機器學習庫等。

1.1 Flink原理分析

很多人是在2015年才聽到Flink這個詞的,其實早在2008年,Flink的前身就已經是柏林理工大學的一個研究性項目,在2014年這個項目被Apache孵化器所接受後,Flink迅速成為ASF(Apache Software Foundation)的頂級項目之一。截至目前,Flink的版本經過了多次更新,本書基於1.6版本寫作。

Flink是一個開源的流處理框架,它具有以下特點。

  • 分佈式:Flink程序可以運行在多臺機器上。
  • 高性能:處理性能比較高。
  • 高可用:由於Flink程序本身是穩定的,因此它支持高可用性(High Availability,HA)。
  • 準確:Flink可以保證數據處理的準確性。

Flink主要由Java代碼實現,它同時支持實時流處理和批處理。對於Flink而言,作為一個流處理框架,批數據只是流數據的一個極限特例而已。此外,Flink還支持迭代計算、內存管理和程序優化,這是它的原生特性。

由圖1.1可知,Flink的功能特性如下。

  • 流式優先:Flink可以連續處理流式數據。
  • 容錯:Flink提供有狀態的計算,可以記錄數據的處理狀態,當數據處理失敗的時候,能夠無縫地從失敗中恢復,並保持Exactly-once。
  • 可伸縮:Flink中的一個集群支持上千個節點。
  • 性能:Flink支持高吞吐、低延遲。
阿里巴巴主推的 Flink 為什麼火?

圖1.1 Flink的功能特性

在這裡解釋一下,高吞吐表示單位時間內可以處理的數據量很大,低延遲表示數據產生以後可以在很短的時間內對其進行處理,也就是Flink可以支持快速地處理海量數據。

1.2 Flink架構分析

Flink架構可以分為4層,包括Deploy層、Core層、API層和Library層,如圖1.2所示。

  • Deploy層:該層主要涉及Flink的部署模式,Flink支持多種部署模式——本地、集群(Standalone/YARN)和雲服務器(GCE/EC2)。
  • Core層:該層提供了支持Flink計算的全部核心實現,為API層提供基礎服務。
  • API層:該層主要實現了面向無界Stream的流處理和麵向Batch的批處理API,其中流處理對應DataStream API,批處理對應DataSet API。
  • Library層:該層也被稱為Flink應用框架層,根據API層的劃分,在API層之上構建的滿足特定應用的實現計算框架,也分別對應於面向流處理和麵向批處理兩類。面向流處理支持CEP(複雜事件處理)、基於SQL-like的操作(基於Table的關係操作);面向批處理支持FlinkML(機器學習庫)、Gelly(圖處理)、Table 操作。

從圖1.2可知, Flink對底層的一些操作進行了封裝,為用戶提供了DataStream API和DataSet API。使用這些API可以很方便地完成一些流數據處理任務和批數據處理 任務。

阿里巴巴主推的 Flink 為什麼火?

圖1.2 Flink架構

1.3 Flink基本組件

讀者應該對Hadoop和Storm程序有所瞭解,在Hadoop中實現一個MapReduce需要兩個階段——Map和Reduce,而在Storm中實現一個Topology則需要Spout和Bolt組件。因此,如果我們想實現一個Flink任務的話,也需要有類似的邏輯。

Flink中提供了3個組件,包括DataSource、Transformation和DataSink。

  • DataSource:表示數據源組件,主要用來接收數據,目前官網提供了readTextFile、socketTextStream、fromCollection以及一些第三方的Source。
  • Transformation:表示算子,主要用來對數據進行處理,比如Map、FlatMap、Filter、Reduce、Aggregation等。
  • DataSink:表示輸出組件,主要用來把計算的結果輸出到其他存儲介質中,比如writeAsText以及Kafka、Redis、Elasticsearch等第三方Sink組件。

因此,想要組裝一個Flink Job,至少需要這3個組件。

Flink Job=DataSource+Transformation+DataSink

1.4 Flink流處理(Streaming)與批處理(Batch)

在大數據處理領域,批處理與流處理一般被認為是兩種截然不同的任務,一個大數據框架一般會被設計為只能處理其中一種任務。比如,Storm只支持流處理任務,而MapReduce、Spark只支持批處理任務。Spark Streaming是Apache Spark之上支持流處理任務的子系統,這看似是一個特例,其實不然——Spark Streaming採用了一種Micro-Batch架構,即把輸入的數據流切分成細粒度的Batch,併為每一個Batch數據提交一個批處理的Spark任務,所以Spark Streaming本質上還是基於Spark批處理系統對流式數據進行處理,和Storm等完全流式的數據處理方式完全不同。

通過靈活的執行引擎,Flink能夠同時支持批處理任務與流處理任務。在執行引擎層級,流處理系統與批處理系統最大的不同在於節點間的數據傳輸方式。

如圖1.3所示,對於一個流處理系統,其節點間數據傳輸的標準模型是,在處理完成一條數據後,將其序列化到緩存中,並立刻通過網絡傳輸到下一個節點,由下一個節點繼續處理。而對於一個批處理系統,其節點間數據傳輸的標準模型是,在處理完成一條數據後,將其序列化到緩存中,當緩存寫滿時,就持久化到本地硬盤上;在所有數據都被處理完成後,才開始將其通過網絡傳輸到下一個節點。

阿里巴巴主推的 Flink 為什麼火?

圖1.3 Flink的3種數據傳輸模型

這兩種數據傳輸模式是兩個極端,對應的是流處理系統對低延遲和批處理系統對高吞吐的要求。Flink的執行引擎採用了一種十分靈活的方式,同時支持了這兩種數據傳輸模型。

Flink以固定的緩存塊為單位進行網絡數據傳輸,用戶可以通過設置緩存塊超時值指定緩存塊的傳輸時機。如果緩存塊的超時值為0,則Flink的數據傳輸方式類似於前面所提到的流處理系統的標準模型,此時系統可以獲得最低的處理延遲;如果緩存塊的超時值為無限大,則Flink的數據傳輸方式類似於前面所提到的批處理系統的標準模型,此時系統可以獲得最高的吞吐量。

緩存塊的超時值也可以設置為0到無限大之間的任意值,緩存塊的超時閾值越小,Flink流處理執行引擎的數據處理延遲就越低,但吞吐量也會降低,反之亦然。通過調整緩存塊的超時閾值,用戶可根據需求靈活地權衡系統延遲和吞吐量。

1.5 Flink典型應用場景分析

Flink主要應用於流式數據分析場景,目前涉及如下領域。

  • 實時ETL:集成流計算現有的諸多數據通道和SQL靈活的加工能力,對流式數據進行實時清洗、歸併和結構化處理;同時,對離線數倉進行有效的補充和優化,併為數據實時傳輸提供可計算通道。
  • 實時報表:實時化採集、加工流式數據存儲;實時監控和展現業務、客戶各類指標,讓數據化運營實時化。
  • 監控預警:對系統和用戶行為進行實時檢測和分析,以便及時發現危險行為。
  • 在線系統:實時計算各類數據指標,並利用實時結果及時調整在線系統的相關策略,在各類內容投放、無線智能推送領域有大量的應用。

Flink在如下類型的公司中有具體的應用。

  • 優化電商網站的實時搜索結果:阿里巴巴的基礎設施團隊使用Flink實時更新產品細節和庫存信息(Blink)。
  • 針對數據分析團隊提供實時流處理服務:通過Flink數據分析平臺提供實時數據分析服務,及時發現問題。
  • 網絡/傳感器檢測和錯誤檢測:Bouygues電信公司是法國著名的電信供應商,使用Flink監控其有線和無線網絡,實現快速故障響應。
  • 商業智能分析ETL:Zalando使用Flink轉換數據以便於將其加載到數據倉庫,簡化複雜的轉換操作,並確保分析終端用戶可以更快地訪問數據(實時ETL)。


分享到:


相關文章: