本文主要是介绍Apache Nifi性能测试计划，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
1.概述
1.1 目的
本测试计划为Apache Nifi的性能测试计划，目的在于测试在应用Nifi做为数据接入工具时系统的数据完整性、异常状态下的数据恢复机制以及在不同负载状态下数据的响应时间。
1.2 背景
考虑到大数据管理平台有数据接入量大、数据源多样化、对数据的完整性和容错率要求高、延迟率低等特点，因此计划对Nifi的数据完整性、异常状态下的容错性以及服务器在高负载情况下的性能做一个全面的测试评估，以便于了解nifi的优点和缺陷，从而优化整个大数据管理平台架构。
1.3 范围
本次测试主要是基于现有的数据接入模块业务流程进行测试。
2.测试概要
2.1 测试环境
软件环境：Apache Nifi 0.5.0 版本
开发环境安装路径：
单机版Nifi：slave158(192.168.60.158) /home/yang/nifi_pro/nifi-0.5.0
Nifi集群：
Node1：slave158(192.168.60.158) /home/yang/nifi_pro/nifi-0.5.0
Node2：slave161(192.168.60.161) /home/yang/nifi_pro/nifi-0.5.0
Node3：slave162(192.168.60.162) /home/yang/nifi_pro/nifi-0.5.0
Node4：slave158(192.168.60.158) /home/yang/nifi_pro/nifi-0.5.0_node4
操作系统：liunx
2.2 测试目标
1.数据完整性测试。
2.异常状态容错机制测试。
3.不同负载下的响应时间测试。
4.Nifi集群模式下的主从切换测试。
3.测试方法
3.1 数据完整性测试
1.通过SendGcjlTokafka.2.0工具向kafka发送数据,并记录发送数据条数。
2.等待整个数据处理流程结束后，去gjjl表里面查看数据增长量是否和发送的数据量一致。
3.多次循环上述流程，结果都是一致则说明数据完整，无丢数据情况发生。
4.有不一致状况，排查各个数据处理流程，找出丢失数据原因。
3.2 异常状态下Nifi容错机制测试
1.在数据正常流转时，关闭系统组件或服务，如使kafka宕机，停止Mysql、Hbase服务等，测试数据 是否按照事先配置的“failure”逻辑进行或者是否出现数据堆积和积压。如果积压，测出积压峰值。
2.重新恢复停掉的服务，测试数据流是否自动切换回“success”逻辑。
3.测试在服务宕机状态下积压的数据是否会重新尝试执行正常业务逻辑。
4.异常状态恢复完成后，根据3.1数据完整性测试流程对异常恢复后的数据完整性进行测试。
3.3 不同负载下Nifi的性能测试
1.同样的业务流程在不同的数据量下的性能测试。
如：针对现有的数据采集清洗转发入库流程，测试其在1W，100W，1亿….等数据量下的性能指 数(处 理速度，资源占用率等)
2.同样的数据量在不同业务流程下的性能测试。
如：10W条数据在接入，清洗转换后直接入QPAQ时的性能指数和10W条数据接入，清洗入库， 同时存入Mysql和HBASE并且转发入实时数据处理业务对应的topic时的性能指数。
3.4 集群模式下的主从切换测试
将master节点kill掉，测试slave节点是否能自动切换为master并且正常处理数据。
4.测试环境搭建
4.1 安装包
nifi-0.5.0-bin.tar.gz
官网下载地址：http://nifi.apache.org/download.html 版本Nifi 0.5.0
安装包上传至SNV地址：
//TODO
4.2 Nifi单机版环境搭建
1. 解压 nifi-0.5.0-bin.tar.gz
2.进入配置文件目录
3.配置文件zookeeper.properties
4.修改zookeeper地址和端口(zookeeper集群形式时候配置多个，以server.1,server.2,server.3…形式)
5.保存退出。Nifi默认端口号为8080，如果和服务器上已有的服务冲突，则去nifi.properties配 置文件中修改nifi.web.http.port属性，重新设置端口号。
6.在NIFI_HOME的bin目录下，启动nifi服务。
7.通过host:port/nifi在浏览器中访问nifi,执行相关操作
5.测试结果报告
5.1 单机版数据完整性与性能测试
测试版本：Nifi0.5.0单节点版
数据操作：清洗转换入库
5.1.1 测试结果列表
5.1.2 测试异常截图
5.1.3 测试结论总结
1. 积压数据量越大，数据处理性能越差，处理时间随着数据量的增加呈指数级增长。
2. 数据是否丢失和连接池最大连接数参数以及批量处理SQL的批次条数有关，这个应该是数据处理代码层面的BUG，和Nifi本身无关。nifi的数据完整性在小数据量下还是可以的。大数据量时候对参数优化要求显得比较严格。
3. 数据处理速度和SQL批量处理的批次条数有关，每批处理的越多，处理性能越好。
4. 在积压数据千万时候，处理用时长达3个多小时，所以单机版Nifi性能相对还是还是比较差的。
5.2 集群版数据完整性与性能测试(包含入Hbase和转发实时业务)
测试版本：Nifi0.5.0集群版(4个节点)
数据操作：清洗转换入Mysql库、入hbase并转发实时业务
5.2.1 测试结果列表
| 连接池最大连接数 | SQL批量处理批次条数 | 接入数据量(单位：条) | 入库数据量(gcjl表) | 入库数据量(gcxq表) | gcjl表jlbh去重后条数 | 处理用时 | 是否存在异常 |
| 100 | 2000 | 10,000,000 | 9778692 | 9960377 | 9775688 | 未完成 | 是 |
5.2.2 测试结论总结
1. 接入hbase性能太差，大概效率是8000~10000条/30s，程序启动两个小时，hbase只入了210W进库，剩余780W因为需要等待的时间太长所以直接放弃执行。
2. 正常入Mysql的任务执行结束后，查看数据库，有丢失数据现象。
5.3 集群版数据完整性与性能测试(直接入Mysql和单机版做对比)
测试版本：Nifi0.5.0集群版(4个节点)
数据操作：清洗转换入Mysql库
5.3.1 测试结果列表
5.3.2 测试结论总结
1. 四个节点集群模式Nifi的测试列表结果和单机版对比，性能提升了约2/3，如下表：
2. 集群模式下，对整体业务流程的支持较好。（单机模式1000W数据会有少量丢失，集群模式则不会）
5.4 集群版容错机制测试
1.Nifi自身发生错误： Nifi集群的节点如果有宕机情况，会导致整个集群的任务流程无法启动，主节点挂掉会导致nifi的UI界面不可用。如果在任务执行过程中kill掉某个节点进程，会发生丢失数据情况，必须等待节点重新启动后数据会自动恢复。
2.处理模块发生错误：如：mysql挂掉后，数据会自动在入库操作的上游堆积，等待数据库恢复。数据库恢复后，可以完成自动入库，整体数据无丢失。Kafka挂掉后数据流也会进入等待，直至kafka恢复后数据自动流转。
6.测试结论
1.Nifi的数据完整性还是有保障的，测试中出现的数据丢失问题主要是由于现在的代码层面对入库失败的数据未做处理造成的。
2.Nifi集群的处理性能和稳定性远高于Nifi单机模式。
3.Nifi集群的处理性能和数据冗余量有直接关系，即nifi处理数据主要依赖磁盘IO。
4.Nifi自身的集群容错率较低，并非传统的主从结构，但对数据处理模块中的组件容错率较强。
5.综上所述：
Nifi的主要优点有：
A.可视化的UI界面，各个模块组件之间高度可配置，且每个流程都有监控，可以通过界面直观的看到各个数据处理模块之间的数据流转情况，分析出程序性能瓶颈。
B.数据流可以在UI界面自由拖拽和拓展，各模块之间相互独立，互不影响。
C.可以在处理耗时的地方创建多个处理模块并行执行，提升处理速度。类似于代码中加入了多线程，但相对于修改代码，界面配置操作十分简单。
D.修改方便，任意模块都可以在数据流转过程中随时启停，任意处理模块都可以实现热插拔。数据流流向随时可变。
E. Nifi的对处理模块有对应的retry机制和错误分发机制，且可配置性强。
缺点：
各个步骤中间结果落地导致磁盘IO成为Nifi的瓶颈，这个缺点在数据冗余量越大的时候表现的越明显。
这篇关于Apache Nifi性能测试计划的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
