1檯筆記本 vs 1個Hbase集羣 - AbutionGraph圖數據庫+Flink性能測試

作者 | 閉雨哲

出品 | 圖特摩斯科技（www.thutmose.cn）

 

AbutionGraph是圖特摩斯自研的時序圖數據庫，它可以滿足永不掉線的實時知識圖譜指標計算任務以及歷史數據分析，靜態圖+動態圖+時序圖同時存儲。在面向大規模在線場景時，使用Flink技術做ETL的同時，保證數據接入更穩定且無丟失。

目錄：

1. 測試目的
2. 業務場景
3. 測試過程
4. AbutionGraph v.s Hbase

 

一、測試目的

測試AbutionGraph單節點實時讀寫TPS的極值，確定AbutionGraph實時讀寫性能。

測試AbutionGraph在低核數低內存環境下持續運行的穩定性。

 

二、測試環境

2.1 硬件信息

機器	小米筆記本Pro
CPU	8核 Intel® Core™ i7-8550U CPU @ 1.80GHz
RAM	8G（除去使用谷歌瀏覽器、IDEA代碼編輯器、文件瀏覽器、文本編輯器所佔內存剩餘）

2.2  軟件信息

計算機系統	Linux Ubuntu18.04
JDK	1.8u211
AbutionGraph	1.0.2
Flink	1.9.1
RocketMQ	4.5.2
Hadoop	3.2.1

 

2.3  軟件配置信息

Hadoop：單節點僞分佈式部署

Flink：單節點嵌入式，程序使用單線程

RocketMQ：單節點同時部署mqnamesrv和mqbroker，各佔用1G內存

AbutionGraph：單節點同時部署集羣監控、資源監控、數據計算、RestAPI等服務

 

三、模擬場景

一個在線交易系統，人與人的轉賬交易數據實時計算並存儲。這是一種靜態圖+動態圖的多維度圖存儲方式。

圖結構信息：

實體“人”具有1個靜態維度和1個動態維度數據：

1. 靜態維度BasicEntityPerson具有jymc（交易名稱）屬性；
2. 動態維度SuperEntityPerson具有zzPeople（轉賬過的人集合）和zzCount（轉賬過的人數）屬性，代表所有歷史數據的實時彙總更新；

關係“交易”具有1個靜態維度和1個時序維度數據：

1. 靜態維度BasicEdgeJiaoYi保存交易的基本信息jysj（交易時間）和jyje（交易金額）
2. 動態維度SuperEdgeJiaoYi具有day（存儲“年月日”爲時序數據分區）和zje（兩個人之間每天的歷史交易金額實時彙總計算並存儲）屬性。

 

實時數據樣本：

數據字段：行標，（匯款人，匯款人名稱，被匯款人，被匯款人名稱，匯款日期，匯款金額）

 

四、測試過程

24小時不間斷：

數據生產（RocketMQ）-->數據消費（Flink）-->數據入庫（Flink）-->AbutionGraph-->數據查詢

所有的大數據技術軟件都啓動在筆記本上，AbutionGMS資源監控系統與Linux系統自帶監控（剩餘內存一致）附圖：

 

4.1 數據生產

單線程中每秒生產200~6w條數據並不定時寫入AbutionGraph。數據生產程序將在IDEA中持續運行。

RocketMQ數據生成核心代碼：

DefaultMQProducer producer = new DefaultMQProducer("p004");
producer.setNamesrvAddr("localhost:9876");
try {
    producer.start();
} catch (MQClientException e) {
    e.printStackTrace();
}
for (int i = 0; i < 200000000; i++) {
    Random random = new Random();
    DecimalFormat b20 = new DecimalFormat("00");
    DecimalFormat b50 = new DecimalFormat("00000");
    String num1 = b50.format(random.nextInt(99999));
    String num2 = b50.format(random.nextInt(99999));
    String data = num1+",ID_"+num1+ "," +num2+",ID_"+num2 +
        ",2020-"+b20.format(random.nextInt(11)+1)+"-"+b20.format(random.nextInt(30)+1)+" " + 
b20.format(random.nextInt(24))+":"+b20.format(random.nextInt(59))+":"+b20.format(random.nextInt(59))+"," +
        random.nextInt(100)+".0";
    Message msg = new Message("flink-source", "", "id_" + i, data.getBytes());
    try {
        producer.send(msg);
    } catch (Exception e) {
        e.printStackTrace();
    }
    System.out.println("["+i+"]: "+ data);
    try {
        Thread.sleep(1);
    } catch (InterruptedException e) {
        e.printStackTrace();
    }
}

 

