第一章 Apache NiFi概述

Apache NiFi概述

第一章 Apache NiFi概述

---

---

一、什么是Apache NiFi？

简而言之，NiFi用来自动构建系统之间的数据流。虽然“DataFlow”一词在多种情况下使用，但我们在这里使用它来表示系统之间的自动化和托管信息数据流。自从企业拥有多个系统以来，就一直存在这个问题，其中一些系统会创建数据，一些系统需要消费这些数据。出现的问题和解决方案已被广泛讨论和阐明。在企业集成模式[eip]¹ 中找到了一种全面且易于使用的形式。

数据流的一些高级挑战包括：

系统故障
网络故障，磁盘故障，软件崩溃，人为失误。

数据访问超出了消费能力
有时，给定的数据源可能会超过处理或交付链的某个部分，导致消费能力受限。

边界条件仅是建议
数据总会出现太大，太小，太快，太慢，损坏，错误或格式错误的情况。

开始可能是噪音数据，后面可能又变成分析对象
组织的优先级快速变化。启用新流程和更改现有流程必须很快。

系统以不同的速度发展
给定系统使用的协议和格式可以随时更改，通常与周围的系统无关。数据流的存在是为了连接本质上是大规模分布的组件系统，这些组件是松散的或根本不是一起工作的。

合规性与安全性
法律，法规和政策会发生变化。企业对企业协议会发生变化。系统到系统以及系统到用户的交互必须是安全的，可信任的，负责的。

生产中不断改进
通常不可能接近实验室中的复制生产环境。
多年来，数据流已成为体系结构中的必要弊端之一。现在，尽管有许多活跃且迅速发展的运动使数据流变得更加有趣，并且对于给定企业的成功也至关重要。这些包括：面向服务的体系结构[soa]²，API [api]³ [api2]⁴的兴起，物联网[iot]⁵和大数据[bigdata]⁶。此外，合规性，隐私性和安全性所必需的严格程度也在不断提高。即使所有这些新概念都应运而生，数据流的模式和需求仍然大致相同。那么主要的区别是复杂性的范围，适应所必需的变化率以及在规模上边缘情况变得普遍。NiFi旨在帮助解决这些现代数据流挑战。

二、NiFi的核心概念

NiFi的基本设计概念与基于流程的编程[fbp]⁷的主要思想紧密相关。以下是一些主要的NiFi概念以及它们如何映射到FBP：

NiFi术语	FBP术语	描述
流文件(FlowFile)	信息包(Information Packet)	FlowFile代表通过系统移动的每个对象，对于每个对象，NiFi都会跟踪 Key/Value 对属性字符串及其0个或多个字节的关联内容的映射。
流文件处理器(FlowFile Processor)	黑盒子(Black Box)	处理器实际上执行工作。用[eip]1术语来说，处理器是在系统之间进行数据路由，转换或中介的某种组合。处理器可以访问给定FlowFile及其内容流的属性。处理器可以在给定的工作单元中对0个或多个FlowFiles进行操作，并提交该工作或回滚。
连接(Connection)	有界缓冲区(Bounded Buffer)	连接提供了处理器之间的实际链接。这些充当队列，并允许各种进程以不同的速率进行交互。这些队列可以动态地进行优先级排序，并且可以在负载上具有上限，从而可以实现背压。
流控制器(Flow Controller)	排程器(Scheduler)	流控制器维护有关进程如何连接和管理所有进程使用的线程及其分配的知识。流控制器充当代理，促进处理器之间的FlowFiles交换。
进程组(Process Group)	子网(subnet)	进程组是一组特定的进程及其连接，可以通过输入端口接收数据，并通过输出端口发送数据。以这种方式，过程组允许仅通过其他组件的组合来创建全新的组件。

此设计模型也类似于[seda]⁸，提供了许多有益的结果，这些结果有助于NiFi成为构建强大且可扩展的数据流的非常有效的平台。这些好处包括：

