Day2 NiFi 架构与 Component 简介

在前面，我有稍微带到 Apache NiFi 的性质与特点，但除了了解这些之外，我们也要清楚知道这个服务本身的架构，以及它牵扯到有哪些 Component，就趁这时候先来好好地知道一下，这样往後在实作时也比较清楚我们运用到哪些。

Apache NiFi 所需要的 component

一开始，我会先大概讲一下在 Apache NiFi 中最重要的几个 component，我会先有简单的描述来让大家可以容易理解，而往後也会一ㄧ套用到实际的操作来做一个呼应，这里我先带出一张自己设计的图，接着搭配下面的 component 来介绍，图如下：

FlowFile

何谓 FlowFile？我们可以想像是资料中或是File中的一笔Record，甚至是一包资料同时含有很多笔 record，今天假设有一张 Table且其中有100笔资料时，当 NiFi 从中读取时，这100笔 Record 就会在 NiFi 产生100笔 FlowFile，而FlowFile会带有自己的 attribute 和 content，这两个有什麽差异呢？
attribute：可以想像成是 metadata，以 Key-Value 的方式来对 FlowFile 的描述，包含size, path, permission等
content：真实data的内容，可能是 csv, json 等格式。

Processor

可以想像成是一个逻辑处理的 Unit，在 NiFi 中它提供了许多内建的 Processor，可参考官方连结，这可使我们透过设定的方式来产生、处理、转换、输出 FlowFile 等相关操作。
因此，我们可以从上图的橘线，可看到在一个 Pipeline当中，FlowFiles 会经过中间多个 Processor的处理，而第一个 Processor 会被用来产生FlowFiles(ex. 读取DB或 files); 而最後一个通常会是一个落地输出的 Processor(ex. 写入DB 或 files)
P.S 额外补充一下，如果读者们有熟悉 Apache Airflow 的话，Processor 的概念就是类似於 Airflow 的 operator。

Connection

在 NiFi 建立 Data Pipeline 的时候，其实就是透过一连串 Processor 来建置，而Processor 彼此之间会建立一个关系，就称作为 Connection，可从图中看到 Processor之间一定会有个 Connection的存在。
在 Connection 当中，我们可以透过设定来描述该 Connection的定义，以上图中的绿框与红框分别代表着最常见的 Success 和 Failed，若今天有 FlowFiles 是走 Success 的 Connection(上图中的橘线)，也就代表上一个 Processor 是处理成功的。因此，我们可自身建立多种 Connection来决定每一条下游路径的状态与意义为何。
此外，在 Connection中我们还可以设定 Queue 的状态，像是 FIFO 或是 New First等，来缓解当 Connection 中因有太多 Flowfiles 时所导致效能的问题。

Processor Group

Processor Group 通常被用来作为 Processor 的 Module，为 Processors 的集合。最常发生在什麽样的情境呢？会有3种情境需要Processor Group:

1. 今天假如有两个 pipeline，其中有一段的流程是一模一样的，那这时候我们就可以把那一段 Processors 独立做成 Processor Group，而後续若遇到一样的需求时，我就只要拉这个 Processor Group 做串接即可，使用这就不需要再一一建立流程。简单来说，就是视为『Module』的意思。
2. 第二个会用到的情境就是『分专案或部门』为使用，若今天有一个 Team，同时有10个专案需要建立 Data Pipeline，理所当然每一个专案的流程都会不一样，这时候就可以透过 Processor Group 来做专案的划分; 或是有不同 Team 要采用时，也可以利用这个方式来划分不同 Team。
3. 第3种是第2种的延伸，Processor Group 通常也会是一个 User 权限的最小单位，我们可以针对特定 Processor Group 来决定哪些 User 拥有 Write 或 read 的权限

其中情境1，我们可以看到上图的橘框，它被整合在 Pipeline 的其中一环，但其实我们将其放大来看，他就是由一连串的 Processor 组合而成，所以未来若有其他 Pipeline 需要类似的情境时，他仅可拉这个 Processor Group，就不需要再重头拉一次原先 Processor Group 内部的流程。

P.S 额外补充，若对应到 Airflow，其实就是类似於 Subdag 或是 Airflow2.0 的 TaskGroup.

Funnel

用来将多个 source connection 的 组合成单一个 connection，这对於可读性可以提供相当大的帮助，如同上图的紫框，我们可以想像假设有 n 个 Processor 同时要连到同一个 Processor，如果不透过 Funnel 的话，在下游的那一个 Processor 身上会有很多条线，这对於使用者在检视或是Debug是不理想的。

接下来的 Component 介绍，就没有呈现在上图，但也是有一定的重要性。

Controller Service

Controller Service 可以想像成他是一个与第三方对接的 connection，注意不是前面所提到的 connection，而是真的透过网路服务建立的 connection。

当我们选择 NiFi 作为我们 Data Pipeline 的工具时，照理来说就会在服务上建立许多的 Pipeline，甚至有些当中的 Processor 会共同存取同一个 DB 或是 cloud 的服务，如果每一个 Processor 都对其建立太多 connection 的话可能会造成 DB 或 cloud 的问题。

所以此时就可以统一透过 Controller Service 来做一个管理，他可以事先建立好一个与第三方服务的 connection，而当有 Processor 需要做使用的就可以直接套用对应的 Controller Service，一方面不用再重新设定，另一方面可以对目标存取控制好连线数以节省开销。

Reporting Task

