This article is reprinted from: NIFI Terminology — memoordit’s Column — CSDN Blog
-
DataFlow Manager A NiFi user with permission to add, remove, and modify NiFi dataflow components.
-
FlowFile Represents a single piece of data in NiFi. A FlowFile consists of two parts: FlowFile attributes and FlowFile content. The content is the data the FlowFile represents. Attributes are characteristics that provide information or context about the data; they are key-value pairs. All FlowFiles have the following standard attributes:
-
uuid The unique identifier of the FlowFile
-
filename A human-readable filename that can be used when storing data to disk or an external service
-
path A hierarchically structured value that can be used when storing data to disk or an external service, so data isn’t stored in a single directory
-
Processor A NiFi component that listens for incoming data; pulls data from external sources; publishes data to external sources; and routes, transforms, or extracts information from FlowFiles.
-
Relationship Each processor has zero or more relationships defined for it. They are named to represent the result of processing a FlowFile. After a processor finishes with a FlowFile, it routes (or “transports”) it to one of the relationships. The DFM can then connect each relationship to other components, specifying where the FlowFile should flow next under each possible processing result.
-
Connection The DFM builds an automated dataflow by dragging components from the toolbar onto the canvas and connecting them with connections. Each connection consists of one or more relationships. For each connection drawn, the DFM decides which relationships to use for it. This lets data route differently based on processing results. Each connection has a FlowFile queue. When a FlowFile is moved to a specific relationship, it is added to the queue belonging to that connection.
-
Controller Service An extension point that, after being added and configured by the DFM in the UI, starts when NiFi starts and provides information for other components (such as processors or other controller services) to use. StandardSSLContextService is a common controller service used by several components. It provides the ability to configure keystore and/or truststore properties once and reuse that configuration throughout the application. The idea is that, instead of configuring it in every processor that needs it, the controller service is provided to any processor on demand.
-
Reporting Task Runs in the background, providing statistical reports about events happening in the NiFi instance. The DFM adds and configures reporting tasks in the UI as needed. Common ones include ControllerStatusReportingTask, the MonitorDiskUsage reporting task, the MonitorMemory reporting task, and StandardGangliaReporter.
-
Funnel A NiFi component that merges data from multiple connections into a single connection.
-
Process Group When a dataflow gets complex, it’s often useful to divide it at a higher, more abstract level. NiFi lets multiple components (such as processors) be grouped together into a process group. The NiFi UI makes it easy for the DFM to connect multiple process groups in one logical dataflow and to enter a process group to view and work with its components.
-
Port A dataflow built from one or more process groups needs a way to connect process groups to other dataflow components; this is done with ports. The DFM can add any number of input and output ports to a process group and name them appropriately.
-
Remote Process Group Just as data flows in and out of process groups, sometimes data needs to be moved from one NiFi instance to another. Although NiFi offers many mechanisms to move data from one system to another, a remote process group is usually the simplest way to transfer data to another NiFi instance.
-
Bulletin The NiFi UI provides monitoring and feedback about the application’s current state. Besides rolling statistics and the current state of each component, components can also report bulletins. Whenever a component reports a bulletin, a bulletin icon appears on it. System-level bulletins are shown in the status bar near the top of the page. Hovering over the icon shows a tooltip with the bulletin’s time and severity (debug, info, warning, error) and message. All component bulletins can also be viewed and filtered in the bulletin board page in the global menu.
-
Template Often a dataflow consists of many reusable sub-flows. NiFi lets the DFM select a portion of the dataflow (or the whole flow) and create a template. The template is given a name and can then be dragged onto the canvas like any other component. Thus multiple components can be grouped to build larger building blocks, creating a dataflow. These templates can also be exported as XML and imported into another NiFi instance.
-
flow.xml.gz Everything the DFM places on the NiFi UI canvas is written in real time to a file called flow.xml.gz. By default it is in the nifi/conf directory. Any change on the canvas is auto-saved to this file; there is no “Save” button to click. Also, NiFi automatically creates a backup copy of this file in the archive directory on update. You can use these archives to roll back the flow configuration. To do so, stop NiFi, replace flow.xml.gz with the desired backup copy, then restart NiFi. In a cluster, stop the whole NiFi cluster, replace flow.xml.gz on one node, then restart that node and remove flow.xml.gz from the other nodes. Once the node is confirmed up as a single-node cluster, start the other nodes. The replaced flow configuration synchronizes across the cluster. The name and location of flow.xml.gz and the auto-archive behavior are configurable; see the System Administrator’s Guide for details.