Сериализация Flink: тип POJO против GenericType - PullRequest
Новая
       4

Сериализация Flink: тип POJO против GenericType

0 голосов
/ 05 февраля 2020

В моем приложении Flink я использую java .time.Instant для представления меток времени UT C. Приложение работает нормально, но недавно я заметил это сообщение в журналах Flink:

"Класс class java .time.Instant не может использоваться как тип POJO, поскольку не все поля являются допустимыми полями POJO, и должен обрабатываться как GenericType. Пожалуйста, прочитайте документацию Flink по \ "Типы данных и сериализация \" для подробностей о влиянии на производительность. снижение производительности при использовании чего-то вроде Instant. Насколько я понимаю, Kryo должен использоваться вместо встроенных сериализаторов Flink. В настоящее время я использую Flink 1.6 и вижу, что Flink 1.7 и выше имеют класс InstantSerializer. Означает ли это, что если я обновлю версии Flink, мои POJO, использующие Instant, больше не будут обрабатываться как GenericType?

В общем, какой класс java лучше всего использовать для представления времени? Есть ли способ использовать Instant и уменьшить или устранить какое-либо влияние на производительность?

1 Ответ

2 голосов
/ 05 февраля 2020

Сообщение журнала немного вводит в заблуждение, но ваше понимание верно. Instant сериализуется с использованием Kryo во Flink 1.6.

В Flink 1.7+ Instant будет сериализовано с InstantSerializer, а не с KryoSerializer.

Будет ли ваш POJO рассматриваться как таковой или нет, не зависит от того, как Instant будет сериализовано в вашем POJO. В сообщении просто говорится, что система пыталась определить, является ли Instant POJO или нет.

Пример: 

    public class SpecialMomentWithName {
        private String name;
        public Instant specialMoment;

        public String getName() {
            return name;
        }

        public void setName(String name) {
            this.name = name;
        }
    }

SpecialMomentWithName всегда будет обрабатываться как POJO во Flink.

Вероятно, вы обнаружите небольшое снижение производительности при сериализации Instant с использованием Kryo против нового InstanceSerializer в микробенчмарке. Трудно предсказать, выиграет ли производительность вашей работы Flink от такого изменения: если затраты на сериализацию Instant сжигают большую часть вашего процессорного времени (а ваша работа связана с процессором), то я ожидаю повышения производительности. Если ваша сеть или жесткий диск (при использовании RocksDB) являются ограничивающим фактором, я не ожидал бы улучшения производительности.

Я бы не стал оптимизировать производительность сериализации Instance, не выполнив некоторый анализ того, где вы на самом деле теряете производительность. Если вы обнаружите, что ваша производительность страдает от сериализации времени, как это, вы можете попытаться представить Экземпляр как long. Это снизит читабельность вашего кода, и у вас могут возникнуть дополнительные циклы ЦП для преобразования между типами.

...