flink 的用途?

? ? ? ?Flink為流處理器開(kāi)辟了新的用武之地，它使流處理架構(gòu)變得完整。它的一大優(yōu)勢(shì)便是，使應(yīng)用程序的構(gòu)建過(guò)程符合自然規(guī)律。為了了解Flink的用途及用法，我們來(lái)看一看令它具有多用途的幾個(gè)核心特點(diǎn)，特別是它如何保障數(shù)據(jù)的正確性。

? ? ? ?1　不同類型的正確性，Flink如何正確地進(jìn)行流處理，以及保障正確性到底意味著什么。人們往往將正確性等同于準(zhǔn)確性——以計(jì)數(shù)為例，計(jì)數(shù)結(jié)果是否“正確”？這個(gè)例子很好地詮釋了正確性，但是正確性的影響因素很多，當(dāng)思考計(jì)算怎樣才能契合需要建模和分析的場(chǎng)景時(shí)，更是如此。換句話說(shuō)，在處理數(shù)據(jù)時(shí)，需要解決這幾個(gè)問(wèn)題：“我需要什么？”“我期望什么？”“我在什么時(shí)候需要得到結(jié)果？”

? ? ? ?2　符合產(chǎn)生數(shù)據(jù)的自然規(guī)律流處理器（尤其是Flink）的正確性體現(xiàn)在計(jì)算窗口的定義符合數(shù)據(jù)產(chǎn)生的自然規(guī)律。舉個(gè)例子，通過(guò)點(diǎn)擊流數(shù)據(jù)追蹤某網(wǎng)站的3個(gè)訪問(wèn)者（圖中的A、B和C）的活動(dòng)。對(duì)于每個(gè)訪問(wèn)者來(lái)說(shuō)，活動(dòng)是不連續(xù)的。在訪問(wèn)時(shí)間段內(nèi)，事件數(shù)據(jù)被收集起來(lái)；當(dāng)訪問(wèn)者起身去喝茶或喝咖啡時(shí)，或者當(dāng)他們因?yàn)槔习鍙纳磉吔?jīng)過(guò)而切換回工作頁(yè)面時(shí)，數(shù)據(jù)就產(chǎn)生了間隙。處理框架能夠?qū)⒃L問(wèn)者行為分析的計(jì)算窗口與實(shí)際的訪問(wèn)時(shí)間段吻合到什么程度？換句話說(shuō)，計(jì)算窗口與會(huì)話窗口吻合嗎？首先讓我們來(lái)看看，當(dāng)訪問(wèn)者行為分析通過(guò)微批處理方法或者固定的計(jì)算窗口來(lái)處理時(shí)，會(huì)發(fā)生什么情況，

如圖所示：（采用微批處理方法時(shí)，很難使計(jì)算窗口（虛線所示）與會(huì)話窗口（長(zhǎng)方形所示）吻合）

? ? ? ?由微批處理方法得到的計(jì)算窗口是人為設(shè)置的，因此很難與會(huì)話窗口吻合。使用Flink的流處理API，可以更靈活地定義計(jì)算窗口，因此這個(gè)問(wèn)題迎刃而解。舉個(gè)例子，開(kāi)發(fā)人員可以設(shè)置非活動(dòng)閾值，若超過(guò)這個(gè)閾值（例如5分鐘），就可以判斷活動(dòng)結(jié)束。下圖展示了這種開(kāi)窗方式。

Flink的流處理能力能夠使計(jì)算窗口與會(huì)話窗口吻合。如圖所示，計(jì)算窗口隨間隙出現(xiàn)。在本例中，相鄰事件之間都有間隙，間隙的時(shí)長(zhǎng)都超過(guò)了預(yù)先定義的閾值Flink能做到這一點(diǎn)的根本原因是，它可以根據(jù)真實(shí)情況設(shè)置計(jì)算窗口。

事件時(shí)間

? ? ? ? 一般而言，流處理架構(gòu)不常采用事件時(shí)間，盡管越來(lái)越多的人這樣做。Flink能夠完美地做到這一點(diǎn)，這在實(shí)現(xiàn)計(jì)算的正確性上非常有用。為了獲得最佳的計(jì)算結(jié)果，系統(tǒng)需要能夠通過(guò)數(shù)據(jù)找到事件發(fā)生的時(shí)間，而不是只采用處理時(shí)間。Flink理解事件時(shí)間的這種能力保障了正確性。2016年，時(shí)任dataArtisans公司應(yīng)用工程總監(jiān)的JamieGrier在OSCON大會(huì)上展示了這一點(diǎn)。他通過(guò)生成的數(shù)據(jù)模擬壓力傳感器的測(cè)量結(jié)果，并寫(xiě)了一個(gè)Flink程序來(lái)計(jì)算以1秒為計(jì)算窗口、每秒內(nèi)正弦波的數(shù)值之和。正確的結(jié)果是0。他比較了用處理時(shí)間劃分窗口和用事件時(shí)間劃分窗口的差別。采用處理時(shí)間時(shí)，結(jié)果總是或多或少地有些偏差；采用事件時(shí)間時(shí)，則總是可以獲得正確的結(jié)果，

