流式處理新秀Flink原理與實(shí)踐-創(chuàng)新互聯(lián)

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

創(chuàng)新互聯(lián)服務(wù)項(xiàng)目包括東平網(wǎng)站建設(shè)、東平網(wǎng)站制作、東平網(wǎng)頁(yè)制作以及東平網(wǎng)絡(luò)營(yíng)銷策劃等。多年來(lái)，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢(shì)、行業(yè)經(jīng)驗(yàn)、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機(jī)構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，東平網(wǎng)站推廣取得了明顯的社會(huì)效益與經(jīng)濟(jì)效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到東平省份的部分城市，未來(lái)相信會(huì)繼續(xù)擴(kuò)大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！

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

我們主要從以下幾個(gè)部分來(lái)看：

一.流式處理的背景：

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

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

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

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

我們來(lái)看一下流式處理的基本框架。

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

3.流式處理的背景—評(píng)測(cè)指標(biāo)

目前的業(yè)界有很多流式處理的框架，在這么多框架中，我們?cè)鯓釉u(píng)價(jià)這個(gè)流式處理框架的性能呢?有哪些指標(biāo)呢？一般我們會(huì)從以下這些方面來(lái)考核流式處理框架的能力。

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

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

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

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

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

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

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

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

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

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

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

二．Flink的原理：

了解Flink的背景之后，我們一起來(lái)看一看它的原理。

1.概述

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

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

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

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

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

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

3.編程模型

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

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

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

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

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

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

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

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

“Filter”就類似于過(guò)濾。

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

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

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

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

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

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

“repartition”是一個(gè)重新分區(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ù)庫(kù)的一些執(zhí)行原理，實(shí)現(xiàn)了自己獨(dú)特的執(zhí)行方式。

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

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

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

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

三.Flink的實(shí)踐：

1.示例

我們來(lái)看一下具體的示例。

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

2.監(jiān)控

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

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

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

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

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

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

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

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

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

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

1.請(qǐng)老師講講Flink和最新版Spark的對(duì)比？

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

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

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

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

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內(nèi)外云服務(wù)器15元起步，三天無(wú)理由+7*72小時(shí)售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國(guó)服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡(jiǎn)單易用、服務(wù)可用性高、性價(jià)比高”等特點(diǎn)與優(yōu)勢(shì)，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場(chǎng)景需求。

本文題目：流式處理新秀Flink原理與實(shí)踐-創(chuàng)新互聯(lián)
瀏覽地址：http://muchs.cn/article30/ceehso.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站改版、域名注冊(cè)、服務(wù)器托管、動(dòng)態(tài)網(wǎng)站、響應(yīng)式網(wǎng)站、商城網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)