описание

у нас есть кластер Hadoop, на котором мы храним данные, которые сериализуются в байты с помощью Kryo (инфраструктура сериализации). Версия Kryo, которую мы использовали для этого, была разветвлена с официального релиза 2.21, чтобы применить наши собственные патчи к проблемам, которые мы испытали с помощью Kryo. Текущая версия Kryo 2.22 также устраняет эти проблемы, но с разными решениями. В результате мы не можем просто изменить версию Kryo, которую мы используем, потому что это это означает, что мы больше не сможем читать данные, которые уже хранятся в нашем кластере Hadoop. Чтобы решить эту проблему, мы хотим запустить задание Hadoop, которое

1. считывает данные, хранящиеся
2. десериализует данные, хранящиеся в старой версии Kryo
3. сериализует восстановленные объекты с новой версией Kryo
4. записывает новое сериализованное представление обратно в наше хранилище данных

проблема что нетривиально использовать две разные версии одного и того же класса в одной программе Java (точнее, в классе сопоставления задания Hadoop).

вопрос в двух словах

как можно десериализовать и сериализовать объект с двумя разными версиями одной и той же структуры сериализации в одном задании Hadoop?

обзор соответствующих фактов

• у нас есть данные, хранящиеся в кластере Hadoop CDH4, сериализованные с версией Kryo 2.21.2-ourpatchbranch
• мы хотим сериализовать данные с Kryo версии 2.22, что несовместимо с нашей версией
• мы строим наши банки работы Hadoop с Apache Maven

возможные (и невозможные) подходы

(1) переименование пакетов

первым подходом, который пришел нам на ум, было переименование пакетов в нашем собственном филиале Kryo с помощью функциональность перемещения тени Maven плагин и отпустите его с другим идентификатором артефакта, чтобы мы могли зависеть от обоих артефактов в нашем проекте задания преобразования. Затем мы создадим экземпляр одного объекта Kryo как старой, так и новой версии и используем старый для десериализации и новый для сериализации объекта снова.

проблемы
Мы не используем Kryo явно в заданиях Hadoop, а скорее получаем доступ к нему через несколько уровней наших собственных библиотек. Для каждой из этих библиотек было бы необходимо

1. переименовать пакетов и
2. создайте выпуск с другой группой или идентификатором артефакта

чтобы сделать вещи еще более грязными, мы также используем сериализаторы Kryo, предоставленные другими сторонними библиотеками, для которых нам пришлось бы сделать то же самое.

(2) Использование нескольких загрузчиков класса

второй подход, который мы придумали, состоял в том, чтобы вообще не зависеть от крио в проекте Maven который содержит задание преобразования, но загружает необходимые классы из JAR для каждой версии, которая хранится в распределенном кэше Hadoop. Сериализация объекта будет выглядеть примерно так:

public byte[] serialize(Object foo, JarClassLoader cl) {
    final Class<?> kryoClass = cl.loadClass("com.esotericsoftware.kryo.Kryo");
    Object k = kryoClass.getConstructor().newInstance();
    ByteArrayOutputStream baos = new ByteArrayOutputStream();
    final Class<?> outputClass = cl.loadClass("com.esotericsoftware.kryo.io.Output");

    Object output = outputClass.getConstructor(OutputStream.class).newInstance(baos);
    Method writeObject = kryoClass.getMethod("writeObject", outputClass, Object.class);
    writeObject.invoke(k, output, foo);
    outputClass.getMethod("close").invoke(output);
    baos.close();
    byte[] bytes = baos.toByteArray();
    return bytes;
}

проблемы
Хотя этот подход может работать для создания экземпляра неконфигурированного объекта Kryo и сериализации / восстановления некоторого объекта, мы используем гораздо более сложную конфигурацию Kryo. Это включает в себя несколько пользовательских сериализаторов, зарегистрированных идентификаторов классов и т. д. Например, мы не смогли найти способ установить пользовательские сериализаторы для классов без получения NoClassDefFoundError - следующий код не работает:

Class<?> kryoClass = this.loadClass("com.esotericsoftware.kryo.Kryo");
Object kryo = kryoClass.getConstructor().newInstance();
Method addDefaultSerializer = kryoClass.getMethod("addDefaultSerializer", Class.class, Class.class);
addDefaultSerializer.invoke(kryo, URI.class, URISerializer.class); // throws NoClassDefFoundError

последняя строка бросает!--11-->

java.lang.NoClassDefFoundError: com/esotericsoftware/kryo/Serializer

потому что URISerializer класса ссылки Kryo-х Serializer class и пытается загрузить его с помощью собственного загрузчика классов (который является загрузчиком системного класса), который не знает Serializer класса.

(3) использование промежуточного сериализация

в настоящее время наиболее перспективным подходом является использование независимой промежуточной сериализации, например JSON с использованием Gson или похожие, а затем запуск двух отдельных заданий:

1. kryo: 2.21.2-ourpatchbranch в нашем обычном магазине - > JSON во временном магазине
2. JSON во временном магазине - > kryo:2-22 в нашем обычном магазине

проблемы
Самая большая проблема с этим решение заключается в том, что оно примерно удваивает объем потребления обрабатываемых данных. Кроме того, нам нужен другой метод сериализации, который работает без проблем на всех наших данных, которые нам нужно будет исследовать в первую очередь.