Apache NiFi Overview

       Apache NIFI是一个易于使用，功能强大且可靠的系统，用于处理和分发数据，可以自动化管理系统间的数据流。简单来说NIFI是一个用来处理数据汇聚场景的数据分发系统；也可以把它理解成一个数据同步工具，类似datax、sqoop、Kettle、Logstash、Apache Camel、Streamsets；也可以把它理解成一个tomcat，一个有可视化操作的后端代码运行容器。

        在个人看来，nifi是一个数据流的运行调度容器，该容器有如下特性：稳定的数据流调度管理、半插件式扩展、强大事务支持、天生的高并发、数据监控、可视化配置；

01

—

NIFI使用缺点

• 句炳数较高，其他资源使用曲线平滑，就这个句炳数比较突出。

• io密集型，大量的预写，磁盘读写性能要求较高。虽然是天生的高并发框架，但是因为有数据流调度管理，所以在不出现dead loop flowfile情况下，cpu和内存还是比较平滑的。

• 数据流监控只有一段时间（默认5分钟），并且扩展能力不足。不能满足ETL，对数据抽取条数、清洗、转换、加载业务模型流转数据的统计分析，需要二次开发；

• 是否正确和数据源交互，可能直接影响nifi系统，开发使用者对第三方数据源使用的学习成本较高。例如：nifi可能系统不工作了，假象是nifi假死了，实际上可能是与数据源交互的问题导致的。

• NIFI本身的使用学习曲线还是有的。

03

—

NIFI特性

• Web-based user interface（基于Web的用户界面）

• Seamless experience between design, control, feedback, and monitoring（设计、控制、反馈、监控的无缝体验）

• Highly configurable（高度可配置）

• Loss tolerant vs guaranteed delivery（允许丢失数据vs保证交付数据）

• Low latency vs high throughput（低延迟vs高吞吐）

• Dynamic prioritization（动态优先排序）

• Flow can be modified at runtime（运行时修改流程）

• Back pressure（背压）

• Data Provenance（数据起源）

• Track dataflow from beginning to end（dataflow的全生命周期的跟踪记录）

• Designed for extension（设计扩展）

• Build your own processors and more（二次开发）

• Enables rapid development and effective testing（支持快速开发和有效测试）

• Secure（安全）

• SSL, SSH, HTTPS, encrypted content, etc...（数据安全设计）

• Multi-tenant authorization and internal authorization/policy management（细致的管理权限）

04

—

NIFI核心

05

—

单机NiFi架构

• 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的实现是可插拔的，默认实现是使用一个或多个物理磁盘卷。在每个位置内的事件数据都是被索引并可搜索的。

06

—

集群NiFi架构

Cluster Coordinator:集群协调器，用来进行管理节点添加和删除的操作逻辑。

Primary Node:主节点，用来运行一些不适合在集群中运行的组件。

Zookeeper Client:zk节点。

备注：从NiFi 1.0版本开始，NIFI集群采用了Zero-Master Clustering模式。NiFi群集中的每个节点对数据执行相同的任务，但每个节点都在不同的数据集上运行。Apache ZooKeeper选择单个节点作为集群协调器，ZooKeeper自动处理故障转移。所有集群节点都会向集群协调器发送心跳报告和状态信息。集群协调器负责断开和连接节点。此外，每个集群都有一个主节点，主节点也是由ZooKeeper选举产生。我们可以通过任何节点的用户界面（UI）与NiFi群集进行交互，并且我们所做的任何更改都将复制到集群中的所有节点上。

07

—

NIFI主要功能

• Flow Management

Guaranteed Delivery 保证交付	NiFi的核心理念是，即使在非常高的规模上，保证交付也是必须的。这是通过有效地使用专门构建的持久预写日志和内容存储库来实现的。它们结合在一起的设计方式允许非常高的事务速率、有效的负载分布、写时拷贝，并发挥传统磁盘读/写的优势。
Data Buffering w/ Back Pressure and Pressure Release 带背压和泄压的数据缓冲	NiFi支持对所有排队的数据进行缓冲，并支持在这些队列达到指定限制时提供背压，或者在数据达到指定期限（其值已消失）时对其进行老化。
Prioritized Queuing‍ 优先级队列	NiFi允许为如何从队列中检索数据设置一个或多个优先级方案。 默认先进先出，newest first, largest first。
Flow Specific QoS (latency v throughput, loss tolerance, etc.) 流量具体的Qos 延迟vs吞吐，损耗容限等	在数据流的某些点上，数据是绝对关键的，并且不能容忍丢失。也有一些时候，它必须在几秒钟内处理和交付，才能有价值。NiFi支持这些关注点的细粒度流特定配置。

• Security

System to System 系统到系统	数据流只有在安全的情况下才是好的。NiFi每一条数据流都通过使用诸如双向SSL之类的加密协议来提供安全的交换。此外，NiFi允许流对内容进行加密和解密，并在发送者/接收者或其他模式的任一侧，使用共享密钥或其他机制。
User to System 用户到系统	NiFi支持双向SSL身份验证，并提供可插拔的授权，以便能够在特定级别（只读、dataflow manager、admin）正确控制用户的访问。如果用户在流中输入一个敏感属性（如密码），它将立即在服务器端加密，即使以加密的形式也不会再次在客户端公开。
Multi-tenant Authorization 多租户授权	给定数据流的权限级别应用于每个组件，允许管理员用户具有细粒度的访问控制级别。这意味着每个NiFi集群能够处理一个或多个组织的需求。与独立的拓扑相比，多租户授权支持用于数据流管理的自助服务模型，允许每个团队或组织在管理流时完全了解流的其余部分（他们无权访问）。

