ETL工具-nifi干货系列 第一讲 揭开nifi神秘面纱_nifi中bulk controller status

1、nifi简介

Apache NiFi 是基于流程编程概念的数据流系统。它支持强大且可扩展的数据路由、转换和系统中介逻辑的有向图。NiFi具有基于Web的用户界面，用于设计、控制、反馈和监控数据流。它在多个服务质量维度上都具有高度可配置性，例如容忍丢失与保证传递、低延迟与高吞吐量、基于优先级的排队等。NiFi为所有接收到的数据提供了细粒度的数据溯源，包括接收、分叉、连接、克隆、修改、发送以及最终到达配置的最终状态时被丢弃的过程。

2、转换或者job设计工具

nifi是基于web页面直接进行设计，可以很方便的进行团队协作。kettle则是基于本地客户端spoon进行设计。

3、核心概念/术语

DataFlow Manager（数据流管理者）

是指具有权限来添加、移除和修改 NiFi 数据流组件的 NiFi 用户。该角色在 NiFi 中负责管理数据流的组件和操作。

3.1 FlowFile（流文件）

代表 NiFi 中的单个数据单元。一个 FlowFile 由两个组成部分构成：FlowFile 属性和 FlowFile 内容。内容即为 FlowFile 所代表的数据。属性是提供有关数据信息或上下文的特征，它们由键值对组成,所有的 FlowFiles 都具有以下标准属性：

uuid：全局唯一标识符，用于区分系统中的该 FlowFile 与其他 FlowFiles。

filename：人类可读的文件名，在将数据存储到磁盘或外部服务时可能会使用。

path：分层结构的值，在将数据存储到磁盘或外部服务时可以使用，以避免数据存储在单个目录中。

3.2、处理器（Processor），也叫组件，类似于spoon中的步骤

是 NiFi 中的组件，用于监听传入数据、从外部源拉取数据、将数据发布到外部源以及对 FlowFiles 进行路由、转换或提取信息。处理器是 NiFi 工作流的核心组件，它们执行各种数据流操作，包括数据获取、转换、路由和传输。

3.3、关系（Relationship）

在 NiFi 中是指用于表示处理器处理 FlowFile 后的结果的命名标识。每个处理器可以定义零个或多个关系，这些关系的命名通常指示对 FlowFile 进行处理后的结果。处理器在完成对 FlowFile 的处理后，会将其传递（或“转移”）到其中一个关系中。数据流管理器（DFM）可以连接这些关系到其他组件，从而指定在每种潜在处理结果下 FlowFile 应该流向的位置。

通过创建关系，处理器可以将处理结果传递给其他组件，实现数据在流程中不同部分之间的流转和交互。通过正确配置处理器的关系，可以实现灵活、高效的数据流处理逻辑，确保数据能够按照预期的方式流动和处理。

3.4、连接（Connection），类似于spoon中的hop（跳转）

在 NiFi 中用于连接各个组件，构建自动化数据流。数据流管理者（DFM）可以通过从 NiFi 工具栏的组件部分拖拽组件到画布上，然后通过连接连接这些组件。每个连接由一个或多个关系（Relationship）组成。对于绘制的每个连接，DFM 可以确定该连接应该使用哪些关系。这使得数据可以根据其处理结果以不同的方式进行路由。每个连接都包含一个 FlowFile 队列。当将 FlowFile 传输到特定的关系时，它会被添加到与相关连接关联的队列中。

3.5、控制器服务（Controller Service）

是 NiFi 中的扩展点，在用户界面中由数据流管理者（DFM）添加和配置后，会在 NiFi 启动时启动，并为其他组件（例如处理器或其他控制器服务）提供信息。一个常见的由多个组件使用的控制器服务是 StandardSSLContextService。它提供了配置密钥库（keystore）和/或信任库（truststore）属性的能力，一次配置后可以在整个应用程序中重复使用该配置。其核心思想是，控制器服务提供了这些信息，任何处理器需要时都可以使用，而不必在每个处理器中单独配置这些信息。

3.6、报告任务（Reporting Task）