Reporting Task 是 NiFi 在做 Monitoring 很重要的角色，他可以将一些** Metrics、Memory & Disk Utilization、以及一些 Monitoring 的资讯发送到出来**，常见应用是发送到 Prometheus, DataDog、Cloudwatch 等第三方服务来做视觉化呈现。

Templates

Templates 通常用於转换环境做使用，假设我有一个既有的 NiFi 在 A 机器上，但这时候我需要转换环境到 B 机器上，此时使用者可以把在 A 机器上所有的 Pipeline 输出成 Templates（为 XML 档），接着再汇入到 B 机器上的 NiFi，就可以在新的环境中继续使用相同的 Pipeline了

这当中的转换是以 Processor Group 作为单位，其中也会把这个底下的所需要用到的参数和设定一起汇出成 templates，所以在环境转换时就会是无痛转移。简单的呈现如下图：

Apache NiFi 基本架构

Apache NiFi是透过 Java 来做开发，所以根据官方文件所提供的架构图，我们可以看见 NiFi 的 Core Component 都位於 JVM 上 :

让我们来从下往上一一介绍

FlowFile Repository

Repository 就是一个存放的地方，在 NiFi 的运作原理会经过压缩与 WAL 方式写入在所属的 instance 上。

因此 FlowFile Repository 就是将 FlowFile 经过我们於 NiFi 所设计的 Data Pipeline 过程中，将其状态做一个保存。举例来说，Pipeline 有 3个 Processor，FlowFile 在每经过一个 Processor 都会将他的状态和 metadata 储存於 FlowFile Repository。

Content Repository

Content 就是指的是 FlowFile 真实的资料内容，Nifi 会将这样的内容透过压缩与加密，再接着存放到自身的 FileSystem，也就是Content Repository。

Provenance Repository

Provenance Repository是用来存放所有 Flowfile 的追踪事件，也就是记录着 FlowFile 从哪里留到目前的 Processor，以及後续以哪一个 Processor 作为下一步流向的标的。主要就是用来追踪 FlowFiles 在每个 Processor 的状态，包含时间、资料变化等

Flow Controller

Flow Controller 你可以想像着他整个 NiFi 的操作核心，所有 Pipeline 的触发与排程，以及对於给 Processor 的相关资源，都是由它来做一个分派与调度。

Web Server

Apache NiFi 有自己的 API 可做使用，所以除了可以在 Web UI 操作之外，我们也可透过呼叫 API 的方式来做设定与执行，但其实 Web UI 也就是基於 Web Server 来根据使用者在 UI 的操作来执行对应的 API。所以这就是一个控制 NiFi API 的地方。

Apache NiFi Clustering 架构

Apache NiFi 除了可以建立成 Single Node 之外，也可以建立成 clustering 的架构，根据官方提供的图参考如下:

但是要注意一点的地方是，NiFi 的 Clustering 与一般我们所想到的像是 EMR, hadoop 的那种 Clustering 不太一样。通常最常见的 Clustering，会有一个 Master(或称 Leader)，去搭配其他的 Worker(或称Follower)。但在 NiFi 的设计中，它是采用『Zero-Master』的 Clustering，也就是每一个在 Clustering 的 Node 都会负责到 Data 的处理，差别在於Data 会被切分到各个 Node 中。

正因为没有一个主要的 Master Node，所以使用者可以从各个 Node 去操作 UI，而 NiFi 就会来同步到其他 Node 中。举例来说，使用者在 A Node 加入一个 Processor，而使用者也可以在同一个 Clustering 中的 B Node 看到刚刚所加入的 Processor。

除了Nifi本身之外，还会一个 Apache Zookeeper 的服务，主要是用来执行故障的处理，而它会选择一个 Node 作为 Coordinator，其他 Node 要向 Coordinator 发送 Heartbeats 和回报状态来确保彼此之间的连线(预设为5秒发送一次)。所以当有一个 Node 没有在时间内回报任何资讯时，Coordinator 就会断开该 Node，直到恢复连线为止。

这边来额外提一下在 NiFi Clustering 中的会用到的名词：

• Coordinator: 由 Zookeeper 决定，主要用来观测目前 Node之间的状况以及决定有哪些 Node 可被加入到 Clustering。
• Primary Node: 每一个 Clustering 会有一个 Primary Node，这个 Node 是唯一可运行 Isolated Processors。一样是由 Zookeeper 做决定，一旦 Primary Node 断线了，Zookeeper 就会马上选择新的 Primary Node 出来。
• Isolated Processors: 一般来说，在 NiFi的所有 Processor他是可以同时运行在所有的Node，但会有一些 Processor 只允许在 Primary Node 做执行，像是 GetSFTP, ListFiles 等这些 Processors，通常都是以『读取』为主的 Processor 居多。我们去思考一个问题，假如现在有一个 Clustering 且有3个 Node，如果每一个 Node 都去读同一份资料，这样资料不就会 Duplicated 了吗？所以同一由一个 Node(也就是 Primary Node)读资料，後续再分散到其他 Node 作处理。

小总结

其实 Nifi Clustering 的设定相对比较复杂，还有一些操作上的细节，所以在这次的系列文当中还是以 Single Node 的模式来去做一个主轴。明天我也会提供 Clustering 的 docker-compose.yml 的参考范例，有兴趣的读者到时候可以再 build 起来玩玩看。

Day2 就大概到这边，让各位了解主要的架构与 Component，明天会带各位介绍另一位 NiFi 的关键角色 - NiFi Registry，他可帮我们对 Data Pipeline 来做版控喔，敬请期待。

Reference

• Apache NiFi Documentation
• Apache Nifi Clustering Configuration