NiFi如何工作

什么是Apache NiFi

Apache NiFi官网对NiFi的定义如下：

An easy to use, powerful, and reliable system to process and distribute data.

这个理解这段描述？

定义NiFi

Process and distribute data
处理和分发数据这是NiFi的主旨. NiFi在系统之间移动数据，提供工具处理数据。

NiFi客户处理各种各样的数据源和数据格式。可以由一个数据源中获取数据，对数据进行计算、转化，把数据推送到其他的数据源进行存储。
NiFi鸟瞰 — NiFi由多个数据源获取数据,对数据进行充实和转化，最后存储到一个key-value存储（例如redis）

易用
多个处理器(Processors)被连接器（Connector）的箭头链接在一起，创建了数据流程。NiFi提供fbp（基于流编程）的体验。

Nifi makes it possible to understand, at a glance, a set of dataflow operations that would take hundreds of lines of source code to implement.

NiFi使整个数据流程非常易于理解，一目了然。要实现一个数据流程经常需要数百行甚至更多的代码来实现。

如下图的数据管道:

使用nifi实现这个数据管道，只要在NiFi的用户姐main中，拖拽三个组件到画布，再拖拽两个链接将它们关联到一起，简单的配置一下就完成了。这个过程只需要几分钟。代码实现可能需十几小时甚至几十小时来完成。

如果编写代码来做同样的功能，看起来需要几百行代码，才能得到同样的结果。

您不会像使用fbp模式那样通过代码捕获管道的本质. NiFi在构建数据管道方面非常有表现力，它的设计初衷如此。

强大
NiFi提供了许多开箱即用的Processor（在1.12.1版本有288个）。在使用NiFi进行数据流程设计时，相当于站在了巨人的肩膀上。 这些标准Processor可以处理您可能遇到的绝大多数用例。

NiFi是高度并发的，并将并发的复杂性封装在自己内部。Processor为您提供了高级抽象，它隐藏了并行编程固有的复杂性。 Processor同步运行，可以为它分配多个线程来应对负载。

并发编程像一个潘多拉魔盒，需要开发者有丰富的经验，大多数时候，我们并不想打开它。 NiFi方便地保护了数据流程，免受并发复杂性的影响。

可靠
NiFi背后的理论并不是新的，它有坚实的理论基础。它的模型与 SEDA类似。

SEDA(Staged Event-Driven Architecture)的核心思想是把一个请求处理过程分成几个Stage，不同资源消耗的Stage使用不同数量的线程来处理，Stage间使用事件驱动的异步通信模式。

对于数据流系统，要解决的主要主题之一是可靠性。您要确保数据能够送达某处。

NiFi通过多种机制全面的跟踪系统状态，来实现了高度的可靠性。这些机制是可配置的，可以根据需求在延迟和吞吐量之间进行适当的权衡。

NiFi利用血缘和出处特征来跟踪每条数据的历史记录。这使得NiFi具有追踪每条数据发生什么转变的能力。

Apache Nifi提出的数据血缘解决方案被证明是审计数据管道的出色工具。Apache Spark也采用数据血缘解决方案保证数据的可靠性。

为什么使用NiFi?

再次重复大数据的4V特性

• 大量 — 包括采集、存储和计算的量都非常大。大数据的计量单位由TB、PB（1000）个T、EB（100万个T）、ZB（10亿个T）不断发展。
• 多样 — 种类和来源多样化。包括结构化、半结构化和非结构化数据，具体表现为网络日志、音频、视频、图片、地理位置信息等等，多类型的数据对数据的处理能力提出了更高的要求
• 高速 — 数据增长速度快，处理速度也快，时效性要求高
• 准确性 — 数据的准确性和可信赖度，即数据的质量

NiFi无缝地从多个数据源提取数据，并提供了处理不同模式数据的机制。 因此，当数据的“多样性”较高时，它会发挥价值。

如果数据具有“低可靠性”，则Nifi。 由于它提供了多个Processor来清理和格式化数据。

通过其配置选项，Nifi可以解决各种量/速度情况。

应用场景原来越多

新法规，物联网的兴起及其生成的数据流程，更突显了诸如Apache NiFi之类的工具的重要性。

• 微服务很新潮。在那些松散耦合的服务中，服务之间的数据就是契约。 Nifi是在这些服务之间路由数据的可靠方法。
• 物联网将大量数据带到云中。从边缘到云的数据摄取和验证带来了许多新挑战，NiFi可以有效应对这些挑战（主要通过[MiniFi]，这是针对边缘设备的NiFi子项目）。
• 制定了新的准则和法规促使大数据经济重新调整。在日益增加的监控范围内，对于企业来说，对其数据管道有清晰的总览非常重要。例如，NiFi数据血缘可能有助于遵守法规。

