Зачем использовать Avro с Kafka - Как обращаться с POJO - PullRequest
Новая
       10

Зачем использовать Avro с Kafka - Как обращаться с POJO

0 голосов
/ 15 января 2019

У меня есть весеннее приложение, которое является моим производителем кафки, и мне было интересно, почему Avro - лучший путь.Я читал об этом, и все, что он может предложить, но почему я не могу просто сериализовать мой POJO, который я создал, например, с помощью Джексона, и отправить его в kafka?

Я говорю это, потому что поколение POJOот авро не все так прямо.Вдобавок ко всему, для этого требуется плагин maven и файл .avsc.

Так, например, у меня есть POJO на моем производителе кафки, созданном мной под названием User: 

public class User {

    private long    userId;

    private String  name;

    public String getName() {
        return name;
    }

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

    public long getUserId() {
        return userId;
    }

    public void setUserId(long userId) {
        this.userId = userId;
    }

}

Я сериализую егои отправить его в мою тему пользователя в Кафке.Затем у меня есть потребитель, который сам имеет пользователя POJO и десериализует сообщение.Это вопрос пространства?Разве также не быстрее сериализовать и десериализовать таким образом?Не говоря уже о том, что поддержание реестра схемы занимает много времени.

Ответы [ 3 ]

0 голосов
/ 16 января 2019

Прежде всего - Кафка понятия не имеет о ключе / значении контента. Он управляет байтами, и его клиент (производитель / потребитель) отвечает за заботу о де / сериализации.

На данный момент наиболее распространенными являются JSON, protobuf и Avro.

Что мне лично нравится в Avro и почему я обычно его использую и рекомендую другим:

1) Это достаточно компактная двоичная сериализация со схемой и логическими типами (которые помогают отличить только обычный long от timestamp in long millis)

2) Схемы Avro очень наглядны и отлично документированы

3) обязательна широкая поддержка среди большинства широко используемых языков программирования!

4) Confluent (и другие) предоставляют хранилище для схем, так называемый «реестр схем», чтобы иметь централизованное хранилище для ваших схем. В Avro сообщение содержит только идентификатор версии схемы, а не саму схему.

5) Если вы используете Java, вы можете получить большую выгоду от использования генерации базового класса POJO из схемы.

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

P.S. Мой очень личный совет: если это не String, выбирайте Avro. Применяется как для ключей, так и для значений.

0 голосов
/ 16 января 2019

Вам не нужен AVSC, вы можете использовать файл AVDL , который в основном выглядит так же, как POJO, только с полями 

@namespace("com.example.mycode.avro")
protocol ExampleProtocol {
   record User {
     long id;
     string name;
   }
}

Который, при использовании цели idl-protocol плагина Maven, создаст этот AVSC для вас, а не вы будете писать его самостоятельно. 

{
  "type" : "record",
  "name" : "User",
  "namespace" : "com.example.mycode.avro",
  "fields" : [ {
    "name" : "id",
    "type" : "long"
  }, {
    "name" : "name",
    "type" : "string"
  } ]
}

И это также поместит SpecificData POJO User.java в ваш путь к классам для использования в вашем коде.

Если у вас уже есть POJO, вам не нужно использовать файлы AVSC или AVDL. Есть библиотеки для конвертации POJO. Например, вы можете использовать Джексона , что не только для JSON, вам просто нужно, например, создать JacksonAvroSerializer для Кафки или найти, если таковой существует.

Avro также имеет встроенную библиотеку на основе отражения .

Так что к вопросу - почему Авро (для Кафки)?

Хорошо, иметь схему - это хорошая вещь . Подумайте о таблицах РСУБД, вы можете объяснить таблицу и увидеть все столбцы. Перейдите в базы данных документов NoSQL, и они могут содержать буквально все, что угодно, и это мир JSON Kafka.

Предположим, у вас есть потребители в вашем кластере Kafka, которые не имеют представления о том, что находится в теме, они должны точно знать, кто / что было внесено в тему. Они могут попробовать консольного потребителя, и если это был обычный текст, такой как JSON, то они должны выяснить некоторые интересующие их поля, а затем снова и снова выполнять нестабильные HashMap-подобные операции .get("name"), только для запуска в NPE, когда поле не существует С Avro вы четко определяете значения по умолчанию и поля, которые можно обнулять.

От вас не требуется для использования реестра схем, но он обеспечивает семантику explain topic этого типа для аналогии с RDBMS. Это также избавляет вас от необходимости посылать схему вместе с каждым сообщением и расходует дополнительную пропускную способность на тему Kafka. Реестр полезен не только для Kafka, так как его можно использовать для Spark, Flink, Hive и т. Д. Для всех анализов Data Science, связанных с получением потоковых данных.

Если вы действительно хотите использовать JSON, тогда попробуйте использовать вместо MsgPack , и вы, вероятно, увидите увеличение пропускной способности Kafka и сэкономите дисковое пространство на брокерах

Вы также можете использовать другие форматы, такие как Protobuf или Thrift, , как сравнил Uber

0 голосов
/ 15 января 2019

Это вопрос скорости и хранения. При сериализации данных вам часто нужно передавать фактическую схему, и, следовательно, это приводит к увеличению размера полезной нагрузки. 

                            Total Payload Size
+-----------------+--------------------------------------------------+
|     Schema      |                 Serialised Data                  |
+-----------------+--------------------------------------------------+

Реестр схем обеспечивает централизованное хранилище для схем и метаданных, так что все схемы регистрируются в центральной системе. Эта централизованная система позволяет производителям включать только идентификатор схемы вместо самой полной схемы (в текстовом формате). 

                      Total Payload Size
+----+--------------------------------------------------+
| ID |                 Serialised Data                  |
+----+--------------------------------------------------+

Поэтому сериализация становится быстрее.

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


Некоторые дополнительные преимущества реестра Schema подробно описаны в этой статье Confluent .

...