流式處理新秀Flink原理與實踐

隨着大數據技術在各行各業的普遍應用，要求能對海量數據進行實時處理的需求愈來愈多，同時數據處理的業務邏輯也愈來愈複雜，傳統的批處理方式和早期的流式處理框架也愈來愈難以在延遲性、吞吐量、容錯能力以及使用便捷性等方面知足業務日益苛刻的要求。

在這種形勢下，新型流式處理框架Flink經過創造性地把現代大規模並行處理技術應用到流式處理中來，極大地改善了之前的流式處理框架所存在的問題。飛馬網於3月13日晚，邀請到大數據技術高級架構師—曠東林，在線上直播中，曠老師向咱們分享了Flink在諸多方面的創新以及它自己所具備的獨特能力。

 

咱們主要從如下幾個部分來看：

一.流式處理的背景：

傳統的大數據處理方式通常是批處理式的，也就是說，今天所收集的數據，咱們明天再把今天收集到的數據算出來，以供你們使用，可是在不少狀況下，數據的時效性對於業務的成敗是很是關鍵的。

 

1.流式處理的背景—必要性

 

好比說，在入侵檢測的場景下，咱們但願看到的結果是：一旦有入侵，咱們能及時地做出響應。這種狀況下，若是按照傳統的批處理方式，是不可能在入侵的時候實時檢測出結果的。另外，好比說在語音計算中，咱們要實時監控各個虛擬器的運行狀態以及出現錯誤時的預警，這種狀況下，也要求咱們可以實時監控數據，並對數據產生的各類報警，實時採起動做。由此，流式處理的必要性就顯得無疑了。

 

2.流式處理的背景—基礎架構

咱們來看一下流式處理的基本框架。

 

主要分爲六個部分：事件生產者、收集、排隊系統（其中kafka的主要目的是，在數據高峯時，暫時把它緩存，防止數據丟失。）、數據變換（也就是流式處理過程）、長期存儲、陳述/行動。

 

3.流式處理的背景—評測指標

目前的業界有不少流式處理的框架，在這麼多框架中，咱們怎樣評價這個流式處理框架的性能呢?有哪些指標呢？通常咱們會從如下這些方面來考覈流式處理框架的能力。

 

其中「數據傳輸的保障度」，是指能不能保證數據被處理併到達目的地。它有三種可能性：保證至少一次、最多一次、精確一次。大多數狀況下，「保證至少一次」就能知足業務要求，除要求數據精確度高的特定場景。

「處理延遲」，在大多數狀況下，流式處理的延遲越低越好，但不少狀況下，咱們的延遲越低，相應付出的代價也越高，「吞吐量」與「處理延遲」就是一對矛盾。吞吐量高，相應的延遲就會低，吞吐量低，相應的延遲就會高。

「狀態管理」，咱們在實時變換的過程當中，要有與外部的交互，如入侵檢測，以此來保護環境和數據的安全。

「容錯能力」和「容錯負荷」要求當流式處理在正常進行中，即便有某些機器掛掉，系統仍能正常運行，整個流式處理框架不受影響。

「流控」，也就是流量控制，咱們在數據傳輸的過程當中，可能會數據忽然增多，爲了保證系統不至於負荷太重而崩潰，這時候就須要控制數據密度。

「編程複雜性」，相對而言，API設計地越高級，編程負擔越低。

 

4.流式處理的背景—選型

瞭解流式處理框架的考覈標準以後，那麼咱們爲何選擇Flink？Flink有哪些優點呢？

 

「保證帶狀態計算下的精確一次語義」，對於某些特定的計算而言很是有必要。

通常在流式處理框架中，數據的處理通常有兩種方式，一種是按照處理時間來處理數據，另外一種就是按照事件時間來處理數據，「事件時間語義支持」方式更爲複雜。

Flink的API很是高級，在處理流式數據的邏輯業務中，效率更高。

 

二．Flink的原理：

瞭解Flink的背景以後，咱們一塊兒來看一看它的原理。

 

1.概述

Flink的整個組件相似於Spark,它的核心是一個分佈式的流式處理框架，在覈心之上，有兩套API，一套應用於批處理—DataSet API，一套應用於流式處理—DataStream API。

 

從圖中咱們能夠看到，在兩套API下又有更爲高級的庫，而它的整個處理部署方式能夠支持本地、集羣、雲端。

 

2.基礎架構

Flink的整個架構和Spark很類似，有三個主要部分。

 

一個是提交任務的客戶端—Flink Program；還有做業的管理器—JobManager，主要負責任務的調度和狀態的檢測，以及在整個集羣出現故障時進行初步管理；最後是任務管理器—TaskManager，實現業務邏輯的執行，負責把接受到的任務運行以後，將相應的結果輸出到外部或進行外部交互。

在整個過程當中，JobManager是不負責任務執行的。

 

3.編程模型

下面咱們來看一下Flink的具體編程模型結構。

第一條語句是創建整個Flink運行時的環境，相似於Spark裏創建一個上下文。它的主要業務邏輯是由指定數據源、指定變換邏輯、指定輸出三部分決定的。

