常用序列化方案比較

• 2020 年 5 月 7 日
• 筆記

當你感到悲哀痛苦時，最好是去學些什麼東西。學習會使你永遠立於不敗之地。

使用場景

在rdd的每一個分區上，執行迭代操作，在每一次的迭代操作中，需要先訪問redis快取，並獲取key對應的value，若value存在則對value進行反序列化操作，否則從db里查詢並序列化存放到redis快取中。

偽程式碼如下：

rdd.mapPartitions {
  iter.map{
    val value:Option[Array[Byte]] = getValueByKey(key)
    value match {
       case Some(bs) => {
                           deserilialize(bs);
                           other operations...
                         }
       case None => {
                       val newVals = fetchFromDbByKey(key);
                       other operations ....;
                       val newBs = serialize(key);
                       storeRedis(newBs)
                     }
    }
  }
}

從這段位程式碼可以看出，影響效率的有序列化和反序列化的效率以及序列化後byte數組的位元組大小（可以影響網路IO）。

測試指標

主要從四方面來考慮，序列化總時間，反序列化總時間，序列化後平均位元組大小，cpu使用率峰值。

其中，使用jconsole監控其cpu使用率峰值。

注意，cpu使用率的峰值只是一個參考，因為在數據量增大時，在序列化和反序列化過程中，伴隨著gc，也會消耗cpu資源。

測試數據

//github.com/Devskiller/jfairy.git 是用來生成測試數據的，可以支援多國語言，由於其本身不是用來測試序列化的數據集，其生成的對象也不是完全可序列化的，欄位也多，也包含了一下二級欄位，故簡化之。

簡化之後的數據結構如下：

生成測試數據程式碼如下：

package com.wisers;
 
import com.devskiller.jfairy.Fairy;
import com.devskiller.jfairy.producer.person.Person;
 
import java.util.ArrayList;
import java.util.Locale;
 
public class DataGenerator {
    public static ArrayList<People> generatePeople(int sampleNum) {
        Fairy chineseFairy = Fairy.create(Locale.CHINESE);
        Fairy englishFairy = Fairy.create(Locale.ENGLISH);
        ArrayList<People> people = new ArrayList<People>(sampleNum);
        for (int i = 0; i < sampleNum; i++) {
            Person person = Math.random() >= 0.5 ? chineseFairy.person() : englishFairy.person();
            people.add(People.createBy(person));
        }
        return people;
    }
}

測試環境

測試方案

儘可能地重用流對象，避免新創建對象對結果的影響
儘可能地避免gc對序列化和反序列化的影響，每次序列化反序列化之後都手動gc，並且測試數據集不宜過大，目前設定最大為1kw，儘可能避免gc對結果的影響
在測試操作過程中，避免列印以及磁碟讀取存放等io操作，序列化後的數據直接放在記憶體，供反序列化使用。

測試結果

下面開始對比業內的比較認可的幾種序列化方案。

序列化方案對比結果如下：

不同數據集下各個序列化方案對比

對比結果如下：

結果分析

時間角度分析

1. 由於jdk本身在序列化和反序列化時，ObjectOutputStream、ByteArrayInputStream以及ObjectInputStream不能復用，序列化時間會包含部分對象創建的時間，這會增加gc時間
2. msgpack在序列化過程中，MessageUnpacker不能復用，並且需要手動創建類，反序列化時間會比序列化時間長
3. hession在反序列化過程中，流不能復用，反序列化時間會比較長
4. kryo、fst、protoStuff 在序列化和反序列化的過程中，很好的使用了流復用，序列化效果比較好
5. 整體來看，同一種序列化方案，反序列化消耗時間會比序列化消耗時間長，多了對象的創建以及欄位映射時間
6. 數量級達到百萬級後，使用protoStuff、fst以及kryo效果比較好，整體時間消耗依次為 protoStuff < kryo < fst

序列化後位元組大小分析

1. 整體大小如下：msgpack < protoStuff < kryo < fst < hession < jdk
2. msgpack需要手動序列化欄位，並不包含類資訊，故序列化後的結果比較小

最大堆記憶體對序列化時間的影響

默認最大堆記憶體約為7.7g，由於序列化後的數據被存放在記憶體，不能被gc回收，數據量達到1kw 時，出現記憶體溢出異常，故調大堆記憶體，對比在1kw 數據量時最大堆記憶體對序列化和反序列化的影響。

結果分析

當數據量在 1kw時，增大最大堆記憶體，對不能使用流復用技術的 jdk、hession影響比較大，影響為幾秒，但整體時間影響並不大，對於其他序列化方案影響在毫秒級，幾乎不影響。

分析總結

綜合考慮序列化和反序列化時間以及序列化後的大小來看，優先使用 protoStuff 、 kryo 以及 fst 。