隨著大數(shù)據(jù)技術(shù)在各行各業(yè)的廣泛應(yīng)用，要求能對海量數(shù)據(jù)進(jìn)行實(shí)時處理的需求越來越多，同時數(shù)據(jù)處理的業(yè)務(wù)邏輯也越來越復(fù)雜，傳統(tǒng)的批處理方式和早期的流式處理框架也越來越難以在延遲性、吞吐量、容錯能力以及使用便捷性等方面滿足業(yè)務(wù)日益苛刻的要求。

為定襄等地區(qū)用戶提供了全套網(wǎng)頁設(shè)計制作服務(wù)，及定襄網(wǎng)站建設(shè)行業(yè)解決方案。主營業(yè)務(wù)為網(wǎng)站設(shè)計制作、成都做網(wǎng)站、定襄網(wǎng)站設(shè)計，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務(wù)。我們深信只要達(dá)到每一位用戶的要求，就會得到認(rèn)可，從而選擇與我們長期合作。這樣，我們也可以走得更遠(yuǎn)！

在這種形勢下，新型流式處理框架Flink通過創(chuàng)造性地把現(xiàn)代大規(guī)模并行處理技術(shù)應(yīng)用到流式處理中來，極大地改善了以前的流式處理框架所存在的問題。飛馬網(wǎng)于3月13日晚，邀請到大數(shù)據(jù)技術(shù)高級架構(gòu)師—曠東林，在線上直播中，曠老師向我們分享了Flink在諸多方面的創(chuàng)新以及它本身所具有的獨(dú)特能力。

我們主要從以下幾個部分來看：

一.流式處理的背景：

傳統(tǒng)的大數(shù)據(jù)處理方式一般是批處理式的，也就是說，今天所收集的數(shù)據(jù)，我們明天再把今天收集到的數(shù)據(jù)算出來，以供大家使用，但是在很多情況下，數(shù)據(jù)的時效性對于業(yè)務(wù)的成敗是非常關(guān)鍵的。

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

比如說，在***檢測的場景下，我們希望看到的結(jié)果是：一旦有***，我們能及時地作出響應(yīng)。這種情況下，如果按照傳統(tǒng)的批處理方式，是不可能在***的時候?qū)崟r檢測出結(jié)果的。另外，比如說在語音計算中，我們要實(shí)時監(jiān)控各個虛擬器的運(yùn)行狀態(tài)以及出現(xiàn)錯誤時的預(yù)警，這種情況下，也要求我們能夠?qū)崟r監(jiān)控數(shù)據(jù)，并對數(shù)據(jù)產(chǎn)生的各種報警，實(shí)時采取動作。由此，流式處理的必要性就顯得無疑了。

2.流式處理的背景—基礎(chǔ)架構(gòu)

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

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

3.流式處理的背景—評測指標(biāo)

目前的業(yè)界有很多流式處理的框架，在這么多框架中，我們怎樣評價這個流式處理框架的性能呢?有哪些指標(biāo)呢？一般我們會從以下這些方面來考核流式處理框架的能力。

其中“數(shù)據(jù)傳輸?shù)谋Ｕ隙取保侵改懿荒鼙ＷC數(shù)據(jù)被處理并到達(dá)目的地。它有三種可能性：保證至少一次、最多一次、精確一次。大多數(shù)情況下，“保證至少一次”就能滿足業(yè)務(wù)要求，除要求數(shù)據(jù)精確度高的特定場景。

“處理延遲”，在大多數(shù)情況下，流式處理的延遲越低越好，但很多情況下，我們的延遲越低，相應(yīng)付出的代價也越高，“吞吐量”與“處理延遲”就是一對矛盾。吞吐量高，相應(yīng)的延遲就會低，吞吐量低，相應(yīng)的延遲就會高。

“狀態(tài)管理”，我們在實(shí)時變換的過程中，要有與外部的交互，如***檢測，以此來保護(hù)環(huán)境和數(shù)據(jù)的安全。

“容錯能力”和“容錯負(fù)荷”要求當(dāng)流式處理在正常進(jìn)行中，即使有某些機(jī)器掛掉，系統(tǒng)仍能正常運(yùn)行，整個流式處理框架不受影響。

“流控”，也就是流量控制，我們在數(shù)據(jù)傳輸?shù)倪^程中，可能會數(shù)據(jù)突然增多，為了保證系統(tǒng)不至于負(fù)荷過重而崩潰，這時候就需要控制數(shù)據(jù)密度。

“編程復(fù)雜性”，相對而言，API設(shè)計地越高級，編程負(fù)擔(dān)越低。

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

