前面我們介紹完了 Processor 之後，一個完整的 Data Pipeline 就是要將這些 Processor 給串連起來，此時就需要理解今天的主角 - Connection

什麼是 Connection？

從上圖紅框我們就可看到 Connection 的使用情態，除了單純將 Processors 彼此之間建立起來之外，他其實還有幾個重要的特性也要知道：

Where does flowfiles go

Connection 通常代表著『這條路』的狀態，最常見的有 Success, Failed，意涵著如果前一個 Procesor 處理狀態是 Success，那 FlowFiles 就會走 Success 的 Connection; 反之亦然。

其實有些『Processor』會有預設的 Connection，可以在 Processor 的 setting 去看到，這部分在前一篇有去提到過他。然而有時候我們也可以自己增長我們想要的 Connection 狀態，以下圖紅框為例：

在紅框中，可以看到是由我透過 『RouteOnAttribute』這個 Processor 來自定義的三種狀態的 Connection，分別是 region_tw, region_jp, region_usa，這用來判斷若流下來的 FlowFiles attributes 內的 region 若是 tw, jp, usa 就可以留到對應的 Connection 以及底下的 Processor 來做對應的資料處理。

詳細的操作後續在講 NEL 會更細節地教大家來設定，所以這部分就是讓讀者們知道 Connection 可以決定 FlowFiles 的目的地。

接下來的介紹可對 Connection 點選右鍵且選擇 config 就可看到相關設定。

Back Pressure

進來到 Connection 的 Setting 之後，我們可以看到上圖中紅框的設定 - Back Pressure。這是什麼用途呢？簡單來說，他是用來緩減且避免下一個 Processor 因一次接受到太多 FlowFiles 數量而導致錯誤或效率問題。

假入現在有一個場景，長得像下面這樣：

processor A  -- connection c1 --> processor B

其中由於 processor B 可能要做許多邏輯上的處理，可能一次無法接受到太多 FlowFiles，此時 connection c1 就可以透過 『Back Pressure』 來當它暫時 queue 住後續的 FlowFiles，等到 processor B 處理完先前的 FlowFiles 之後再從這個 connection c1 繼續拿資料。

經過上面的簡單下例子，其實不難發現， Connection 同時兼具『queue』的概念，而下游的 Processor 可向相成類似於 Consumer 的角色。

而 Connection 也有他的限制，並不是可以queue 住無限的 FlowFiles，所以通常會有兩個設定(上圖紅框也可以看到):

• Object Threshold
  就是 FlowFiles 數量的限制，預設是 10000 ，也就是這個 Connection 最多可以有 10000 個 FlowFiles 的 Buffer，使用者可以根據自己的情境去設定。
• Size Threshold
  就是目前在 Connection FlowFiles 加總 Size 大小，預設為 1GB，這也是一種 Buffer 的設計。

通常我們會選擇 Object Threshold 來設定比較多，但就因場景而異來設定適當的條件。

Load Balance Strategy

接著介紹 Load Balance，這通常需要設定的場景是『Cluster』 的 NiFi。正常來說，我們會需要做到 Cluster的架構，一定是 FlowFiles 會很多，期望透過更多的 Node 來區消耗當中的處理，所以這時候就要去選擇對應的 load balance 的機制。下面是可設定四種類:

• Do not load balance
  這是 default 值，就是不在 node 之間做 load balance。但如果會有大量 FlowFiles 的話，建議不要選擇這個，否則可能會造成有節點 loading 太重，而有其他 node 閒置的狀態。

• Partition by attributes
  根據 FlowFiles attributes 的某一個 key 值決定要去哪一個 node。具有相同Attribute值的所有FlowFile將發送到 Cluster 中的同一節點。

• Round robin
  FlowFiles 將以輪流詢問的方式指派到 Cluster 中的 node。簡單來說，假設有 3 個 node，分別是 a, b, c，Connection 就會以 a -> b -> c -> a... 這樣的順序去詢問，直到可以接受的 node。

• Single node
  將所有 FlowFiles 將發送到 Cluster 中的單一個node。它們被分派到哪個 node 是不可配置的，而是由 NiFi 來依據當時的狀況來決定。

Load Balance Compression

當我們選擇完 Load Balance Strategy 之後，只要是非 Do not load balance 這個選項，通常會在跳出一個 Load Balance Compression 的設定，這是用來在做 Load Balance 的時候決定 FlowFiles 是否要先做壓縮再做傳送，會有 3 種方式：

• Do not compress
  這是 Dafault 設定，不會對 FlowFiles 做任何壓縮。

• Compress attributes only
  只壓縮 FlowFiles 的 attributes，不會對 content 做壓縮。

• Compress attributes and content
  直接壓縮 FlowFiles 的 attributes 和 content。

通常如果 attributes 很多 key 時且沒有 content 的話，就選擇第二種; 若 attributes 和 content 都很多的話建議選擇第三種。

Available Prioritizers

在前面的舉例有提到，Connection 同時兼具 Queue 的性質，正常來說 Queue 都採用 FIFO(First-In-First-Out) 的性質居多，但在 NiFi Connection 我們可選擇處理順序，從上圖紅框可看到有 4 個種類:

• FirstInFirstOutPrioritizer
  先處理首先到達 Connection 的FlowFiles。

• NewestFlowFileFirstPrioritizer
  先處理最新的FlowFiles，注意最新的 FlowFiles 不代表會是最後到達 Connection，有可能因為網路問題等造成提前。而 FlowFiles 會帶有產生的 timestamp，來知道它產生的時間。

• OldestFlowFileFirstPrioritizer
  先處理最舊的FlowFiles。這是在沒有選擇 Priority 的情況下使用的預設方案。

• PriorityAttributePrioritizer
  提取名爲 priority 的 attributes。將首先處理具有最低優先級值的那個。用這個要特別注意 FlowFile 一定要帶有 priority 這個 attributes，而 value 可以是 A-100的範圍，ex. a 比 z 優先處理; 1 比 9 優先處理。

就我目前的經驗，我是還沒有去動過這邊的設定，頂多選擇 FirstInFirstOutPrioritizer 而已，所以其他適合的場景可能等未來有需要才會去使用。倘若你真的要指定，記得拖拉你要的 Stategy 到下面的 Selected Prioritizers。

小總結

以上就是對於 Connection 的簡單介紹，但就接下來的系列文介紹不會對於這邊做太多的改動，因為採用的範例資料也不會太多。但未來讀者們若要使用到企業或是 Production 的環境時，此時這邊的設定就格外重要，因為這也會影響到整個 Pipeline 的 Performance 和處理順序。

最後，明天要跟各位介紹『Processor Group』，來把一些東西給模組化吧。

Reference

• Apache NiFi Document
• Apache NiFi用戶指南