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.1 測試目标
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 測試結果清單
連接配接池最大連接配接數 SQL批量處理批次條數 接入資料量(機關：條) 入庫資料量(gcjl表) 入庫資料量(gcxq表) gcjl表jlbh
去重後條數 處理
用時 是否存在異常
10 100 100,000 99,904 100,000 99,904 2m30s 是
10 100 1,000,000 941,251 899,016 899,033 32m43s 是
10 100 1,000,000 999,952 999,113 999065 28m38s 是
10 1000 100,000 100,000 100,000 100,000 1m34s 否
10 1000 1,000,000 1,000,000 998,992 998,992 16m35s 否
50 1000 100,000 100,000 100,000 100,000 1m43s 否
50 1000 1,000,000 1,000,000 999,287 999287 13m16s 否
100 2000 100,000 100,000 100,000 100,000 1m38s 否
100 2000 1,000,000 1000000 999435 999435 17m10s 否
100 2000 10,000,000 9,992,478 9,985,039 9,982,851 3h23m10s 是
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 測試結果清單
連接配接池連接配接數 SQL批量處理批次條數 接入資料量(條) 入庫資料量(gcjl表) 入庫資料量(gcxq表) gcjl表jlbh
去重後條數 處理
用時 是否存在異常
100 2000 10,000,000 10,000,000 9980135 9980135 1h18m30s 否
100 2000 10,000,000 10,000,000 9,992,638 9,992,638 63m 否
100 2000 1,000,000 1,000,000 999,141 999,141 5m26s 否
100 2000 1,000,000 1,000,000 999,345 999,345 5m18s 否
100 2000 100,000 100,000 100,000 100,000 29s 否
100 2000 100,000 100,000 100,000 100,000 28s 否
5.3.2 測試結論總結
1. 四個節點叢集模式Nifi的測試清單結果和單機版對比，性能提升了約2/3，如下表：
接入資料量 單機模式 四個節點的叢集模式 單機平均處理速度 叢集平均處理速度
10W 1分38秒 28秒，29秒 1020條/s 3508/s
100W 17分10秒 5分26秒，5分18秒 980條/s 3105/s
1000W 203分10秒 78m30s,63m 821條/s 2355/s
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的瓶頸，這個缺點在資料備援量越大的時候表現的越明顯。