什么是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” 存储了数据流程的最新状态，如果系统失败可以讲系统恢复到最后的状态。
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 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）。可以添加一个输入端口和一个输出端口，以便它可以接收和发送数据。
处理器组(Processor Group)是一种基于现有"Processor"创建新"Processor"的简单方法。
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将不会被调度。
确定流文件的优先级
NiFi中的连接器是高度可配置的。可以选择优先策略，以决定下一步优先处理哪个文件。
在可用的优先策略，常见的有FIFO、Max优先、Min优先等。甚至可以使用FlowFile的属性来对传入的数据包进行优先级排序。
Flow Controller（流程控制器）
Flow Controller(流程控制器）是把所有东西结合在一起的粘合剂。管理线程，执行数据流程。
此外，流控制器(Flow Controller )使添加控制器服务(Controller Services)成为可能。
这些服务有助于管理共享资源，如数据库连接或云服务提供商凭据等。控制器服务是守护程序，在后台运行，为处理器提供配置、资源和参数。
例如，可以使用AWS凭据提供程序服务(AWS credentials provider service)使您的服务能够在不需要担心处理器级别的凭据。
