1.1 背景介绍
2006年NiFi由美国国家安全局(NSA)的Joe Witt创建。2015年7月20日,Apache 基金会宣布Apache NiFi顺利孵化成为Apache的顶级项目之一。NiFi初始的项目名称是Niagarafiles,当NiFi项目开源之后,一些早先在NSA的开发者们创立了初创公司Onyara,Onyara随之继续NiFi项目的开发并提供相关的支持。Hortonworks公司收购了Onyara并将其开发者整合到自己的团队中,形成HDF(Hortonworks Data Flow)平台。2018年Cloudera与Hortonworks合并后,新的CDH整合HDF,改名为Cloudera Data Flow(CDF),并且在最新的CDH6.2中直接打包,而Apache NiFi就是CFM的核心组件。
1.2 什么是Apache NiFi
Apache NiFi 是一个易于使用、功能强大而且可靠的数据处理和分发系统。Apache NiFi 是为数据流设计,它支持高度可配置的指示图的数据路由、转换和系统中介逻辑,支持从多种数据源动态拉取数据。简单地说,NiFi是为自动化系统之间的数据流而生。 这里的数据流表示系统之间的自动化和受管理的信息流。 基于WEB图形界面,通过拖拽、连接、配置完成基于流程的编程,实现数据采集、处理等功能。
传统的数据流解决方案往往会遇到以下的挑战:
-
系统错误
包括网络错误、硬盘错误、软件崩溃,甚至是人为错误,造成了数据流处理的不稳定性。
-
数据访问超过处理消费的能力
当数据处理模块有某一瓶颈时,往往不能够及时处理到达的数据。
-
异常数据处理
不可避免会出现数据太大,数据碎片,数据传输太慢,数据损坏,问题数据以及及数据格式错误。
-
业务快速演进
快速处理业务的调整,快速启用新flow以及改造已有的flow。
-
多系统升级不同步引入的前后兼容
原有系统的协议和数据格式,会伴随系统的升级有一定的调整,同时单个系统的升级会影响周边系统。数据流可以把多个大型分布式系统串边在一起,这些系统可以是松散地,甚至设计之初就没考虑未来集成。
-
合规与安全
法律法规的变更,规章制度的变动,以及政策调整,业务条款的变更。系统和系统之间,系统和用户接口之间要安全,可信和权责分明。
-
持续改进生产系统
在实验室环境很难复制生产环境。从生产系统复制数据到实验室环境或者在实验室环境重现生产系统的问题?
多年来,数据流(dataflow)一直是架构中的痛点之一。而现在有越来越多事物的兴起让企业开始重视数据流,包括:面向服务的体系结构(SOA),API,物联网IOT和大数据。此外,合规性,隐私性和安全性所需的严格程度也在不断提高。对于这些新鲜事物或概念,数据流的需求大致相同,主要区别在于复杂性,适应业务变化的速度,以及大规模边缘用例。NiFi旨在帮助解决这些现代数据流挑战。
1.3 NiFi的核心概念
NiFi的基本设计理念是基于数据流的编程 Flow-Based Programming(FBP)。应用是由处理器黑盒、连接器组成的网络。数据进入一个节点,由该节点对数据进行处理,根据不同的处理结果将数据路由到后续的其他节点进行处理。这是NiFi的流程比较容易可视化的一个原因。以下是NiFi的概念,以及和FBP相对应内容。
参照上述表格,简单来讲
-
FlowFile 是在各个节点间流动的数据;
-
FlowFile Processor 是数据的处理模块;
-
Connection是各个处理模块间的一个队列;
-
Flow Controllers是复杂流程的调度;
-
Process Group封装流程的层次关系。
这种设计模式和seda架构类似,带来了很多好处,帮助NiFi成为构建强大的可扩展数据流高效的平台,包括:
- 适用于可视化的创建和管理Processor。
- 本质上是异步的,即使在处理和流量波动时也允许非常高的吞吐和自然缓冲。
- 提供高并发的模型,让开发人员不用担心如何实现复杂的并发。
- 帮助高度聚合和松散耦合组件的开发,让这些组件可以在其他环境复用,并帮助单元测试。
- 资源受限的connection使得背压和压力释放等关键功能非常自然和直观。
- 错误处理做的非常好,而不是粗粒度的一把抓。
- 数据进入和退出系统以及如何流过的点很容易理解和轻松跟踪。
1.4 NiFi架构
NiFi是基于Java的,NiFi的核心部件在JVM里的位置如上图所示:
-
Web Server
承载NiFi基于HTTP的命令和控制API。
-
Flow Controller
是NiFi执行具体操作的大脑,负责从线程资源池中给Processor分配可执行的线程,以及其他资源管理调度的工作。
-
Extensions
在其他文档中会专门介绍各种类型的NiFi扩展,重点是这些扩展也是在JVM中运行的。
-
FlowFile Repository
负责保存在目前活动流中FlowFile的状态,其功能实现是可插拔的。默认的方式是通过一个存储在指定磁盘分区的持久预写日志(WAL),来实现此功能。
-
Content Repository
负责保存在目前活动流中FlowFile的实际字节内容,其功能实现是可插拔的。默认的方式是一种相当简单的机制,即存储内容数据在文件系统中。多个存储路径可以被指定,因此可以将不同的物理路径进行结合,从而避免达到单个物理分区的存储上限。
-
Provenance Repository
负责保存所有跟踪事件数据,同样此功能是可插拔的,并且默认可以在一个或多个物理分区上进行存储,在每个路径下的事件数据都被索引,并且可被查询。
当然NiFi也支持以集群方式部署
从NiFi 1.0版本开始,NiFi采用Zero-Master集群模式。NiFi集群中的每个节点都对数据执行相同的任务,但每个节点都运行在不同的数据集上。Apache ZooKeeper选择其中一个节点作为集群协调器,故障转移由ZooKeeper自动处理。所有集群节点都会向集群协调器报告心跳和状态信息。集群协调器负责断开和连接节点。作为DataFlow管理器,您可以通过集群中任何节点的UI与NiFi集群进行交互。您所做的任何更改都会复制到集群中的所有节点,从而允许多个入口点进入集群。
1.5 NiFi的性能期望和特性
NiFi旨在充分利用底层服务器的能力,最大化使用CPU和磁盘这种资源特别有优势。更多其他信息可以参考官网文档中的“Administration Guide”。
1.5.1 For IO
期望的吞吐或时延与实际情况可能会存在很大的差异,这取决于系统的配置方式。鉴于大多数主要NiFi子系统都是可插拔式的,性能取决于部署实施的方式。对于通用需求建议使用开箱即用的默认实现。使用本地磁盘对于所有子系统都可以持久化保存数据,从而保证交付。保守一点假设一台典型的服务器上的一般磁盘或者RAID卷大约每秒50MB的读写速率。则NiFi中的较大类型的数据流可以达到每秒100MB或者更高的吞吐。这是因为添加到NiFi的每个物理分区和content repository会呈线性增长。这将在FlowFile repository和provenance repository的某个点上出现瓶颈。我们计划在搭建时提供一个基准测试和性能测试模板,允许用户轻松测试他们的系统并确定瓶颈在哪里。此模板还应使系统管理员可以轻松进行更改并验证其影响。
1.5.2 For CPU
Flow Controller充当引擎,指示特定Processor何时被赋予执行线程。Processor被设计为一旦执行任务完成立即返回线程。Flow Controller有一个配置项,用以表明它维护的各个线程池的可用线程。理想的线程数取决于服务器的CPU核的数量,系统是否正在运行其他服务,以及flow中的处理性质。对于典型的IO很重的flow,使许多线程可用是合理的。
1.5.3 For RAM
NiFi运行在JVM中,因此受限于JVM提供的内存空间。JVM的GC对于限制总实际堆大小以及优化应用程序运行时间是一个非常重要的因素。定期阅读相同内容时,NiFi作业可能是I/O密集型的。配置足够大的磁盘以优化性能。
1.6 NiFi的关键特性
1.6.1 Flow Management
-
保证交付
NiFi的核心理念是即使在非常大的规模下,保证交付也是必须的。这是通过有效使用专用的持久性预写日志(WAL)和content repository来实现的。它们的设计可以实现非常高的事务处理,高效的负载分散,写入时复制以及发挥传统磁盘读/写的优势。
-
基于背压的数据缓冲和背压释放
NiFi支持所有排队数据的缓冲以及当这些队列达到指定限制时提供背压的能力,或者指定过期时间。
-
优先排队
NiFi允许设置一个或多个优先级方案,用于数据如何在队列中被检索。默认情况下,是先进先出的处理策略。也可以设置成后进先出、最大先出,或者其他的处理策略。可以为每一个connection配置队列的优先级。
-
流式QoS保障
经常有一些数据是非常重要的不能够丢失,以及需要进行低延迟处理的。NiFi能够为这些数据流提供QoS保障服务。
1.6.2 易于使用
-
可视化命令与控制
数据流的处理有时非常复杂,因此提供一个可视化的数据流展现与编辑功能,使得用户在编辑和处理数据流时更加直观,从而提升使用效率。当用户在数据流上做出修改时,这个更改将立即在实际中产生作用。并且,用户在进行局部修改时,不需要停止整个流处理过程。
-
流程模板
由于数据流是高度面向模式的,并且在解决一个问题时会有多种不同的方式,能够共享一些好的通用处理模板将对用户会有很大的帮助。模板功能允许用户构建、发布设计模板,并共享给其他人。
-
数据跟踪
NiFi自动记录、索引对于数据流的每个操作日志,并可以把可用的跟踪数据作为对象在系统中传输。这些信息能够在系统故障诊断、优化等其他场景中发挥重要作用。如下图所示为一个数据流的数据跟踪记录。
-
记录/恢复细粒度的历史数据
NiFi的content repository被设计成历史滚动缓冲区的角色。数据仅仅在超时或者空间不足时被从content repository中删除。此项功能与数据跟踪功能一起,可以提供一项非常有用的基础功能,即用户能够对中间过程的内容进行下载和回放。
1.6.3 安全
-
系统间
NiFi可以通过双向SSL进行数据加密。并且可以允许在发送与接收端使用共享秘钥,及其他机制对数据流进行加密与解密。
-
用户与系统间
NiFi允许双向SSL认证,并且提供可插入式授权模式,因此可以控制用户的登录权限(例如:只读权限、数据流管理者、系统管理员)。如果用户在flow中输入敏感信息(如密码),则会立即加密服务器端,即使是加密形式也不会再暴露在客户端。
-
多租户授权
指定数据流的权限适用于每个组件,允许管理员用户具有细粒度的访问控制。这意味着每个NiFi集群都能够处理一个或多个组织的要求。与隔离方式相比,多租户授权支持数据流管理的自助服务模型,允许每个团队或组织在完全了解流的其余部分的情况下管理流,而无法访问流。
1.6.4 可扩展架构
-
扩展
NiFi的核心是为扩展而构建的,因此它是一个数据流进程可以以可预测和可重复的方式执行和交互的平台。 扩展点包括:处理器,控制器服务,报告任务,优先级排序器和用户界面。
-
类装载器隔离
对于任何基于组件的系统,随着规模的扩张,组件之间的依赖会越来越错综复杂。为了解决这个问题,NiFi通过提供自定义类装载器模型,来确保每个扩展组件之间的约束关系被限制在非常有限的程度。因此,在创建扩展组件时,就不用再过多关注其是否会与其他组件产生冲突。
-
Site-to-Site通信协议
NiFi实例之间的首选通信协议是NiFi Site-to-Site(S2S)协议。S2S可以轻松,高效,安全地将数据从一个NiFi实例传输到另一个实例。NiFi客户端库可以轻松构建并捆绑到其他应用程序或设备中,以通过S2S与NiFi进行通信。S2S中支持基于socket的协议和HTTP(S)协议作为底层传输协议,使得可以将代理服务器嵌入到S2S通信中。
1.6.5 灵活的缩放模型
-
横向扩展(集群)
如上所述,NiFi可以通过将许多节点聚集在一起以集群的方式实现横向扩展。如果单节点被配置为每秒处理数百MB的数据,则集群方式可以达到每秒处理GB级别。这就带来了NiFi与其获取数据的系统之间的负载均衡和故障转移的挑战。使用基于异步排队的协议(如消息服务,Kafka等)可以提供帮助。使用NiFi的“site-to-site”功能也非常有效,因为它是一种协议,允许NiFi和客户端(包括另一个NiFi集群)相互通信,共享有关加载的信息,以及交换特定授权的数据端口。
-
放大和缩小
NiFi还可以非常灵活地放大和缩小。从NiFi框架的角度来看,如果要增加吞吐,可以在配置时增加“Scheduling”选项卡下processor的并发任务数。这允许更多进程同时执行,从而提供更高的吞吐。 另一方面,您可以完美地将NiFi缩小到适合在边缘设备上运行,因为硬件资源有限,所需的占用空间很小。要专门解决第一英里数据收集挑战和边缘用例,您可以使用MiNiFi,参考:
https://cwiki.apache.org/confluence/display/NIFI/MiNiFi
也是Cloudera Data Flow(CDF)中的另一个核心套件Cloudera Edge Management(CEM),参考《0603-Cloudera Flow Management和Cloudera Edge Management正式发布》。
因为NiFi可以对来自多种数据源的流数据进行处理,Cloudera认为CFM非常适合用于物联网(IoT)的数据处理。NiFi并非只能用于物联网,实际上,它可以用于所有种类的实时数据处理,比如预测分析、欺诈检测、大数据注入、资源评估等等。NiFi项目自身提供了200多个数据处理器(Data Processors),这其中包括了数据的编码、加密、压缩、转换、从数据流创建Hadoop的序列文件、同AWS交互、发送消息到Kafka、从Twitter上获取消息,以及其它等等。你可以在拖放风格的可视化界面上来配置这些数据处理器,把它们链接到一起,并在它们之间使用背压机制来进行流控。NiFi还提供了内置的自动扩展、请求复制、负载均衡和故障切换机制。