• Ease of Use

Visual Command and Control 可视化的指挥与控制	数据流可能变得相当复杂。能够可视化这些流并直观地表达它们，可以极大地帮助降低复杂性，并确定需要简化的领域。NiFi不仅可以可视化地建立数据流，而且可以实时地建立数据流。与其说是“design and deploy”，不如说它更像是陶土的模塑。如果对数据流进行更改，更改将立即生效。更改是细粒度的，并且与受影响的组件隔离。您不需要仅仅为了进行某些特定的修改而停止整个流或一组流。
Flow Templates 流模版	数据流往往是高度面向模式的，虽然通常有许多不同的方法来解决问题，但能够共享这些最佳实践非常有帮助。模板允许主题专家构建和发布他们的流程设计，并让其他人从中受益并进行协作。
Data Provenance 数据来源‍	当对象在系统中流动时，NiFi会自动记录、索引和生成可用的出处数据，甚至可以跨扇入、扇出、转换等等。这些信息在支持法规遵从性、故障排除、优化和其他场景方面变得非常重要。
Recovery Recording a rolling buffer of fine-grained history 恢复/记录细粒度历史记录的滚动缓冲区	NiFi的内容存储库被设计成历史的滚动缓冲区。只有当数据从内容存储库中过时或需要空间时，才会删除数据。这与数据来源功能相结合，为在对象生命周期的某个特定点（甚至可以跨代）实现内容点击、内容下载和重播提供了非常有用的基础。

• Extensible Architecture

Extension 扩展	NiFi是为扩展而构建的核心，因此，它是一个平台，数据流进程可以在该平台上以可预测和可重复的方式执行和交互。扩展点包括：处理器，控制器服务，报告任务，优先级划分程序和客户用户界面。
Classloader Isolation 类加载器隔离	对于任何基于组件的系统，依赖关系问题都可能很快发生。NiFi通过提供自定义类加载器模型来解决此问题，确保每个扩展包都暴露于非常有限的依赖项集合中。结果，可以很少考虑扩展是否会与另一个扩展冲突。这些扩展的概念称为“ NiFi存档”，并在《开发人员指南》中进行了详细讨论。
Site-to-Site Communication Protocol 站点间通信协议	NiFi实例之间的首选通信协议是NiFi站点到站点（S2S）协议。通过S2S，可以轻松，高效，安全地将数据从一个NiFi实例传输到另一个实例。NiFi客户端库可以轻松构建并捆绑到其他应用程序或设备中，以通过S2S与NiFi通信。S2S支持基于套接字的协议和HTTP（S）协议作为基础传输协议，从而可以将代理服务器嵌入到S2S通信中。

• Flexible Scaling Model

Scale-out (Clustering) 横向扩展（聚类）	如上所述，NiFi旨在通过将多个节点聚在一起来横向扩展。如果设置了一个节点并将其配置为每秒处理数百MB，则可以将适度的群集配置为每秒处理GB。这就带来了有趣的挑战，即在NiFi和从中获取数据的系统之间进行负载平衡和故障转移。使用基于异步排队的协议（例如消息传递服务，Kafka等）可以有所帮助。使用NiFi的“站点到站点”功能也非常有效，因为它是一种协议，它允许NiFi和客户端（包括另一个NiFi群集）相互交谈，共享有关加载的信息以及交换有关特定授权的数据端口。
Scale-up & down 放大和缩小	NiFi还设计为以非常灵活的方式放大和缩小。从NiFi框架的角度来看，在提高吞吐量方面，可以在配置时在“调度”选项卡下增加处理器上的并发任务数。这允许更多进程同时执行，从而提供更大的吞吐量。另一方面，您可以将NiFi完美缩小，以适合在由于硬件资源有限而需要占用空间小的边缘设备上运行。

08

—

性能调优关注点

A. for io：FlowFile repository and provenance repository配置多个分区，可以加大io的吞吐。

B. for cpu：nifi处理器执行完任务，线程是立刻返回线程池的，并且这个线程池的大小是可配的。这个线程池的合适大小由cpu的内核数决定。对于io密集型任务系统，配置多一些可用线程数是合理的方案。

#查看物理CPU个数
cat proc/cpuinfo | grep "physical id" | sort| uniq| wc -l
#查看每个物理CPU中core的个数(即核数)
cat proc/cpuinfo|grep "cpu cores"| uniq
#总核数 =物理CPU个数 X 每颗物理CPU的核数

个人使用总核数*(2～4)做为线程数比较合理。

C. for rar：NiFi存在于JVM中，因此受到JVM提供的内存空间的限制。JVM垃圾收集对于限制实际堆的总大小，以及优化应用程序随时间运行的情况都是一个非常重要的因素。当定期阅读相同的内容时，NiFi作业可能是I/O密集型的。配置足够大的磁盘以优化性能。

09

—

使用NIFI会遇到的挑战

• 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

  通常不可能在测试环境中完全模拟生产环境。
  
  

10

—