flink 的用途?

? ? ? ?Flink為流處理器開辟了新的用武之地，它使流處理架構變得完整。它的一大優勢便是，使應用程序的構建過程符合自然規律。為了了解Flink的用途及用法，我們來看一看令它具有多用途的幾個核心特點，特別是它如何保障數據的正確性。

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

? ? ? ?2　符合產生數據的自然規律流處理器（尤其是Flink）的正確性體現在計算窗口的定義符合數據產生的自然規律。舉個例子，通過點擊流數據追蹤某網站的3個訪問者（圖中的A、B和C）的活動。對于每個訪問者來說，活動是不連續的。在訪問時間段內，事件數據被收集起來；當訪問者起身去喝茶或喝咖啡時，或者當他們因為老板從身邊經過而切換回工作頁面時，數據就產生了間隙。處理框架能夠將訪問者行為分析的計算窗口與實際的訪問時間段吻合到什么程度？換句話說，計算窗口與會話窗口吻合嗎？首先讓我們來看看，當訪問者行為分析通過微批處理方法或者固定的計算窗口來處理時，會發生什么情況，

如圖所示：（采用微批處理方法時，很難使計算窗口（虛線所示）與會話窗口（長方形所示）吻合）

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

Flink的流處理能力能夠使計算窗口與會話窗口吻合。如圖所示，計算窗口隨間隙出現。在本例中，相鄰事件之間都有間隙，間隙的時長都超過了預先定義的閾值Flink能做到這一點的根本原因是，它可以根據真實情況設置計算窗口。

事件時間

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

如圖:

處理時間

從處理時間切換到事件時間，讓許多計算工作完成得更好。用處理時間來計算會導致錯誤，用事件時間則能得到正確的結果（與其他流處理系統相比，Flink的一個優勢就是能區分不同類型的時間。

發生故障后仍保持準確

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

Flink的檢查點特性在流處理器中是獨一無二的，它使得Flink可以準確地維持狀態，并且高效地重新處理數據.

及時給出所需結果

Flink能夠滿足低延遲應用程序的需要，將這算作一種正確性可能出人意料。我們換個角度看看：有些計算結果或許很準確，例如求和或者求平均值的結果，但是如果沒有及時地取得結果，那么很難說它們是正確的。舉一個例子，假設你在開車上班的途中想通過智能手機上的實時路況查詢及導航應用程序選擇一條暢通的路，如果應用程序花了2小時才把查詢結果發給你，那么結果再準確也是無用的。哪怕只有5秒鐘的延遲也足以造成麻煩，因為你可能已經拐錯了彎。可見，在某些情況下，極低的延遲非常重要，它決定了系統能夠及時地給出所需結果，而不僅僅是完成計算。Flink的實時且容錯的流處理能力可以滿足這類需求。

使開發和運維更輕松

Flink與用戶交互的接口也有助于保障正確性。完備的語義簡化了開發工作，進而降低了出錯率。此外，Flink還承擔了跟蹤計算狀態的任務，從而減輕了開發人員的負擔，簡化了編程工作，并提高了應用程序的成功率。用同一種技術來實現流處理和批處理，大大地簡化了開發和運維工作。

分階段采用Flink

盡管Flink擁有非常豐富的功能，并能處理極為復雜的數據，但是沒有必要為了采用Flink而徹底拋棄其他技術。流處理架構可以分步來實現。有些公司在引入流處理架構時，先實現簡單的應用程序，等到熟悉后再推廣。雖然試點應用程序的類型完全取決于公司的需求，但是許多公司都有相似的流處理“價值鏈”。

對時間的處理

用流處理器編程和用批處理器編程最關鍵的區別在于對時間的處理。舉一個非常簡單的例子：計數。事件流數據（如微博內容、點擊數據和交易數據）不斷產生，我們需要用key將事件分組，并且每隔一段時間（比如一小時）就針對每一個key對應的事件計數。這是眾所周知的“大數據”應用，與MapReduce的詞頻統計例子相似。

采用批處理架構和Lambda架構

計數盡管看起來簡單，但是大規模的計數任務在實踐中出人意料地困難。當然，計數無處不在。針對聯機分析處理多維數據集的聚合或其他操作，都可以簡單地歸結為計數。圖41展示了如何采用傳統的批處理架構實現計數任務。

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

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

采用流處理架構計數

當然有更好的辦法來對事件流進行計數。如你所想，計數是流處理用例，上一節只是使用定期運行的批處理作業來模擬流處理。此外，必須把各種系統耦合在一起。下圖展示了采用流處理架構的應用程序模型。

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

//通過Kafka生成數據流

.addSource(newFlinkKafkaConsumer(...))

//分組

.keyBy("country")

//將時間窗口設為60分鐘

.timeWindow(Time.minutes(60))

//針對每個時間窗口進行操作

.apply(newCountPerWindowFunction());

流處理區別于批處理最主要的兩點是：流即是流，不必人為地將它分割為文件；時間的定義被明確地寫入應用程序代碼（如以上代碼的時間窗口），而不是與攝取、計算和調度等過程牽扯不清。流處理系統中的批處理第1章討論過微批處理，它是介于流處理和批處理之間的方法。實際上，微批處理的含義取決于具體情況。從某種角度來說，圖41中的批處理架構也可以稱為微批處理架構，前提是文件足夠小。StormTrident是這樣實現微批處理的：它先創建一個大的Storm事件，包含固定數量的子事件；聚合在一

?

總結

以上是生活随笔為你收集整理的flink 的用途 场景的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。