• 非常适合视觉创建和管理处理器的有向图
• 天生是异步的，即使处理和流量波动，也可以实现很高的吞吐量和自然缓冲
• 提供高度并发的模型，而开发人员不必担心并发的典型复杂性
• 促进内聚和松散耦合的组件的开发，然后可以在其他情况下重用这些组件并开发可测试的单元
• 资源受限的连接使背压和压力释放等关键功能非常自然直观
• 错误处理变得像快乐之路一样自然，而不是粗粒度的包罗万象
• 数据进入和离开系统的时间点以及数据流的方式已得到很好的理解并易于跟踪

三、NiFi架构

NiFi在主机操作系统上的JVM中执行。JVM上的NiFi的主要组件如下：

网络服务器(Web Server)
Web服务器的目的是托管NiFi基于HTTP的命令和控制API。

流控制器(Flow Controller)
流控制器是操作的大脑。它为扩展程序提供运行所需的线程，并管理扩展程序何时接收执行资源的时间表。

扩展(Extension)
其他文档中介绍了各种类型的NiFi扩展程序。这里的关键点是扩展在JVM中运行和执行。

FlowFile库(FlowFile Repository)
NiFi可以在FlowFile信息库中跟踪对流中当前处于活动状态的给定FlowFile的了解状态。存储库的实现是可插入的。默认方法是位于指定磁盘分区上的持久性预写日志。

内容仓库(Content Repository)
Content Repository是给定FlowFile的实际内容字节所在的位置。存储库的实现是可插入的。默认方法是一种相当简单的机制，它将数据块存储在文件系统中。可以指定多个文件系统存储位置，以便使用不同的物理分区来减少任何单个卷上的争用。

来源库(Provenance Repository)
来源库是存储所有来源事件数据的地方。存储库构造是可插入的，默认实现是使用一个或多个物理磁盘卷。在每个位置内，事件数据都被索引并可以搜索。

NiFi还可以在集群中运行。

从NiFi 1.0版本开始，采用零领导者聚类范例。NiFi集群中的每个节点都对数据执行相同的任务，但是每个节点都对不同的数据集进行操作。Apache ZooKeeper选择一个节点作为集群协调器，并且故障转移由ZooKeeper自动处理。所有群集节点均向群集协调器报告心跳和状态信息。群集协调器负责断开和连接节点。此外，每个群集都有一个主节点，该节点也由ZooKeeper选择。作为DataFlow管理器，您可以通过任何节点的用户界面（UI）与NiFi群集进行交互。您所做的任何更改都将复制到群集中的所有节点，从而允许多个入口点。

---

四、NiFi的性能期望和特性

NiFi旨在充分利用其所运行的基础主机系统的功能。就CPU和磁盘而言，这种资源最大化尤其强大。有关其他详细信息，请参阅《管理指南》中的最佳做法和配置提示。

对于IO
一个人可以期望看到的吞吐量或等待时间变化很大，这取决于系统的配置方式。鉴于大多数主要的NiFi子系统都有可插入的方法，因此性能取决于实现方式。但是，对于某些具体且广泛适用的问题，请考虑使用现成的默认实现。这些都是持久的，并保证了交付，并且使用本地磁盘来实现。因此，保守起见，假设在典型服务器中的适度磁盘或RAID卷上每秒大约有50 MB的读/写速率。然后，用于大量数据流的NiFi应该能够有效地达到每秒100 MB或更高的吞吐量。这是因为预计添加到NiFi的每个物理分区和内容存储库都将线性增长。这将在FlowFile存储库和源存储库上的某些时候出现瓶颈。我们计划提供一个基准测试和性能测试模板，以包括在构建中，该模板使用户可以轻松地测试他们的系统并确定瓶颈在哪里，以及在什么时候可能成为瓶颈。该模板还应使系统管理员可以轻松进行更改并验证影响。

对于CPU
流控制器充当引擎，指示何时向特定处理器分配要执行的线程。处理器被编写为在执行完任务后立即返回线程。可以为流控制器提供一个配置值，该值指示其维护的各种线程池的可用线程。使用的理想线程数取决于主机系统资源的核心数量，该系统是否还运行其他服务以及流中处理的性质。对于典型的IO繁重的流，合理的做法是使多线程可用。

