Nifi简单入门
准备和资料
参看
Apache NiFi
Apache NiFi Documentation
Explore - Docker Hub
Apache NiFi - Wikipedia
Flow-based programming - Wikipedia
Low-code development platform - Wikipedia
How An Arcane Coding Method From 1970s Banking Software Could Save The (fastcompany.com)
Apache NiFi如何工作？
环境
Docker(Docker Desktop for Windows 10)
Sub Linux(Ubuntu)
Linux(Centos 8)
Nifi基础
概念
Nifi
用来处理数据集成场景的分发，是一种BS结构的程序
- 高可用
- 高性能
- 纠察错误
- 快速响应
- 高兼容性
- 安全性
- 便于在系统间传递数据
FBP
流式编程
惰性求值
也叫做Call By Need（传需求调用），目的是尽可能减少CPU处理的任务
SEDA
Staged Event-Driven Architecture（分段事件驱动架构）
分阶段设计模式，将一个请求的过程分为多个Stage，每个Stage使用相应的线程数量来进行处理，每个Stage之间则通过Asynchronize Event-Driven方式进行通信
Backpressure
背压，当生产者生产数据的速度超过消费者消费的速度，就会产生背压；例如测试提的Bug过快，开发者来不及修改完成
解决方案分为两种：有损背压和无损背压
有损背压指的是压制生产者生产数据的速度，比如限制测试提出不影响主流程的Bug
无损背压
将数据记录，之后再进行处理（Buffer）
buffer/when
有损背压
限制生产者的速度
debounce/throttle/audit/sample
抛弃部分包
Flow File
信息包，是在Nifi中移动的所有对象，包含attribute和content两部分组成，nifi会记录每个flow file的一个attribute键值对和0到多个content
整个Flow File可以被看着是一个TCP报文（近似）
其中，TCP中的Data就是Nifi Flow File中的Content，而其报文头和脚部就可以看做Flow File的Attribute（元数据）
Processor
处理器，在FBP中也被称为黑盒，相当于不同系统间的数据路由，处理器可以访问Flow File的属性和内容，并对其进行操作
Connection
链接，在FBP中也被称为缓冲区，它负责链接不同的Processor，允许各种进程通过不同的速率进行通信，也可以限制生产者和消费者之间的速率，从而消除背压；相当于链接 + 队列 + 限流器
如果设置了阈值，那么如果数据符合范围则正常执行
如果超过限制，则会通过背压（Backpressure）的形式暂停生产者（P1）
系统会等待P2处理数据，在此之前P1不会被调度；如果P2处理完成了部分数据，使得链接中的数据符合阈值，那么会再次调用P1
事实上Nifi的背压机制是“无损背压”，或者说超越的数据会被“交换”到一个Cache中
Controller
流控制器，在FBP中被称为调度器，负责管理和分配流程使用的线程，在系统中充当代理的角色
Process Group
进程组，由多个Processor和Connection组成，可以通过输入端口传入数据，通过输出端口发送数据，是一组级联的关系
如果我们将一个Processor看着
优势
- 允许处理大量数据
- 允许处理多种类型数据
- 执行速度高
- 数据质量高（准确率高）
Nifi架构
Web Server
Web 服务器
承载了Nifi基于Http的命令和API
Flow Controller
流控制器
整个操作的核心，为要执行的组件提供线程，管理调度
Extensions
扩展
有各种类型的Nifi扩展，并可以被加载到JVM中进行执行
FlowFile Repository
状态数据库
流文件存储库，负责保存FlowFile的Status History，类似于Photoshop中的历史记录，注意，这三个Repository都具有不变性（只读），因此只能追加，不可修改。
Content Repository
内容存储库
内容存储库，负责存储FlowFile中实际的内容，注意，这三个Repository都具有不变性（只读），因此只能追加，不可修改。如果对内容进行了修改，会再创建一份新的内容，并将指针返回，这也是为什么Nifi可以回溯到之前的状态，这种形式有点类似于Java中的String，他的值都是final的，但仍然可以不显性的修改内容，当然其中的内容并没有发送改变，改变的只是指针（引用）。
可以把FlowFile看做一个*指针，而指针是不存放数据的，数据都会被存放在Content Repository中
Provenance Repository
源头存储库（事件存储库）
用于存储所有的事件，注意，这三个Repository都具有不变性（只读），因此只能追加，不可修改。
每次修改FlowFile时，都会拍摄FlowFile的Attribute和Content，这允许用户通过Provenance Repository来迅速回溯到指定的时间点（时光机）
和FlowFile Repository相似，但Provenance Repository存储的是Event（事件）的快照，根据这个快照可以快速的回溯到某个特定的时间点
Nifi集群
Cluster Coordinator
集群协调器，用于管理节点添加和删除的操作逻辑
Primary Node
主节点，用于运行不适合在集群中执行的组件（如读取文件）（注意，NIFI集群是零主模式，因此没有特别核心的功能）
Zookeeper Client
Zookeeper节点
Nifi入门
部署
Docker
docker run -p 7379:7379 -p 6379:6379 --name redis -v /usr/local/docker/redis.conf:/etc/redis/redis.conf -v $PWD/data:/data -d redis redis-server /etc/redis/redis.conf --appendonly yes --requirepass 980208
界面
主界面
Nifi和SRPA Designer的对比
- SRPA系统重点是功能的实现，Nifi的重点是数据的处理
- SRPA中，Processor被称为Block
- SRPA中，Connection被称为Order，且不明显要求Data Flow
- SRPA中，Status History被系统通过ini方式管理，而在Nifi中被当做快照存储在两个Repository中
- SRPA可以将Nifi集成，并形成一个新的抽象化组件（Data Processor），该组件仍然被称为Block，但问题是可能会有过多的嵌套