在后台运行，用于提供有关 NiFi 实例中发生的情况的统计报告。数据流管理者（DFM）可以根据需要在用户界面中添加和配置报告任务。常见的报告任务包括 ControllerStatusReportingTask（控制器状态报告任务）、MonitorDiskUsage（监控磁盘使用情况报告任务）、MonitorMemory（监控内存报告任务）和 StandardGangliaReporter（标准 Ganglia 报告器）。

这些报告任务可以提供关于数据流处理情况、系统资源使用情况以及性能指标等方面的统计信息。通过报告任务，数据流管理者可以实时监控和评估 NiFi 实例的健康状态和运行情况，从而及时采取必要的措施以确保系统的稳定性和高效性。

3.7、参数提供者（Parameter Provider）

可以从外部来源向参数上下文（Parameter Context）提供参数。参数提供者的参数可以被获取并应用到所有引用该参数上下文的地方。

参数提供者的作用在于将外部的参数源与应用程序、服务或组件进行解耦，使得参数的管理和配置更加灵活和便捷。通过参数提供者，可以实现将参数从外部统一管理，然后应用到多个上下文中，例如不同的服务实例、环境配置等。

3.8、漏斗（Funnel）

漏斗是 NiFi 组件，用于将多个连接中的数据合并到一个连接中。

3.9、处理组（Process Group），类似于spoon中的子转换或者子job

当数据流变得复杂时，以更高级、更抽象的层次来思考数据流往往是有益的。NiFi允许将多个组件，如处理器（Processors），组合成一个处理组（Process Group）。NiFi用户界面使得数据流管理者（DFM）能够轻松将多个处理组连接成一个逻辑数据流，同时也允许DFM进入处理组以查看和操作处理组内的组件。

3.10、端口（Port），包含输入端口和输出端口

使用一个或多个处理组构建的数据流需要一种方式将处理组连接到其他数据流组件。这可以通过使用端口来实现。数据流管理者可以向处理组添加任意数量的输入端口和输出端口，并适当地命名这些端口。

3.11、远程处理组（Remote Process Group），跨nifi实例使用

就像数据从处理组传输进入和传出一样，有时需要将数据从一个 NiFi 实例传输到另一个实例。虽然 NiFi 提供了许多不同的机制来在系统之间传输数据，但如果要将数据传输到另一个 NiFi 实例，远程处理组通常是最简单的方法。

3.12、公告（Bulletin）：类似于日志

NiFi 用户界面提供了大量关于应用程序当前状态的监控和反馈信息。除了为每个组件提供的滚动统计信息和当前状态外，组件还可以报告公告。每当一个组件报告一个公告时，该组件上会显示一个公告图标。系统级别的公告显示在页面顶部附近的状态栏上。使用鼠标悬停在图标上会显示一个工具提示，显示公告的时间和严重程度（调试、信息、警告、错误），以及公告的消息。所有组件的公告也可以在全局菜单中的公告板页面中查看和过滤。

3.13、模板（Template）

很多时候，数据流由许多可重复使用的子流组成。NiFi 允许数据流管理者选择数据流的一部分（或整个数据流）并创建一个模板。这个模板被赋予一个名称，然后可以像其他组件一样拖动到画布上。因此，可以将几个组件合并在一起，形成一个更大的构建模块，用来创建数据流。这些模板也可以以 XML 格式导出，并导入到另一个 NiFi 实例中，从而实现这些构建模块的共享。

14、flow.xml.gz

DFM（Data Flow Manager，数据流管理者）在 NiFi 用户界面画布上放置的所有内容都实时写入一个名为 flow.xml.gz 的文件中。默认情况下，该文件位于 nifi/conf 目录下。在画布上进行的任何更改都会自动保存到这个文件中，无需用户点击“保存”按钮。此外，当流配置更新时，NiFi会自动在存档目录中创建该文件的备份副本。您可以使用这些存档文件来回滚流配置。要这样做，需要停止 NiFi，用所需的备份副本替换 flow.xml.gz，然后重新启动 NiFi。在集群环境中，停止整个 NiFi 集群，替换其中一个节点的 flow.xml.gz，并重新启动该节点。将其它节点上的 flow.xml.gz 文件删除。确认节点作为单节点集群启动后，启动其它节点。替换的流配置将在整个集群中同步。flow.xml.gz 的名称和位置，以及自动存档行为都是可配置的。