对于RAM
NiFi驻留在JVM中，因此受限于JVM提供的内存空间。JVM垃圾回收成为限制总实际堆大小以及优化应用程序随时间运行状况的一个非常重要的因素。定期读取相同内容时，NiFi作业可能会占用大量I / O。配置足够大的磁盘以优化性能。

五、NiFi主要功能概述

关键功能类别包括流管理，易用性，安全性，可扩展的体系结构和灵活的缩放模型。

流管理

保证交货
NiFi的核心理念是，即使规模很大，也必须保证交付。这可以通过有效使用专用的持久性预写日志和内容存储库来实现。它们的设计共同考虑到了很高的事务处理速率，有效的负载分散，写时复制以及发挥了传统磁盘读/写的优势。

带反压和泄压的数据缓冲
NiFi支持缓冲所有排队的数据，并能够在这些队列达到指定的限制时提供反压力，或者在达到指定的使用期限（其值消失）时使数据过期。

优先排队
NiFi允许设置一种或多种优先级分配方案，以用于如何从队列中检索数据。默认值是最旧的优先，但是有时数据应该被最新的优先，最大的优先或其他一些自定义方案。

流特定的QoS（延迟v吞吐量，丢失容限等）
在数据流的某些点上，数据是绝对关键的并且不容忍丢失。在某些情况下，有时还必须在几秒钟内对其进行处理并交付任何值。NiFi可以实现这些问题的细粒度流特定配置。

易用性

视觉命令与控制
数据流可能变得非常复杂。能够可视化这些流程并以可视方式表达它们可以极大地帮助降低这种复杂性并确定需要简化的区域。NiFi不仅可以直观地建立数据流，而且可以实时建立数据流。与其“设计和部署”，不如说它是成型粘土。如果您对数据流进行更改，则该更改将立即生效。更改是细粒度的，并且与受影响的组件隔离。您无需停止整个流程或一组流程即可进行某些特定的修改。

流模板
数据流往往是高度面向模式的，尽管通常有许多不同的方法可以解决问题，但能够共享这些最佳实践对它很有帮助。模板使主题专家可以构建和发布其流程设计，并让其他人从中受益并进行协作。

资料来源
当对象流经系统时，即使在扇入，扇出，转换等过程中，NiFi也会自动记录，建立索引并提供出处数据。在支持合规性，故障排除，优化和其他方案时，此信息变得至关重要。

恢复/记录细粒度历史记录的滚动缓冲区
NiFi的内容存储库旨在充当历史的滚动缓冲区。数据仅在内容存储库中老化或需要空间时才被删除。这与数据源功能相结合，为在对象生命周期中甚至跨越几代生命周期的特定点上实现单击内容，下载内容和重播提供了极为有用的基础。

安全性

系统对系统
数据流仅是安全的。数据流中每个点的NiFi都可以通过使用带有加密的协议（例如2路SSL）来提供安全的交换。此外，NiFi使流能够加密和解密内容，并在发送者/接收者等式的任一侧使用共享密钥或其他机制。

用户到系统
NiFi启用2-Way SSL身份验证并提供可插入授权，以便它可以在特定级别（只读，数据流管理器，管理）适当地控制用户的访问。如果用户在流中输入诸如密码之类的敏感属性，它将立即在服务器端进行加密，并且即使以加密形式也不会再在客户端公开。

多租户授权
给定数据流的权限级别适用于每个组件，从而允许admin用户具有细粒度的访问控制级别。这意味着每个NiFi集群都能够处理一个或多个组织的需求。与隔离的拓扑相比，多租户授权为数据流管理提供了一种自助服务模型，允许每个团队或组织在完全了解他们无法访问的其余流的情况下管理流。

可扩展架构

扩展
NiFi是为扩展而构建的核心，因此，它是一个平台，数据流进程可以在该平台上以可预测和可重复的方式执行和交互。扩展点包括：处理器，控制器服务，报告任务，优先级划分程序和客户用户界面。

