Day7 NiFi - Connection

前面我们介绍完了 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用户指南