如圖:

處理時(shí)間

從處理時(shí)間切換到事件時(shí)間，讓許多計(jì)算工作完成得更好。用處理時(shí)間來(lái)計(jì)算會(huì)導(dǎo)致錯(cuò)誤，用事件時(shí)間則能得到正確的結(jié)果（與其他流處理系統(tǒng)相比，Flink的一個(gè)優(yōu)勢(shì)就是能區(qū)分不同類型的時(shí)間。

發(fā)生故障后仍保持準(zhǔn)確

若想使計(jì)算保持準(zhǔn)確，就必須跟蹤計(jì)算狀態(tài)。如果計(jì)算框架本身不能做到這一點(diǎn)，就必須由應(yīng)用程序的開(kāi)發(fā)人員來(lái)完成這個(gè)任務(wù)。連續(xù)的流處理很難跟蹤計(jì)算狀態(tài)，因?yàn)橛?jì)算過(guò)程沒(méi)有終點(diǎn)。實(shí)際上，對(duì)狀態(tài)的更新是持續(xù)進(jìn)行的。Flink解決了可能影響正確性的幾個(gè)問(wèn)題，包括如何在故障發(fā)生之后仍能進(jìn)行有狀態(tài)的計(jì)算。Flink所用的技術(shù)叫作檢查點(diǎn)（checkpoint），在每個(gè)檢查點(diǎn)，系統(tǒng)都會(huì)記錄中間計(jì)算狀態(tài)，從而在故障發(fā)生時(shí)準(zhǔn)確地重置。這一方法使系統(tǒng)以低開(kāi)銷的方式擁有了容錯(cuò)能力——當(dāng)一切正常時(shí)，檢查點(diǎn)機(jī)制對(duì)系統(tǒng)的影響非常小。值得注意的是，檢查點(diǎn)也是Flink能夠按需重新處理數(shù)據(jù)的關(guān)鍵所在。畢竟，并不是只有在發(fā)生故障之后才會(huì)重新處理數(shù)據(jù)。比如，在運(yùn)行新模型或者修復(fù)bug時(shí)，就可能需要重播并重新處理事件流數(shù)據(jù)。Flink成全了這些操作。　

Flink的檢查點(diǎn)特性在流處理器中是獨(dú)一無(wú)二的，它使得Flink可以準(zhǔn)確地維持狀態(tài)，并且高效地重新處理數(shù)據(jù).

及時(shí)給出所需結(jié)果

Flink能夠滿足低延遲應(yīng)用程序的需要，將這算作一種正確性可能出人意料。我們換個(gè)角度看看：有些計(jì)算結(jié)果或許很準(zhǔn)確，例如求和或者求平均值的結(jié)果，但是如果沒(méi)有及時(shí)地取得結(jié)果，那么很難說(shuō)它們是正確的。舉一個(gè)例子，假設(shè)你在開(kāi)車上班的途中想通過(guò)智能手機(jī)上的實(shí)時(shí)路況查詢及導(dǎo)航應(yīng)用程序選擇一條暢通的路，如果應(yīng)用程序花了2小時(shí)才把查詢結(jié)果發(fā)給你，那么結(jié)果再準(zhǔn)確也是無(wú)用的。哪怕只有5秒鐘的延遲也足以造成麻煩，因?yàn)槟憧赡芤呀?jīng)拐錯(cuò)了彎。可見(jiàn)，在某些情況下，極低的延遲非常重要，它決定了系統(tǒng)能夠及時(shí)地給出所需結(jié)果，而不僅僅是完成計(jì)算。Flink的實(shí)時(shí)且容錯(cuò)的流處理能力可以滿足這類需求。

使開(kāi)發(fā)和運(yùn)維更輕松

Flink與用戶交互的接口也有助于保障正確性。完備的語(yǔ)義簡(jiǎn)化了開(kāi)發(fā)工作，進(jìn)而降低了出錯(cuò)率。此外，Flink還承擔(dān)了跟蹤計(jì)算狀態(tài)的任務(wù)，從而減輕了開(kāi)發(fā)人員的負(fù)擔(dān)，簡(jiǎn)化了編程工作，并提高了應(yīng)用程序的成功率。用同一種技術(shù)來(lái)實(shí)現(xiàn)流處理和批處理，大大地簡(jiǎn)化了開(kāi)發(fā)和運(yùn)維工作。

分階段采用Flink