类加载器隔离
对于任何基于组件的系统，依赖关系问题都可能很快发生。NiFi通过提供自定义类加载器模型来解决此问题，确保每个扩展包都暴露于非常有限的依赖项集合中。结果，可以很少考虑扩展是否会与另一个扩展冲突。这些扩展束的概念称为“ NiFi存档”，并在《开发人员指南》中进行了详细讨论。

站点间通信协议
NiFi实例之间的首选通信协议是NiFi站点到站点（S2S）协议。通过S2S，可以轻松，高效，安全地将数据从一个NiFi实例传输到另一个实例。NiFi客户端库可以轻松构建并捆绑到其他应用程序或设备中，以通过S2S与NiFi通信。S2S支持基于套接字的协议和HTTP（S）协议作为基础传输协议，从而可以将代理服务器嵌入到S2S通信中。

弹性缩放模型

横向扩展（聚类）
如上所述，NiFi旨在通过将多个节点聚在一起来横向扩展。如果设置了一个节点并将其配置为每秒处理数百MB，则可以将适度的群集配置为每秒处理GB。这就带来了有趣的挑战，即在NiFi和从中获取数据的系统之间进行负载平衡和故障转移。使用基于异步排队的协议（例如消息传递服务，Kafka等）可以有所帮助。使用NiFi的“站点到站点”功能也非常有效，因为它是一种协议，它允许NiFi和客户端（包括另一个NiFi群集）相互交谈，共享有关加载的信息以及交换有关特定授权的数据端口。

放大和缩小
NiFi还设计为以非常灵活的方式放大和缩小。从NiFi框架的角度来看，在提高吞吐量方面，可以在配置时在“调度”选项卡下增加处理器上的并发任务数。这允许更多进程同时执行，从而提供更大的吞吐量。另一方面，您可以完美地缩小NiFi的尺寸，使其适合在由于硬件资源有限而需要较小占用空间的边缘设备上运行。要专门解决首英里数据收集挑战和边缘用例，您可以在此处找到更多详细信息：https : //cwiki.apache.org/confluence/display/NIFI/MiNiFi关于Apache NiFi的子项目MiMiFi的工作（发音为 “minify”，[min-uh-fahy]）。

参考文献

---

1. [eip] Gregor Hohpe. Enterprise Integration Patterns [online]. Retrieved: 27 Dec 2014, from: http://www.enterpriseintegrationpatterns.com ↩︎ ↩︎

2. [soa] Wikipedia. Service Oriented Architecture [online]. Retrieved: 27 Dec 2014, from: http://en.wikipedia.org/wiki/Service-oriented_architecture ↩︎

3. [api] Eric Savitz. Welcome to the API Economy [online]. Forbes.com. Retrieved: 27 Dec 2014, from: http://www.forbes.com/sites/ciocentral/2012/08/29/welcome-to-the-api-economy ↩︎

4. [api2] Adam Duvander. The rise of the API economy and consumer-led ecosystems [online]. thenextweb.com. Retrieved: 27 Dec 2014, from: http://thenextweb.com/dd/2014/03/28/api-economy ↩︎

5. [iot] Wikipedia. Internet of Things [online]. Retrieved: 27 Dec 2014, from: http://en.wikipedia.org/wiki/Internet_of_Things ↩︎

6. [bigdata] Wikipedia. Big Data [online]. Retrieved: 27 Dec 2014, from: http://en.wikipedia.org/wiki/Big_data ↩︎

7. [fbp] Wikipedia. Flow Based Programming [online]. Retrieved: 28 Dec 2014, from: http://en.wikipedia.org/wiki/Flow-based_programming#Concepts ↩︎

8. [seda] Matt Welsh. Berkeley. SEDA: An Architecture for Well-Conditioned, Scalable Internet Services [online]. Retrieved: 18 Jan 2018, from: http://www.mdw.la/papers/seda-sosp01.pdf ↩︎