apache nifi
2022-09-21 15:15:48 0 举报AI智能生成
Apache NiFi 是一个易于使用、功能强大而且可靠的数据处理和分发系统。Apache NiFi 是为数据流设计。它支持高度可配置的指示图的数据路由、转换和系统中介逻辑。
作者其他创作
大纲/内容
概述
Apache NiFi 是一个易于使用、功能强大而且可靠的数据处理和分发系统。Apache NiFi 是为数据流设计。它支持高度可配置的指示图的数据路由、转换和系统中介逻辑。
简单的说，NiFi就是为了解决不同系统间数据自动流通问题而建立的。虽然dataflow这个术语在各种场景都有被使用，但我们在这里使用它来表示不同系统间的自动化的可管理的信息流。自企业拥有多个系统开始，一些系统会有数据生成，一些系统要消费数据，而不同系统之间数据的流通问题就出现了。这些问题出现的相应的解决方案已经被广泛的研究和讨论，其中企业集成eip就是一个全面且易于使用的方案。
dataflow要面临的一些挑战包括
Systems fail
网络故障，磁盘故障，软件崩溃，人为事故。
Data access exceeds capacity to consume
有时，给定的数据源可能会超过处理链或交付链的某些部分的处理能力，而只需要一个环节出现问题，整个流程都会受到影响。
Boundary conditions are mere suggestions
总是会得到太大、太小、太快、太慢、损坏、错误或格式错误的数据。
What is noise one day becomes signal the next
现实业务或需求变更快，设计新的数据处理流程或者修改已有的流程必必须要迅速。
Systems evolve at different rates
给定的系统所使用的协议或数据格式可能随时改变，而且常常跟周围其他系统无关。dataflow的存在就是为了连接这种大规模分布的，松散的，甚至根本不是设计用来一起工作的组件系统。
Compliance and security*
法律，法规和政策发生变化。企业对企业协议的变化。系统到系统和系统到用户的交互必须是安全的，可信的，负责任的。
Continuous improvement occurs in production
通常不可能在测试环境中完全模拟生产环境。
多年来，数据流一直是架构中不可避免的问题之一。现在有许多活跃的、快速发展的技术，使得dataflow对想要成功的特定企业更加重要，比如soa,API，iot,bigData。此外，合规性，隐私性和安全性所需的严格程度也在不断提高。尽管不停的出现这些新概念新技术，但dataflow面临的困难和挑战依旧，其中主要的区别还是复杂的范围，需要适应的需求变化的速度以及大规模边缘情况的普遍化。NiFi旨在帮助解决这些现代数据流挑战。
特性
基于 web 的用户界面
无缝体验设计、控制和监视
高度可配置的
数据丢失容错和保证交付
低延迟和高吞吐量
动态优先级
流可以在运行时修改
背压 Back presure
数据来源
从始至终跟踪数据流
为扩展设计
构建自己数据处理器
支持快速开发和有效的测试
安全
SSL,SSH,HTTPS 加密内容，等等……
可插拔的基于角色的验证 / 授权
核心概念
NiFi的基本设计概念与基于流程的编程fbp的主要思想密切相关。以下是一些主要的NiFi概念以及它们如何映射到FBP
论文
https://en.wikipedia.org/wiki/Flow-based_programming#Concepts
基于流编程
此设计模型也类似于seda，带来了很多好处，有助于NiFi成为非常有效的、构建功能强大且可扩展的数据流的平台。其中一些好处包括
有助于处理器有向图的可视化创建和管理
本质上是异步的，允许非常高的吞吐量和足够的自然缓冲
提供高并发的模型，开发人员不必担心并发的复杂性
促进内聚和松散耦合组件的开发，然后可以在其他环境中重复使用并方便单元测试
资源受限的连接(流程中可配置connections)使得背压和压力释放等关键功能非常自然和直观
错误处理变得像基本逻辑一样自然，而不是粗粒度的全部捕获(catch-all)
数据进入和退出系统的点，以及它是如何流动的，都是容易理解和跟踪的。
本质上是异步的，允许非常高的吞吐量和足够的自然缓冲
提供高并发的模型，开发人员不必担心并发的复杂性
促进内聚和松散耦合组件的开发，然后可以在其他环境中重复使用并方便单元测试
资源受限的连接(流程中可配置connections)使得背压和压力释放等关键功能非常自然和直观
错误处理变得像基本逻辑一样自然，而不是粗粒度的全部捕获(catch-all)
数据进入和退出系统的点，以及它是如何流动的，都是容易理解和跟踪的。
这里从源码的角度上来讲讲 NiFi 的本质,在我看来,NiFi 是一套借鉴 flow-based programming (FBP) 编程范式写成的 Java 编程工具箱.首先它是用 Java 语言写成的系统级应用或者说是框架,对于 FBP,它是一种编程范式,如面向过程,面向对象,函数式,流式编程等一样.FBP是流式编程的一种,简单理解就是把程序看作是信息数据包,处理器以及处理器间的连接组成的有向图.这是 NiFi 的使用方式,也可以称这是使用 NiFi 来进行数据编程.说它是工具箱,是因为它内置了很多的 Java 组件,框架和技术.它将各种 Java 框架技术包装成 NiFi 中的处理器或者服务等组件,开箱即用,组合成不同的 data flow ,对于开发者来说,也可以叫编写成不同的应用程序.
NiFi 核心框架对 IO,并发,异步,缓冲缓存,容错等技术方面的处理和设计都是非常值得学习和研究的.
架构
Web Server
web服务器的目的是承载NiFi基于http的命令和控制API。
Flow Controller
是整个操作的核心，为将要运行的组件提供线程，管理调度。
Extensions
有各种类型的NIFI扩展，这些扩展在其他文档中进行了描述。这里的关键点是NIFI扩展在JVM中操作和执行。
FlowFile Repository
对于给定一个流中正在活动的FlowFile,FlowFile Repository就是NIFI保持跟踪这个FlowFIle状态的地方。FlowFile Repository的实现是可插拔的（多种选择，可配置，甚至可以自己实现），默认实现是使用Write-Ahead Log技术(简单普及下，WAL的核心思想是：在数据写入库之前，先写入到日志.再将日志记录变更到存储器中。)写到指定磁盘目录。
Content Repository
Content Repository是给定FlowFile的实际内容字节存储的地方。Content Repository的实现是可插拔的。默认方法是一种相当简单的机制，它将数据块存储在文件系统中。可以指定多个文件系统存储位置，以便获得不同的物理分区以减少任何单个卷上的争用。(所以环境最佳实践时可配置多个目录，挂载不同磁盘，提高IO)
Provenance Repository
Provenance Repository是存储所有事件数据的地方。Provenance Repository的实现是可插拔的，默认实现是使用一个或多个物理磁盘卷。在每个位置内的事件数据都是被索引并可搜索的。
集群
从NiFi 1.0版本开始，NIFI集群采用了Zero-Master Clustering模式。NiFi群集中的每个节点对数据执行相同的任务，但每个节点都在不同的数据集上运行。Apache ZooKeeper选择单个节点作为集群协调器，ZooKeeper自动处理故障转移。所有集群节点都会向集群协调器发送心跳报告和状态信息。集群协调器负责断开和连接节点。此外，每个集群都有一个主节点，主节点也是由ZooKeeper选举产生。我们可以通过任何节点的用户界面（UI）与NiFi群集进行交互，并且我们所做的任何更改都将复制到集群中的所有节点上。
NIFI的特性及性能预期
NIFI的设计目的是充分利用其运行的底层主机系统的能力。这种资源的最大化在CPU和磁盘方面尤其明显。有关其他详细信息，请参阅“Administration Guide”中的最佳实践和配置提示文档。
For IO
不同系统不同配置可预期的吞吐量或延迟会有很大差异，具体取决于系统的配置方式。鉴于大多数NiFi子系统都有可插拔的实现方法，所以性能取决于实现。但是，对于一些具体和广泛适用的地方，请考虑使用现成的默认实现。这些实现都是持久的，有保证的让数据流传递，并且是使用本地磁盘来实现。因此，保守点说，假设在典型服务器中的普通磁盘或RAID卷上的每秒读/写速率大约为50 MB，那么，对于大型数据流，NIFI应该能够有效地达到每秒100 MB或更多的吞吐量。这是因为预期添加到NiFi的每个物理分区和content repository都会出现线性增长，瓶颈将出现在FlowFile repository和Provenance repository的某个点上。我们计划提供一个基准测试和性能测试模板，然后允许用户能够轻松测试他们的系统并确定瓶颈在哪里，以及他们可能成为瓶颈的原因。此模板还应使系统管理员可以轻松进行更改并验证其影响。(期待这个测试功能的出现)
For CPU
Flow Controller充当引擎的角色，指示特定处理器何时可以被分配线程去执行。编写处理器以在执行任务后立即释放线程。可以为Flow Controller提供一个配置值，该值指示它维护的各种线程池的可用线程。理想的线程数取决于主机系统内核数量，系统中是否正在运行其他服务，以及流程中要处理的流的性质。对于典型的IO大流量，合理的做法是让多线程可用。
For RAM
NiFi在JVM中运行，因此限制于JVM提供的内存。JVM垃圾回收（GC）成为限制实际堆总大小以及优化应用程序的运行的一个非常重要的因素。NIFI作业在定期读取相同内容时可能会占用大量I/O。可以配置足够大的磁盘以优化性能。
NIFI关键特性高度概览
Flow Management
Guaranteed Delivery
NIFI的核心理念是，即使在非常高的规模下，也必须保证交付。这是通过有效地使用专门构建的Write-Ahead Log和content repository来实现的。它们一起被设计成具备允许非常高的事务速率、有效的负载分布、写时复制和能发挥传统磁盘读/写的优势。
Data Buffering w/ Back Pressure and Pressure Release
NIFI支持缓冲所有排队的数据，以及在这些队列达到指定限制时提供背压的能力，或在数据达到指定期限（其值已失效）时老化数据的能力。
Prioritized Queuing
NiFi允许设置一个或多个优先级方案，用于如何从队列中检索数据。默认情况是先进先出，但有时应该首先提取最新的数据(后进先出)、最大的数据先出或其他定制方案。
Flow Specific QoS (latency v throughput, loss tolerance, etc.)
可能在数据流的某些节点上数据至关重要，不容丢失，并且在 某些时刻这些数据需要在几秒钟就处理完毕传向下一节点才会有意义。对于这些 方面NIFI也可以做细粒度的配置。
Ease of Use
Visual Command and Control
数据流的处理逻辑和过程可能会非常复杂。能够可视化这些流程并以可视的方式来表达它们可以极大地帮助用户降低数据流的复杂度，并确定哪些地方需要简化。NiFi可以实现数据流的可视化建立，而且是实时的。并不是“设计、部署”，它更像泥塑。如果对数据流进行了更改，更改就会立即生效，并且这些更改是细粒度的和组件隔离的。用户不需要为了进行某些特定修改而停止整个流程或流程组。
Recovery / Recording a rolling buffer of fine-grained history
NiFi的content repository旨在充当历史数据的滚动缓冲区。数据仅在content repository老化或需要空间时才会被删除。content repository与data provenance能力相结合，为在对象的生命周期中的特定点（甚至可以跨越几代）实现可以查看内容，内容下载和重放等功能提供了非常有用的基础。
Security
System to System
数据流越安全越好。对于数据流中每个节点NiFi都是通过使用加密协议（如双向SSL）来安全地交换数据。此外，NiFi的流程能够加密和解密内容，并在发送方/接收方任何一侧使用共享密钥或其他机制来保证数据的安全。
User to System
NiFi支持双向SSL身份验证，并提供可插拔授权方式，以便能够正确控制用户的访问权限和特定级别（只读，数据流管理，admin）。如果用户在流程中输入敏感属性（如密码），则会立即在服务器端加密，保证敏感信息不会再次暴露在客户端(前端UI)中(比如用户A在流程中输入了MySQL的用户密码，填写完毕后任何人即使是用户A也看不到明文密码)。
Multi-tenant Authorization
NIFI数据流的权限级别适用于每个组件，并且允许管理员用户拥有细粒度的控制访问级别。这意味着每个NiFi集群都能够处理一个或多个组织的需求。与隔离拓扑相比，多租户授权支持数据流管理的自助服务，允许每个团队或组织在完全了解流的其余部分的情况下管理流，而无法访问流。
Extensible Architecture
Extension
NiFi的核心是可扩展，因此它是一个可以以可预测和可重复的方式去执行和交互的数据流流程平台。可扩展的包括：processors, Controller Services, Reporting Tasks, Prioritizers, 和 Customer User Interfaces。
Classloader Isolation
对于任何基于组件的系统，涉及依赖的问题时常发生。NiFi通过提供自定义类加载器(在下面的NIFI源码会有进一步讲解)来解决这个问题，确保每个扩展包都暴露在一组非常有限的依赖中。因此，构建扩展包的时候不必担心它们是否可能与另一个扩展包冲突。这些扩展包的概念称为“NiFi Archives”，在Developer’s Guide中有更详细的讨论。
Site-to-Site Communication Protocol
NiFi实例之间的首选通信协议是NiFi站点到站点（S2S）协议。S2S轻松，高效，安全地将数据从一个NiFi实例传输到另一个实例。NiFi客户端库可以轻松构建并捆绑到其他应用程序或设备中，通过S2S协议与NiFi进行通信。S2S中支持以socket的协议和HTTP（S）协议作为底层传输协议，使得可以将代理服务器嵌入到S2S协议的通信中。
Flexible Scaling Model
Scale-out (Clustering)
NiFi的设计是可集群，可横向扩展的。如果配置单个节点并将其配置为每秒处理数百MB数据，那么可以相应的将集群配置为每秒处理GB级数据。但这也带来了NiFi与其获取数据的系统之间的负载平衡和故障转移的挑战。采用基于异步排队的协议（如消息服务，Kafka等）可以提供帮助解决这些问题。使用NiFi的s2s功能也非常有效，因为它是一种协议，允许NiFi和客户端（包括另一个NiFi群集）相互通信，共享有关加载的信息，以及交换特定授权的数据端口。
Scale-up & down
NiFi还可以非常灵活地扩展和缩小。从NiFi框架的角度来看，在增加吞吐量方面，可以在配置时增加“调度”选项卡下处理器上的并发任务数。这允许更多线程同时执行，从而提供更高的吞吐量。另一方面，您可以完美地将NiFi缩小到适合在边缘设备上运行，因为硬件资源有限，所需的占用空间很小，这种情况可以使用MINIFI，
NiFi 源码框架分析
当 NiFi 源码编译好之后,就开始正式进入源码分析.在 eclipse 里面左边视图拉一下列表,可以看到,NiFi 总共有 394 个 pom 工程.一下子感觉无从下手,这个时候我们还是要回过头来看 NiFi 官网上的架构图
nifi-api 就是 nifi 的应用程序接口,里面就是定义了整个工程所需要用到的接口,注解,抽象类和枚举等基本的接口和信息.
nifi-assembly 负责 nifi 的成品装配, 工程打包最后形成的可供部署的压缩包就在这个工程里的 target 目录内.
nifi-bootstarp 负责 nifi 这个 jvm 应用程序的启动相关事宜
nifi-commons nifi 诸多特性,比如data-provenance,expression-language,s2s 传输 的实现就在这里,同时也是 nifi 的工具类集合
nifi-docker nifi 的 docker 应用相关
nifi-docs nifi 的文档 实现相关
nifi-external nifi 内部元信息和外部交换,主要用于集群模式下
nifi-framework-api 这就是nifi 核心框架层的api,也就是架构图中的 Flow Controller 那一层,注意这里只是各种接口信息定义,不是实现.
nifi-maven-archetypes 这里只是为了生成两个 maven archetype,一个是 nifi 自定义处理器的脚手架,一个是 nifi 自定义服务的脚手架.这些脚手架在 maven 的中央仓库都有提供.
nifi-mock 用于 nifi 的 mock 测试
nifi-nar-bundles 之前一直说的 nifi java 工具箱就是这里了.整个 nifi 里面大部分的 maven 工程都是这个工程的子工程.在这个工程里面,一个 bundle 就是一个工具,也对应着上面架构图里的 Extension
nifi-toolkit 这里面是 nifi 的命令行工具的实现.nifi 也提供了比较丰富的命令行指令.
nifi-assembly 负责 nifi 的成品装配, 工程打包最后形成的可供部署的压缩包就在这个工程里的 target 目录内.
nifi-bootstarp 负责 nifi 这个 jvm 应用程序的启动相关事宜
nifi-commons nifi 诸多特性,比如data-provenance,expression-language,s2s 传输 的实现就在这里,同时也是 nifi 的工具类集合
nifi-docker nifi 的 docker 应用相关
nifi-docs nifi 的文档 实现相关
nifi-external nifi 内部元信息和外部交换,主要用于集群模式下
nifi-framework-api 这就是nifi 核心框架层的api,也就是架构图中的 Flow Controller 那一层,注意这里只是各种接口信息定义,不是实现.
nifi-maven-archetypes 这里只是为了生成两个 maven archetype,一个是 nifi 自定义处理器的脚手架,一个是 nifi 自定义服务的脚手架.这些脚手架在 maven 的中央仓库都有提供.
nifi-mock 用于 nifi 的 mock 测试
nifi-nar-bundles 之前一直说的 nifi java 工具箱就是这里了.整个 nifi 里面大部分的 maven 工程都是这个工程的子工程.在这个工程里面,一个 bundle 就是一个工具,也对应着上面架构图里的 Extension
nifi-toolkit 这里面是 nifi 的命令行工具的实现.nifi 也提供了比较丰富的命令行指令.
进入源码
启动类
org.apache.nifi.NiFi
真正启动类
java工具箱
NarClassLoaders
nar 包 其实就是 nifi 包装了其他额外信息的 jar 包集合的压缩包而已
记住这个图, NiFi 首先是一个 JVM 应用,其次最上层是一个 web server.我们就从这里入手开始阅读 NiFi 的源码.
0 条评论
下一页