抽丝剥茧看NiFi

NiFi开箱

启动NiFi，打开它的主界面，数据流程的设计，运行，管理，监控都在这个界面上了。

在NiFi中，组装一个数据流程需要若干个Processor用来处理数据，需要若干个Connection用来把Processor链接到一起。Processor是处理数据的站点，数据进站被加工处理后出站。Connection是连接站点的公路，数据通过Connection在站点之间间流动，同时还起到缓存的作用。在NiFi界面的画布上，通过拖拽连接起来，构建数据流。前面数据流程的例子，由三个processor和两天连接它们的connection构成。

NiFi的术语

要是使用NiFi，首先要理解它的关键术语以及术语背后的逻辑。

如下图所示：

黑盒子被称为Processor，它们通过名为Connection队列交换名为FlowFile的数据。最后由FlowContoller负责管理这些组件和资源。

简单看看它们是如何工作的

FlowFile

在NiFi中，FlowFile是数据的封装，在数据管道中流动。

FlowFile由两部分组成:

• Attributes(属性), 是一组键值对. 例如, 文件名, 文件路径, 和唯一标识是标准属性。
• Content(内容), 一个字节流的引用，是实际需要处理的数据.

FlowFile并不自己持有数据，这对吞吐量由非常大的益处。代替方案是，FlowFile有一个指针，指向存储在本地存储(Content Repository)里的数据。

为了访问内容，FlowFile从内容存储库中读取数据。 FlowFile会跟踪内容所在文件的确切偏移量，并将其取回到FlowFile。

绝大部分Processor都不需要访问FlowFile的内容来执行其操作。例如，合并两个FlowFiles的内容不需要将其内容加载到内存中。

当Processor修改FlowFile的内容时，会保留先前的数据。 NiFi采用“写时复制的策略(copies on write)”， 它将修改后的内容写到一个新的位置，并更新FlowFile的指针指向新Content的位置。 原始内容信息保留在内容存储库中。

考虑一个压缩FlowFile内容的Processor的例子。 原始内容保留在内容存储库中，并为压缩内容在新的位置创建一个新的条目。内容存储库最终将对压缩内容的引用返回 FlowFile更新指针，指向压缩数据。 下图总结了带有压缩FlowFiles内容的Processor运行过程。

可靠性

NiFi声称是可靠的，实际上如何？ 当前使用的所有FlowFiles的属性以及对其内容的引用都存储在“FlowFile Repository”中。在数据管道的每个步骤，在修改DataFlow之前，首先要将对FlowFile的修改记录在WAL中的“FlowFile Repository”中。

对于系统中当前存在的每个FlowFile，FlowFile存储库存储存储了：

• FlowFile属性

• 指向位于FlowFile存储库中的FlowFile内容的指针

• FlowFile的状态。 例如：Flowfile此时属于哪个队列。

FlowFile repository

“FlowFile Repository” 存储了数据流程的最新状态，如果系统失败可以讲系统恢复到最后的状态。

NiFi提供了另一个工具来跟踪流中所有FlowFiles的完整历史记录：“Provenance Repository”。

Provenance Repository

每次修改FlowFile时，NiFi都会在此时获取FlowFile及其上下文的快照, NiFi中此快照的名称是"Provenance Event(来源事件)"。 “Provenance Repository(来源存储库)”会记录"Provenance Event(来源事件)"。

“Provenance” 使我们能够追溯数据血缘并为在NiFi中处理的每条信息建立完整的监管链。

处理提供完成的数据血缘外，“Provenance Repository”也提供了在任何时间点回放数据的能力

“FlowFile Repository” vs. "Provenance Repository"

这两个存储库由相似的设计, 但是它们解决的问题是不同的.

• “FlowFile repository”是日志包含了在数据流程中活跃的FlowFiles的最后状态，是整个数据流程的最后的快照，能够使系统快速恢复运行。这个库可以看作单机游戏的存档，让你能够读档由上次保存点开始，继续游戏。
• 另一方面，Provenance Repository保存了提供更详尽的，完整的保存了每个FlowFile生命周期的所有相关信息。这个就像是游戏录像整个游戏过程完全被保存，可以重播，可以观察每个点，内容更详尽。
  
  “FlowFile Repository”是一张最新的照片，保存了系统最后的样子。“Provenance Repository”是一段视频，可以倒回到过去的任何时刻，调查数据，回放给定时间的操作。它提供了完整的数据血缘。