指定數據源的過程就是nv.addSource，這是指定咱們的數據到底從哪裏來，在這個設計中，它是從kafka裏把數據讀出來。在這個事例裏面，數據流的變換比較簡單，只是把每一行數據作一個解析，解析完後得到另外一個數據流，就構成了 DataStreamevents這個數據流。

在這個數據流上面，咱們作了一個分組：keyBy(「id」)、timeWindow(Time.seconds(10))、apply(new MyWindowAggregationFunction())。咱們把整個數據處理完以後，獲得一個統計數據流，指定輸出。

這大體就是整個數據流的業務邏輯，箭頭下方是數據流圖。

 

 

示例裏面展現的只是部分API，除了上面那些，還有不少操做，咱們一塊兒來看下面這張圖片。

 

「map」就是作一些映射，好比咱們把兩個字符串合併成一個字符串，把一個字符串拆成兩個或者三個字符串。

「flatMap」相似於把一個記錄拆分紅兩條、三條、甚至是四條記錄。

「Filter」就相似於過濾。

「keyBy」就等效於SQL裏的group by。

「reduce」就相似於MapReduce裏的reduce。

「join」操做就有點相似於咱們數據庫裏面的join。

「aggregate」是一個聚合操做，如計數、求和、求平均等。

「connect」實現把兩個流連成一個流。

「project」操做就相似於SQL裏面的snacks。

「repartition」是一個從新分區操做。

 

4.執行機制

知道Flink的編程模型以後，那麼Flink是怎樣去運行這些業務邏輯的呢？下面是它的執行機制。

 

上圖是表現業務邏輯的業務執行圖，Flink的執行方式相似於管道，它借鑑了數據庫的一些執行原理，實現了本身獨特的執行方式。

 

5.狀態與容錯

Flink的容錯機制很特別，咱們一塊兒來看一看。

 

Flink在處理數據流時，它的整個數據流裏面的數據分爲兩種，一種是自己業務發給的數據，還有一種是Flink本身插到數據流裏面的數據。插入的記錄咱們叫它barrier，就是柵欄，咱們能夠把它當作一個表示進度的標記，標記整個數據處理的狀態，它從源頭髮出。從圖中咱們能夠看到，不論是什麼流，它都會產生一個checkpoint barrier。

 

當operator收到柵欄以後，它會把柵欄的狀態存儲，而後把特定記錄發出去，到達第二個operator裏面，它又把它的狀態放到Master裏，它就是這樣一步一步去完成的。在這個過程當中，若是有一步出現故障，Flink會重複前面的步驟，從新去運行，因此不會出現數據的丟失和錯誤。

 

三.Flink的實踐：

 

1.示例

咱們來看一下具體的示例。

 

第一步是初始化框架的運行時環境；第二步是指定數據流的數據源，示例裏指定的是FlinkKafkaConsumer010<>(...)數據；第三步是實現數據流的業務變換邏輯，這裏主要是經過flatmap把一個記錄分紅多條記錄，經過filter進行過濾，以後按照域名進行分組，指定窗口長度，最後指定統計方式，這裏的統計方式是計數；第四步就是對統計出來的數據流進行指定輸出；最後一步，提交數據變換邏輯到框架中經編譯後運行。

 

2.監控

把這個程序啓動以後，咱們就能夠看到Flink的監控頁面，下面是一些監控信息。

 

咱們能夠看到，在啓動的Flink集羣裏面，有80個Task Managers，80個巢，1個空閒的巢數，紅框點進去以後，就是下面的圖片。

 

 

 

監控指標有不少。

 

 

四.總結與展望：

最後，咱們來作一下總結。以上只是關於Flink的一些簡單介紹，關於Flink的內存管理、部署、內部執行機制等相關詳細資料，咱們能夠經過如下網站進行資料查詢。

 

 

Apache Flink是有關Flink開源的官方網站。

Flink-Forward網站主要介紹各家大公司在使用Flink過程當中的心得體會，以及Flink自己的發展提案的一些相關內容。

dataArtisans是Flink背後的一個商業公司，Flink由它發展起來。它上面的博客包含好多關於Flinkd的介紹，以及一些有深度的文章。

Athenax主要是關於Flink的前瞻性研究的網站。

 

以上四部分就是本次線上直播曠東林老師講述的主要內容，在提問環節有哪些問題呢？咱們一塊兒來看看。

1.請老師講講Flink和最新版Spark的對比？

曠老師：spark streaming和flink是競爭關係，兩個框架都是流處理裏面用的比較多，Flink最大的優點在於保證高吞吐量狀況下的低延遲，以及對複雜的帶有狀態的流的狀態管理能力，還有就是很是靈活窗口的支持。

2.新版spark採用的是timeline db技術嗎？

曠老師：不是的，timeline db在實現上與spark不是同樣的，spark streaming是典型的微批次的流處理框架，其餘的大部分都是基於pipeline的執行架構。

 

 

此次線上直播，相信你們對Flink流式處理有了進一步的認識，在這裏咱們也很感謝曠東林老師的分享。想了解更多更詳細內容的小夥伴們，能夠關注服務號：FMI飛馬網，點擊菜單欄飛馬直播，便可進行學習。