4.2 數據消費

數據採用不定時長間隔消費，以製造真實環境中的突然大流量峯值。我們使用大數據技術Flink實時接入數據（AbutionGraph接口）並做一定數據處理，將接收到的每一條數據拆分爲3個實體（源點/終點/實時統計的源點）2條關係（靜態數據邊/實時統計的動態邊），即將1條原始數據擴展爲5條圖數據同時入庫，並對原始數據中的字段處理成指定的數據類型，如將字符串日期處理成Date格式並存儲到AbutionGraph。

 

4.3 數據入庫

數據入庫的分別對3個靜態維度+1個時序維度的圖（即常見的數據圖譜+1個時序屬性）和2個靜態維度+2個動態維度的圖（即常見的數據圖譜+1個動態維度和1個時序維度圖屬性隨數據流入而實時計算並更新）進行性能測試。

靜態+時序測試圖：

（2個靜態實體維度、1個靜態關係維度、1個時序關係維度）

高峯入庫過程，使用RocketMQ每秒生成1k數據，使用Flink不定間隔時長消費RocketMQ中的數據並導入AbutionGraph。圖內已存在數據量>9千萬，且持續入庫，系統健康運行>3天（同時開網頁優酷看電影）。

實時入庫峯值：17w/s

 

 

靜態+動態+時序測試圖：

（1個靜態實體維度、1個動態實體維度、1個靜態關係維度、一個時序關係維度）

高峯入庫過程，使用RocketMQ每秒不定間隔生成1k或1w數據，使用Flink不定間隔時長導入數據到AbutionGraph。圖內已存在數據量>5千萬，且持續入庫。

實時入庫峯值：17w/s

當數據過億之後：

實時入庫峯值：15w/s

總結：

動態指標維度需要根據歷史數據進行實時計算並取庫，隨着動態維度的增加，不會因此降低寫入速率，兩個測試圖寫入速率基本保持一致，最高峯值都達到了驚人的17w/s。

 

四、數據查詢

使用1.3億數據圖，因爲筆記本剩餘空間是3.5G，可用內存只有不到1G，所以在此不做大量查詢。

1跳查詢（查詢實體"62016"）：毫秒返回252條數據

2跳查詢（查詢實體"62016"）：1s/並返回可視化數據502條

3跳查詢（查詢實體"62016"）：1.4s/並返回可視化數據9638條（下圖最短的藍柱狀）

6跳查詢（查詢實體"62016"）：22s/並返回可視化數據38991條（下圖最長的後2根藍柱狀）

Ps：一般的圖庫在億級數據已經很難完成6跳的查詢了，因爲多跳數據查詢不涉及屬性的過濾操作，所以不需要大規模的數據掃描操作即可快速定位到數據。

 

我們來看看掃描全部數據，過濾出每天交易金額大於100元的邊（由於可用內存原因做了條數限制）：

掃描速率：20w/s

 

五、AbutionGraph v.s Hbase

爲了體現對比權威性，我們使用Hbase技術社區發佈的測試報告，且爲目前Hbase最高的2.2版本。該Hbase測試結果也爲全網的最高水平，網絡查找到的一些測試報告可能因爲版本和配置不同要遠低於此水平。

	AbutionGraph	Hbase
CPU	8核	112核
RAM	8G（可用4G）	312G
網絡	公用WIFI	網易內網
操作系統	Ubuntu	Debian
實例數	1個	4個
單節點穩定吞吐	13w/s	3.5w/s（集羣14w/s）
單節點最高峯值	17w/s	3.5w/s（集羣14w/s）
測試時間	2020.03	2020.01

 

對比文章：

HBase 2.2隨機讀寫性能測試：https://thutmose.blog.csdn.net/article/details/104554739

Cassandra3.11讀寫性能測試（6臺集羣6w/s）：https://thutmose.blog.csdn.net/article/details/104670119

 

六、總結

本測試可能是有史以來配置最低的大數據技術性能測試了，結果比較令人欣喜，期間查看日誌信息可以看到好幾次警告內存過低，但整套大數據生態系統都還能穩定的運行下去。在此測試中使用的Flink並沒有啓動，而是使用AbutionGraph接口中嵌入式的方式運行，集羣模式下性能更佳。業務合作與技術人才投遞郵箱： [email protected]