了解流式處理框架的考核標(biāo)準(zhǔn)之后，那么我們?yōu)槭裁催x擇Flink？Flink有哪些優(yōu)勢呢？

“保證帶狀態(tài)計算下的精確一次語義”，對于某些特定的計算而言非常有必要。

一般在流式處理框架中，數(shù)據(jù)的處理一般有兩種方式，一種是按照處理時間來處理數(shù)據(jù)，另一種就是按照事件時間來處理數(shù)據(jù)，“事件時間語義支持”方式更為復(fù)雜。

Flink的API非常高級，在處理流式數(shù)據(jù)的邏輯業(yè)務(wù)中，效率更高。

二．Flink的原理：

了解Flink的背景之后，我們一起來看一看它的原理。

1.概述

Flink的整個組件類似于Spark,它的核心是一個分布式的流式處理框架，在核心之上，有兩套API，一套應(yīng)用于批處理—DataSet API，一套應(yīng)用于流式處理—DataStream API。

從圖中我們可以看到，在兩套API下又有更為高級的庫，而它的整個處理部署方式可以支持本地、集群、云端。

2.基礎(chǔ)架構(gòu)

Flink的整個架構(gòu)和Spark很相似，有三個主要部分。

一個是提交任務(wù)的客戶端—Flink Program；還有作業(yè)的管理器—JobManager，主要負(fù)責(zé)任務(wù)的調(diào)度和狀態(tài)的檢測，以及在整個集群出現(xiàn)故障時進(jìn)行初步管理；最后是任務(wù)管理器—TaskManager，實(shí)現(xiàn)業(yè)務(wù)邏輯的執(zhí)行，負(fù)責(zé)把接受到的任務(wù)運(yùn)行之后，將相應(yīng)的結(jié)果輸出到外部或進(jìn)行外部交互。

在整個過程中，JobManager是不負(fù)責(zé)任務(wù)執(zhí)行的。

3.編程模型

下面我們來看一下Flink的具體編程模型結(jié)構(gòu)。

第一條語句是建立整個Flink運(yùn)行時的環(huán)境，類似于Spark里建立一個上下文。它的主要業(yè)務(wù)邏輯是由指定數(shù)據(jù)源、指定變換邏輯、指定輸出三部分決定的。

指定數(shù)據(jù)源的過程就是nv.addSource，這是指定我們的數(shù)據(jù)到底從哪里來，在這個設(shè)計中，它是從kafka里把數(shù)據(jù)讀出來。在這個事例里面，數(shù)據(jù)流的變換比較簡單，只是把每一行數(shù)據(jù)做一個解析，解析完后獲得另一個數(shù)據(jù)流，就構(gòu)成了 DataStreamevents這個數(shù)據(jù)流。

在這個數(shù)據(jù)流上面，我們做了一個分組：keyBy(“id”)、timeWindow(Time.seconds(10))、apply(new MyWindowAggregationFunction())。我們把整個數(shù)據(jù)處理完之后，得到一個統(tǒng)計數(shù)據(jù)流，指定輸出。

這大致就是整個數(shù)據(jù)流的業(yè)務(wù)邏輯，箭頭下方是數(shù)據(jù)流圖。

示例里面展示的只是部分API，除了上面那些，還有很多操作，我們一起來看下面這張圖片。

“map”就是做一些映射，比如我們把兩個字符串合并成一個字符串，把一個字符串拆成兩個或者三個字符串。

“flatMap”類似于把一個記錄拆分成兩條、三條、甚至是四條記錄。

“Filter”就類似于過濾。

“keyBy”就等效于SQL里的group by。

“reduce”就類似于MapReduce里的reduce。

“join”操作就有點(diǎn)類似于我們數(shù)據(jù)庫里面的join。

“aggregate”是一個聚合操作，如計數(shù)、求和、求平均等。

“connect”實(shí)現(xiàn)把兩個流連成一個流。

“project”操作就類似于SQL里面的snacks。

“repartition”是一個重新分區(qū)操作。

4.執(zhí)行機(jī)制

知道Flink的編程模型之后，那么Flink是怎樣去運(yùn)行這些業(yè)務(wù)邏輯的呢？下面是它的執(zhí)行機(jī)制。

上圖是表現(xiàn)業(yè)務(wù)邏輯的業(yè)務(wù)執(zhí)行圖，F(xiàn)link的執(zhí)行方式類似于管道，它借鑒了數(shù)據(jù)庫的一些執(zhí)行原理，實(shí)現(xiàn)了自己獨(dú)特的執(zhí)行方式。

