其他分享
首页 > 其他分享> > NiFi如何工作

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客户处理各种各样的数据源和数据格式。可以由一个数据源中获取数据,对数据进行计算、转化,把数据推送到其他的数据源进行存储。apache 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实现这个数据管道,只要在NiFi的用户姐main中,拖拽三个组件到画布,再拖拽两个链接将它们关联到一起,简单的配置一下就完成了。这个过程只需要几分钟。代码实现可能需十几小时甚至几十小时来完成。
nifi pipline
如果编写代码来做同样的功能,看起来需要几百行代码,才能得到同样的结果。

您不会像使用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特性
大数据 4V

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

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

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

应用场景原来越多

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

抽丝剥茧看NiFi

NiFi开箱

启动NiFi,打开它的主界面,数据流程的设计,运行,管理,监控都在这个界面上了。
nifi ui
在NiFi中,组装一个数据流程需要若干个Processor用来处理数据,需要若干个Connection用来把Processor链接到一起。Processor是处理数据的站点,数据进站被加工处理后出站。Connection是连接站点的公路,数据通过Connection在站点之间间流动,同时还起到缓存的作用。在NiFi界面的画布上,通过拖拽连接起来,构建数据流。前面数据流程的例子,由三个processor和两天连接它们的connection构成。
在这里插入图片描述

NiFi的术语

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

如下图所示:

黑盒子被称为Processor,它们通过名为Connection队列交换名为FlowFile的数据。最后由FlowContoller负责管理这些组件和资源。
Processor、FlowFile、Connector
简单看看它们是如何工作的

FlowFile

在NiFi中,FlowFile是数据的封装,在数据管道中流动。
FlowFile
FlowFile由两部分组成:

FlowFile并不自己持有数据,这对吞吐量由非常大的益处。代替方案是,FlowFile有一个指针,指向存储在本地存储(Content Repository)里的数据。
FlowFile Repository
为了访问内容,FlowFile从内容存储库中读取数据。 FlowFile会跟踪内容所在文件的确切偏移量,并将其取回到FlowFile。

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

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

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

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

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

FlowFile repository

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的属性和上下文
处理提供完成的数据血缘外,“Provenance Repository”也提供了在任何时间点回放数据的能力

多亏了“Provenance Repository”,我们可以追溯数据的历史
“FlowFile Repository” vs. "Provenance Repository"

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

FlowFile Processor

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

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

“processor”一般都有多个配置项,可以对其执行的操作进行微调。
记录验证“Processor”— UI完成配置,黑盒隐藏实现细节.
“processor”的属性是NiFi与应用程序需求的业务现实之间的最后一个链接。问题出在细节上,数据流程开发者需要花费大部分时间微调这些属性以完成预期行为。

扩展

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

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

Process Group

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

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

使用三个已经存在的处理器,创建一个新的“Processor”(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发送数据。

两个“Processor”通过一个限制了上限的连接相连
现在假设p1向连接再发送4000个新的FlowFile。
7000+4000=11000→超过了10000个FlowFile的连接阈值。
产生背压,p1暂停
这些限制是软限制,意味着可以超过它们。但是,一旦它们被设置好,在连接器返回到其阈值以下(10000个FlowFiles)之前,前一个处理器P1将不会被调度。
连接器中的FlowFile数返回到阈值以下。流控制器(Flow Controller)再次调度处理器P1
这个简化的例子展示了背压是如何工作的。需要设置与要处理的数据量和速度相适应的连接阈值。

当FlowFile或相关数据的数量超过阈值时,交换机制被触发。
Nifi连接器中的活动队列和交换
确定流文件的优先级
NiFi中的连接器是高度可配置的。可以选择优先策略,以决定下一步优先处理哪个文件。

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

Flow Controller(流程控制器)

Flow Controller(流程控制器)是把所有东西结合在一起的粘合剂。管理线程,执行数据流程。
Flow Controller调度资源流程控制器
此外,流控制器(Flow Controller )使添加控制器服务(Controller Services)成为可能。

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

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

Controller Services

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

例如,可以使用AWS凭据提供程序服务(AWS credentials provider service)使您的服务能够在不需要担心处理器级别的凭据。
AWS凭证服务为两个处理器提供上下文
就像"Processor"一样,NiFi提供开箱即用多种控制器服务。可以看看这篇文章有关控制器服务的更多内容。

标签:NiFi,存储,Repository,工作,如何,FlowFile,数据,Processor
来源: https://blog.csdn.net/tj85771370/article/details/110074941