大資料時代，且看Flink如何叱吒風雲

Flink專案是大資料計算領域冉冉升起的一顆新星。

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

Flink原理分析

很多人是在2015年才聽到Flink這個詞的，其實早在2008年，Flink的前身就已經是柏林理工大學的一個研究性專案，在2014年這個專案被Apache孵化器所接受後，Flink迅速成為ASF(Apache Software Foundation)的頂級專案之一。

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

分散式：Flink程式可以執行在多臺機器上。

高效能：處理效能比較高。

高可用：由於Flink程式本身是穩定的，因此它支援高可用性(High Availability，HA)。

準確：Flink可以保證資料處理的準確性。

Flink主要由Java程式碼實現，它同時支援實時流處理和批處理。對於Flink而言，作為一個流處理框架，批資料只是流資料的一個極限特例而已。此外，Flink還支援迭代計算、記憶體管理和程式最佳化，這是它的原生特性。

Flink特性

支援批處理和資料流程式處理

優雅流暢的支援java和scala api

同時支援高吞吐量和低延遲

支援事件處理和無序處理透過SataStream API，基於DataFlow資料流模型

在不同的時間語義(時間時間，處理時間)下支援靈活的視窗(時間，技術，會話，自定義觸發器)

僅處理一次的容錯擔保

自動反壓機制

圖處理(批) 機器學習(批) 複雜事件處理(流)

在dataSet(批處理)API中內建支援迭代程式(BSP)

高效的自定義記憶體管理，和健壯的切換能力在in-memory和out-of-core中

相容hadoop的mapreduce和storm

整合YARN,HDFS,Hbase 和其它hadoop生態系統的元件

Flink的功能特性

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

Flink架構分析

Flink架構可以分為4層，包括Deploy層、Core層、API層和Library層

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 操作。

Flink對底層的一些操作進行了封裝，為使用者提供了DataStream API和DataSet API。使用這些API可以很方便地完成一些流資料處理任務和批資料處理任務。

Flink架構

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

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

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

透過靈活的執行引擎，Flink能夠同時支援批處理任務與流處理任務。在執行引擎層級，流處理系統與批處理系統最大的不同在於節點間的資料傳輸方式。

對於一個流處理系統，其節點間資料傳輸的標準模型是，在處理完成一條資料後，將其序列化到快取中，並立刻透過網路傳輸到下一個節點，由下一個節點繼續處理。而對於一個批處理系統，其節點間資料傳輸的標準模型是，在處理完成一條資料後，將其序列化到快取中，當快取寫滿時，就持久化到本地硬碟上;在所有資料都被處理完成後，才開始將其透過網路傳輸到下一個節點。

Flink的3種資料傳輸模型

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

Flink以固定的快取塊為單位進行網路資料傳輸，使用者可以透過設定快取塊超時值指定快取塊的傳輸時機。如果快取塊的超時值為0，則Flink的資料傳輸方式類似於前面所提到的流處理系統的標準模型，此時系統可以獲得最低的處理延遲;如果快取塊的超時值為無限大，則Flink的資料傳輸方式類似於前面所提到的批處理系統的標準模型，此時系統可以獲得最高的吞吐量。

快取塊的超時值也可以設定為0到無限大之間的任意值，快取塊的超時閾值越小，Flink流處理執行引擎的資料處理延遲就越低，但吞吐量也會降低，反之亦然。透過調整快取塊的超時閾值，使用者可根據需求靈活地權衡系統延遲和吞吐量。

Flink典型應用場景分析

Flink主要應用於流式資料分析場景，目前涉及如下領域。

實時ETL：整合流計算現有的諸多資料通道和SQL靈活的加工能力，對流式資料進行實時清洗、歸併和結構化處理;同時，對離線資料進行有效的補充和最佳化，併為資料實時傳輸提供可計算通道。

實時報表：實時化採集、加工流式資料儲存;實時監控和展現業務、客戶各類指標，讓資料化運營實時化。

監控預警：對系統和使用者行為進行實時檢測和分析，以便及時發現危險行為。

線上系統：實時計算各類資料指標，並利用實時結果及時調整線上系統的相關策略，在各類內容投放、無線智慧推送領域有大量的應用。

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

最佳化電商網站的實時搜尋結果：阿里巴巴的基礎設施團隊使用Flink實時更新產品細節和庫存資訊(Blink)。

針對資料分析團隊提供實時流處理服務：透過Flink資料分析平臺提供實時資料分析服務，及時發現問題。

網路/感測器檢測和錯誤檢測：Bouygues電信公司是法國著名的電信供應商，使用Flink監控其有線和無線網路，實現快速故障響應。

商業智慧分析ETL：Zalando使用Flink轉換資料以便於將其載入到資料倉儲，簡化複雜的轉換操作，並確保分析終端使用者可以更快地訪問資料(實時ETL)。

流式計算框架對比

Storm是比較早的流式計算框架，後來又出現了Spark Streaming和Trident，現在又出現了Flink這種優秀的實時計算框架，那麼這幾種計算框架到底有什麼區別呢?下面我們來詳細分析一下

流式計算框架對比

產品模型API保證次數容錯機制狀態管理延時吞吐量StormNative(資料進入立即處理)組合式(基礎API)At-least-once (至少一次)Record ACK(ACK機制)無低低TridentMicro-Batching(劃分為小批 處理)組合式Exactly-once (僅一次)Record ACK基於操作(每次操作有一個狀態)中等中等Spark StreamingMicro-Batching宣告式(提供封裝後的高階函式，如count函式)Exactly-onceRDD CheckPoint(基於RDD做CheckPoint)基於DStream中等高FlinkNative宣告式Exactly-onceCheckPoint(Flink的一種快照)基於操作低高

在這裡對這幾種框架進行對比。

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

API：Storm和Trident都使用基礎API進行開發，比如實現一個簡單的sum求和操作;而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的吞吐量是比較高的。

官網中Flink和Storm的吞吐量對如圖

Flink和Storm的吞吐量對比

前面我們分析了3種實時計算框架，那麼公司在實際操作時到底選擇哪種技術框架呢?下面我們來分析一下。

需要關注流資料是否需要進行狀態管理，如果是，那麼只能在Trident、Spark Streaming和Flink中選擇一個。

需要考慮專案對At-least-once(至少一次)或者Exactly-once(僅一次)訊息投遞模式是否有特殊要求，如果必須要保證僅一次，也不能選擇Storm。

對於小型獨立的專案，並且需要低延遲的場景，建議使用Storm，這樣比較簡單。

如果你的專案已經使用了Spark，並且秒級別的實時處理可以滿足需求的話，建議使用Spark Streaming

要求訊息投遞語義為Exactly-once;資料量較大，要求高吞吐低延遲;需要進行狀態管理或視窗統計，這時建議使用Flink。