5.狀態(tài)與容錯

Flink的容錯機(jī)制很特別，我們一起來看一看。

Flink在處理數(shù)據(jù)流時，它的整個數(shù)據(jù)流里面的數(shù)據(jù)分為兩種，一種是本身業(yè)務(wù)發(fā)給的數(shù)據(jù)，還有一種是Flink自己插到數(shù)據(jù)流里面的數(shù)據(jù)。插入的記錄我們叫它barrier，就是柵欄，我們可以把它看成一個表示進(jìn)度的標(biāo)記，標(biāo)記整個數(shù)據(jù)處理的狀態(tài)，它從源頭發(fā)出。從圖中我們可以看到，不管是什么流，它都會產(chǎn)生一個checkpoint barrier。

當(dāng)operator收到柵欄之后，它會把柵欄的狀態(tài)存儲，然后把特定記錄發(fā)出去，到達(dá)第二個operator里面，它又把它的狀態(tài)放到Master里，它就是這樣一步一步去完成的。在這個過程中，如果有一步出現(xiàn)故障，F(xiàn)link會重復(fù)前面的步驟，重新去運(yùn)行，所以不會出現(xiàn)數(shù)據(jù)的丟失和錯誤。

三.Flink的實(shí)踐：

1.示例

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

第一步是初始化框架的運(yùn)行時環(huán)境；第二步是指定數(shù)據(jù)流的數(shù)據(jù)源，示例里指定的是FlinkKafkaConsumer010<>(...)數(shù)據(jù)；第三步是實(shí)現(xiàn)數(shù)據(jù)流的業(yè)務(wù)變換邏輯，這里主要是通過flatmap把一個記錄分成多條記錄，通過filter進(jìn)行過濾，之后按照域名進(jìn)行分組，指定窗口長度，最后指定統(tǒng)計方式，這里的統(tǒng)計方式是計數(shù)；第四步就是對統(tǒng)計出來的數(shù)據(jù)流進(jìn)行指定輸出；最后一步，提交數(shù)據(jù)變換邏輯到框架中經(jīng)編譯后運(yùn)行。

2.監(jiān)控

把這個程序啟動之后，我們就可以看到Flink的監(jiān)控頁面，下面是一些監(jiān)控信息。

我們可以看到，在啟動的Flink集群里面，有80個Task Managers，80個巢，1個空閑的巢數(shù)，紅框點(diǎn)進(jìn)去之后，就是下面的圖片。

監(jiān)控指標(biāo)有很多。

四.總結(jié)與展望：

最后，我們來做一下總結(jié)。以上只是關(guān)于Flink的一些簡單介紹，關(guān)于Flink的內(nèi)存管理、部署、內(nèi)部執(zhí)行機(jī)制等相關(guān)詳細(xì)資料，我們可以通過以下網(wǎng)站進(jìn)行資料查詢。

Apache Flink是有關(guān)Flink開源的官方網(wǎng)站。

Flink-Forward網(wǎng)站主要介紹各家大公司在使用Flink過程中的心得體會，以及Flink本身的發(fā)展提案的一些相關(guān)內(nèi)容。

dataArtisans是Flink背后的一個商業(yè)公司，F(xiàn)link由它發(fā)展起來。它上面的博客包含好多關(guān)于Flinkd的介紹，以及一些有深度的文章。

Athenax主要是關(guān)于Flink的前瞻×××的網(wǎng)站。

以上四部分就是本次線上直播曠東林老師講述的主要內(nèi)容，在提問環(huán)節(jié)有哪些問題呢？我們一起來看看。

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

曠老師：spark streaming和flink是競爭關(guān)系，兩個框架都是流處理里面用的比較多，F(xiàn)link最大的優(yōu)勢在于保證高吞吐量情況下的低延遲，以及對復(fù)雜的帶有狀態(tài)的流的狀態(tài)管理能力，還有就是非常靈活窗口的支持。

2.新版spark采用的是timeline db技術(shù)嗎？

曠老師：不是的，timeline db在實(shí)現(xiàn)上與spark不是一樣的，spark streaming是典型的微批次的流處理框架，其他的大部分都是基于pipeline的執(zhí)行架構(gòu)。

這次線上直播，相信大家對Flink流式處理有了進(jìn)一步的認(rèn)識，在這里我們也很感謝曠東林老師的分享。想了解更多更詳細(xì)內(nèi)容的小伙伴們，可以關(guān)注服務(wù)號：FMI飛馬網(wǎng)，點(diǎn)擊菜單欄飛馬直播，即可進(jìn)行學(xué)習(xí)。