深入理解Apache NIFI Connection

深入理解NIFI Connection

---

編輯人(全網同名)：酷酷的誠 郵箱：[email protected]

---

簡介

NiFi Connection是在兩個已連接的NiFi處理器組件之間臨時保存FlowFiles的位置。每個包含排隊的NiFi FlowFiles的Connection在JVM堆中都會佔一些空間。本文將對Connection進行分析，探究NiFi如何管理在該Connection中排隊的FlowFiles和Connection對堆和性能的影響。

正文

首先看一下下面這張說明圖

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-118tyuwM-1589794601586)(https://nifichina.gitee.io/image/code/connection/1.png)]

NiFi FlowFiles由FlowFile內容和FlowFile屬性/元數據組成。 FlowFile內容永遠不會保存在Connection中。Connection僅將FlowFile屬性/元數據放置在堆中。

“Connection Queue”

"Connection Queue"保存了Connection中所有排隊的FlowFiles的位置。要了解這些排隊的FlowFile如何影響性能和堆使用情況，讓我們首先關注上圖底部的關於"Connection Queue"的剖析。

Connection的整體大小由用戶配置的back Pressure Object Threshold和Back Pressure Data Size threshold設置控制。

Back Pressure Object Threshold 和 Back Pressure Data Size Threshold

此處的Back Pressure Object Threshold默認設置爲10000。

Back Pressure Data Size Threshold默認爲1 GB。

這兩個設置都是軟限制，這意味着可以超過它們。例如，假設上面的默認設置以及已經包含9500個FlowFiles的連接。由於連接尚未達到或超過對象閾值，因此允許運行該連接的處理器運行。如果此隊列上游的處理器在執行時又生成了2000個FlowFiles，則Connection將增長到11500個排隊的FlowFiles。然後，直到Connection再次下降到配置的閾值以下，才允許前一個處理器執行。(這就是背壓機制)

數據大小閾值也是如此。數據大小基於與每個排隊的FlowFile相關聯的內容的累積大小。

現在，我們知道如何控制“connection queue”的整體大小，下面將其分解爲幾個部分：

1. ACTIVE QUEUE：FlowFiles進入到一個Connection中將首先被放置在active隊列中。 之後FlowFiles將繼續被放入到此active隊列，直到該隊列達到全局配置的nifi交換閾值爲止(swap threshold)。active隊列中的所有FlowFiles都保存在堆內存中。從此Connection中使用Flowfile的處理器將始終從active隊列中提取FlowFiles。每個連接的活動隊列的大小由nifi.properties文件中的以下屬性控制

nifi.queue.swap.threshold=20000

交換閾值的增加會增加數據流中每個連接的潛在堆佔用空間。

2. SWAP QUEUE: 根據上述默認設置，一旦Connection達到20000個FlowFiles，進入連接的新FlowFiles將被放置在swap隊列中。swap隊列也保存在堆中，並且硬編碼爲最大10000個FlowFiles。如果活動隊列中的空間已釋放並且不存在交換文件，則交換隊列中的FlowFiles將直接移到活動隊列中。

3. SWAP FILES: 每次swap隊列達到10000個FlowFiles時，會將包含這些FlowFiles的交換文件寫入磁盤上。屆時，新的FlowFiles將再次寫入交換隊列。NIFI可以創建許多交換文件(但設計上建議儘量減少)，上面圖片的Connection包含80000個FlowFiles，堆中將有30000個FlowFiles和5個交換文件(active中有兩萬個，swap中有一萬個，剩下的五萬在交換文件裏)。當活動隊列釋放10000個FlowFiles，因此最早的交換文件將移至活動隊列，直到所有交換文件都消失。交換文件會產生磁盤IO讀寫，在整個數據流中產生大量交換文件，這一定會影響數據流的吞吐量性能。

4. IN-FLIGHT QUEUE: 與上面的3不同，運行中隊列僅在使用此連接的處理器正在運行時才存在。消費處理器將僅從active隊列中提取FlowFiles並將它們放置在運行隊列中，直到成功處理完並且這些FlowFiles已從消費處理器提交到出站Connection爲止。該運行中隊列也保留在堆中。一些處理器一次處理一個FlowFile，另一些處理器處理批量的FlowFile，還有一些處理器可能處理傳入連接隊列中的每個FlowFile。在最後一種情況下，這可能意味着在處理這些FlowFiles時堆使用率很高。上面的使用MergeContent處理器的示例就可能是最後一種情況，假如MergeContent配置的結果爲每次合併90000個FlowFile,那麼這80000個FlowFile都會進入到運行隊列中。

總結

1. 通過限制連接隊列的大小來控制堆的使用（如果可能的話）。 （當然，如果你打算合併40000個FlowFile，則傳入連接中必須有40,000個Flowfile。但是，你可以串聯使用兩個mergeContent處理器，每個處理器合併較小的bundle，並獲得相同的最終結果，而總堆使用量較少。）

2. 使用默認的背壓對象閾值設置，大多數連接上都不會生成交換文件（記住軟限制），這將導致更好的吞吐量性能。

3. 在大多數活動隊列大小和性能的情況下，默認配置的交換閾值20000是一個很好的平衡。對於較小的流量，你可以將其推高，對於較大的流量，你可能需要將其設置爲較低。只需瞭解這是爲了性能而對堆使用情況進行的權衡。但是，如果你的堆用完了，性能將爲零。

額外說一下隊列的優先級排序器

優先級排序器僅對active隊列中當前的FlowFiles有效。由於此active隊列位於JVM堆中，因此基於優先級的重新排序對性能的影響很小。每次新的FlowFile進入連接時，重新評估所有交換的FlowFiles都會影響吞吐量性能。請記住，當在連接上不定義優先級時，將始終獲得最佳吞吐量。

公衆號

關注公衆號 得到第一手文章/文檔更新推送。