盡管Flink擁有非常豐富的功能，并能處理極為復(fù)雜的數(shù)據(jù)，但是沒(méi)有必要為了采用Flink而徹底拋棄其他技術(shù)。流處理架構(gòu)可以分步來(lái)實(shí)現(xiàn)。有些公司在引入流處理架構(gòu)時(shí)，先實(shí)現(xiàn)簡(jiǎn)單的應(yīng)用程序，等到熟悉后再推廣。雖然試點(diǎn)應(yīng)用程序的類型完全取決于公司的需求，但是許多公司都有相似的流處理“價(jià)值鏈”。

對(duì)時(shí)間的處理

用流處理器編程和用批處理器編程最關(guān)鍵的區(qū)別在于對(duì)時(shí)間的處理。舉一個(gè)非常簡(jiǎn)單的例子：計(jì)數(shù)。事件流數(shù)據(jù)（如微博內(nèi)容、點(diǎn)擊數(shù)據(jù)和交易數(shù)據(jù)）不斷產(chǎn)生，我們需要用key將事件分組，并且每隔一段時(shí)間（比如一小時(shí)）就針對(duì)每一個(gè)key對(duì)應(yīng)的事件計(jì)數(shù)。這是眾所周知的“大數(shù)據(jù)”應(yīng)用，與MapReduce的詞頻統(tǒng)計(jì)例子相似。

采用批處理架構(gòu)和Lambda架構(gòu)

計(jì)數(shù)盡管看起來(lái)簡(jiǎn)單，但是大規(guī)模的計(jì)數(shù)任務(wù)在實(shí)踐中出人意料地困難。當(dāng)然，計(jì)數(shù)無(wú)處不在。針對(duì)聯(lián)機(jī)分析處理多維數(shù)據(jù)集的聚合或其他操作，都可以簡(jiǎn)單地歸結(jié)為計(jì)數(shù)。圖41展示了如何采用傳統(tǒng)的批處理架構(gòu)實(shí)現(xiàn)計(jì)數(shù)任務(wù)。

在該架構(gòu)中，持續(xù)攝取數(shù)據(jù)的管道每小時(shí)創(chuàng)建一次文件。這些文件通常被存儲(chǔ)在HDFS或MapRFS等分布式文件系統(tǒng)中。像ApacheFlume這樣的工具可以用于完成上述工作。由調(diào)度程序安排批處理作業(yè)（如MapReduce作業(yè)）分析最近生成的一個(gè)文件（將文件中的事件按key分組，計(jì)算每個(gè)key對(duì)應(yīng)的事件數(shù)），然后輸出計(jì)數(shù)結(jié)果。對(duì)于每個(gè)使用Hadoop的公司來(lái)說(shuō)，其集群都有多個(gè)類似的管道。這種架構(gòu)完全可行，但是存在以下問(wèn)題。太多獨(dú)立的部分。為了計(jì)算數(shù)據(jù)中的事件數(shù)，這種架構(gòu)動(dòng)用了太多系統(tǒng)。每一個(gè)系統(tǒng)都有學(xué)習(xí)成本和管理成本，還可能存在bug。對(duì)時(shí)間的處理方法不明確。假設(shè)需要改為每30分鐘計(jì)數(shù)一次。這個(gè)變動(dòng)涉及工作流調(diào)度邏輯（而不是應(yīng)用程序代碼邏輯），從而使DevOps問(wèn)題與業(yè)務(wù)需求混淆。預(yù)警。假設(shè)除了每小時(shí)計(jì)數(shù)一次外，還需要盡可能早地收到計(jì)數(shù)預(yù)警（比如在事件數(shù)超過(guò)10時(shí)預(yù)警）。為了做到這一點(diǎn)，可以在定期運(yùn)行的批處理作業(yè)之外，引入Storm來(lái)采集消息流（Kafka或者M(jìn)apRStreams）。Storm實(shí)時(shí)提供近似的計(jì)數(shù)，批處理作業(yè)每小時(shí)提供準(zhǔn)確的計(jì)數(shù)。但是這樣一來(lái)，就向架構(gòu)增加了一個(gè)系統(tǒng)，以及與之相關(guān)的新編程模型,上述架構(gòu)叫作Lambda架構(gòu).