FlowFile Processor

• 是一个执行某种操作的黑盒。
• 能够访问FlowFile的属性和内容来完成各种各样的行为
• 可以摄取数据、执行标准的数据转换和验证、将数据存储到外部数据源“Processor”。

NiFi内置了非常多的“processor”，可以满足80%以上的构建数据流程的需求。如果在标准“processor”列表中没有找到能够满足需求的“processor”，也可以开发自己的“processor”。

“processor”是完成一项任务的高级抽象。这种抽象隐藏了并发编程和错误处理机制的复杂性，使构建数据流程变得简单直观。

“processor”一般都有多个配置项，可以对其执行的操作进行微调。

“processor”的属性是NiFi与应用程序需求的业务现实之间的最后一个链接。问题出在细节上，数据流程开发者需要花费大部分时间微调这些属性以完成预期行为。

扩展

可以给每个“Processor”配置一个并发任务数，使它能够利用多个线程执行。“Flow Controller”分配更多的资源给这个“Processor”，从而增加它的吞吐量。“Processor”共享主机硬件资源。如果一个“Processor”请求更多线程，那么其他“Processor”可执行的线程就会变少。

**水平缩放。**另一种扩展方法是增加NiFi集群中的节点数。集群服务器使您能够使用商用硬件来提高处理能力。

Process Group

现在我们已经了解了什么是“Processor”，这一点不算复杂。

一组“processors”及其连接可以组成一个处理组（process group）。可以添加一个输入端口和一个输出端口，以便它可以接收和发送数据。

Connections

连接(Connection)是"“Processor”"之间的队列。这些队列允许"Processor"以不同的速率进行交互。连接(Connection)可以有不同的容量，就像存在不同尺寸的水管一样。
各个"Processor"执行的操作不同，以不同的速率消费和生产数据，需要连接(Connection)充当FlowFile的缓冲区。

连接(Connection)中可以缓存多少数据是有限制的。就像当你的水管满了，你就不能再加水了，否则水就会溢出来。

在NiFi中，您可以设置FlowFile的数量或FlowFile内容的数据量做为缓冲的上限。

当发送的数据超过连接所能缓存的数量时会发生什么？

如果FlowFile的数量或数据量超过定义的阈值，会使用“背压”。在队列中有空间之前，流控制器(Flow Mananger)会暂停前一个"Processor"运行。

假设两个"Processor"之间的FlowFile限制为10000个。在某种程度上，连接中有7000个元素。上限是10000，没问题。P1仍然可以通过连接到P2发送数据。

现在假设p1向连接再发送4000个新的FlowFile。
7000+4000=11000→超过了10000个FlowFile的连接阈值。

这些限制是软限制，意味着可以超过它们。但是，一旦它们被设置好，在连接器返回到其阈值以下（10000个FlowFiles）之前，前一个处理器P1将不会被调度。

这个简化的例子展示了背压是如何工作的。需要设置与要处理的数据量和速度相适应的连接阈值。

当FlowFile或相关数据的数量超过阈值时，交换机制被触发。

确定流文件的优先级
NiFi中的连接器是高度可配置的。可以选择优先策略，以决定下一步优先处理哪个文件。

在可用的优先策略，常见的有FIFO、Max优先、Min优先等。甚至可以使用FlowFile的属性来对传入的数据包进行优先级排序。

Flow Controller（流程控制器）

Flow Controller(流程控制器）是把所有东西结合在一起的粘合剂。管理线程，执行数据流程。

此外，流控制器(Flow Controller )使添加控制器服务(Controller Services)成为可能。

这些服务有助于管理共享资源，如数据库连接或云服务提供商凭据等。控制器服务是守护程序，在后台运行，为处理器提供配置、资源和参数。

例如，可以使用AWS凭据提供程序服务(AWS credentials provider service)使您的服务能够在不需要担心处理器级别的凭据。

Controller Services

这些服务有助于管理共享资源，如数据库连接或云服务提供商凭据等。控制器服务是守护程序，在后台运行，为处理器提供配置、资源和参数。

例如，可以使用AWS凭据提供程序服务(AWS credentials provider service)使您的服务能够在不需要担心处理器级别的凭据。

就像"Processor"一样，NiFi提供开箱即用多种控制器服务。可以看看这篇文章有关控制器服务的更多内容。