Lambda架構(gòu)用定期運(yùn)行的批處理作業(yè)來(lái)實(shí)現(xiàn)應(yīng)用程序的持續(xù)性，并通過(guò)流處理器獲得預(yù)警。流處理器實(shí)時(shí)提供近似結(jié)果；批處理層最終會(huì)對(duì)近似結(jié)果予以糾正亂序事件流。在現(xiàn)實(shí)世界中，大多數(shù)事件流都是亂序的，即事件的實(shí)際發(fā)生順序（事件數(shù)據(jù)在生成時(shí)被附上時(shí)間戳，如智能手機(jī)記錄下用戶登錄應(yīng)用程序的時(shí)間）和數(shù)據(jù)中心所記錄的順序不一樣。這意味著本屬于前一批的事件可能被錯(cuò)誤地歸入當(dāng)前一批。批處理架構(gòu)很難解決這個(gè)問(wèn)題，大部分人則選擇忽視它。批處理作業(yè)的界限不清晰。在該架構(gòu)中，“每小時(shí)”的定義含糊不清，分割時(shí)間點(diǎn)實(shí)際上取決于不同系統(tǒng)之間的交互。充其量也只能做到大約每小時(shí)分割一次，而在分割時(shí)間點(diǎn)前后的事件既可能被歸入前一批，也可能被歸入當(dāng)前一批。將數(shù)據(jù)流以小時(shí)為單位進(jìn)行分割，實(shí)際上是最簡(jiǎn)單的方法。假設(shè)需要根據(jù)產(chǎn)生數(shù)據(jù)的時(shí)間段（如從用戶登錄到退出）生成聚合結(jié)果，而不是簡(jiǎn)單地以小時(shí)為單位分割數(shù)據(jù)，則用上面的圖的架構(gòu)無(wú)法直接滿足需求。

采用流處理架構(gòu)計(jì)數(shù)

當(dāng)然有更好的辦法來(lái)對(duì)事件流進(jìn)行計(jì)數(shù)。如你所想，計(jì)數(shù)是流處理用例，上一節(jié)只是使用定期運(yùn)行的批處理作業(yè)來(lái)模擬流處理。此外，必須把各種系統(tǒng)耦合在一起。下圖展示了采用流處理架構(gòu)的應(yīng)用程序模型。

通過(guò)流處理架構(gòu)實(shí)現(xiàn)應(yīng)用程序的持續(xù)性。水平圓柱體表示消息傳輸系統(tǒng)（Kafka或MapRStreams）。消息傳輸系統(tǒng)為負(fù)責(zé)處理所有數(shù)據(jù)的流處理器（在本例中是Flink）提供流數(shù)據(jù)，產(chǎn)生的結(jié)果既是實(shí)時(shí)的，也是正確的事件流由消息傳輸系統(tǒng)提供，并且只被單一的Flink作業(yè)處理，從而以小時(shí)為單位計(jì)數(shù)和預(yù)警（后者可選）。這種方法直接解決了上一節(jié)提到的所有問(wèn)題。Flink作業(yè)的速度減慢或者吞吐量激增只會(huì)導(dǎo)致事件在消息傳輸系統(tǒng)中堆積。以時(shí)間為單位把事件流分割為一批批任務(wù)（稱作窗口），這種邏輯完全嵌入在Flink程序的應(yīng)用邏輯中。預(yù)警由同一個(gè)程序生成，亂序事件由Flink自行處理。要從以固定時(shí)間分組改為根據(jù)產(chǎn)生數(shù)據(jù)的時(shí)間段分組，只需在Flink程序中修改對(duì)窗口的定義即可。此外，如果應(yīng)用程序的代碼有過(guò)改動(dòng)，只需重播Kafka主題，即可重播應(yīng)用程序。采用流處理架構(gòu)，可以大幅減少需要學(xué)習(xí)、管理和編寫(xiě)代碼的系統(tǒng)。Flink應(yīng)用程序用來(lái)計(jì)數(shù)的代碼非常簡(jiǎn)單，如下所示。
DataStream<LogEvent>stream=env

//通過(guò)Kafka生成數(shù)據(jù)流

.addSource(newFlinkKafkaConsumer(...))

//分組

.keyBy("country")

//將時(shí)間窗口設(shè)為60分鐘

.timeWindow(Time.minutes(60))

//針對(duì)每個(gè)時(shí)間窗口進(jìn)行操作

.apply(newCountPerWindowFunction());

流處理區(qū)別于批處理最主要的兩點(diǎn)是：流即是流，不必人為地將它分割為文件；時(shí)間的定義被明確地寫(xiě)入應(yīng)用程序代碼（如以上代碼的時(shí)間窗口），而不是與攝取、計(jì)算和調(diào)度等過(guò)程牽扯不清。流處理系統(tǒng)中的批處理第1章討論過(guò)微批處理，它是介于流處理和批處理之間的方法。實(shí)際上，微批處理的含義取決于具體情況。從某種角度來(lái)說(shuō)，圖41中的批處理架構(gòu)也可以稱為微批處理架構(gòu)，前提是文件足夠小。StormTrident是這樣實(shí)現(xiàn)微批處理的：它先創(chuàng)建一個(gè)大的Storm事件，包含固定數(shù)量的子事件；聚合在一

?

總結(jié)

以上是生活随笔為你收集整理的flink 的用途 场景的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。