Каковы рассуждения, стоящие за схемами соединения Кафки?

Мы пишем пользовательский соединитель приемника для записи содержимого темы с сообщениями avro в хранилище CEPH.

Для этого нам предоставляются SinkRecords, которые имеют схему соединения Кафки, которая является отображенной версией нашей схемы avro. Поскольку мы хотим записать avro в CEPH, мы используем методы connect API для преобразования схемы Connect обратно в Avro. Почему мы должны это делать? Каковы преимущества введения схемы Kafka Connect и отказа от использования более адаптированного Avro Схема?

К вашему сведению: я спрашиваю об этом, потому что у нас есть некоторые проблемы с профсоюзами Avro. Их сопоставление со схемой соединения Кафки все еще имеет некоторые проблемы, например https://github.com/confluentinc/schema-registry/commit/31648f0d34b10c1b36e8ec6f4c1236ed3fe86495#diff-0a8d4f17f8d4a68f2f0d2dcd9211df84

1 2
apache-kafka avro

1 ответ:

Kafka Connect определяет свою собственную структуру схемы, поскольку фреймворк изолирует коннекторы от любых знаний о том, как сообщения сериализуются в Kafka. Это позволяет использовать любой разъем с любым преобразователем. Без такого разделения соединители будут ожидать, что сообщения будут сериализованы в определенной форме, что затруднит их повторное использование.

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

Однако имейте в виду, что если сообщения сериализуются с помощью Конфлюэнтов Avro serializer (или Avro Converter в исходном соединителе), то двоичная форма ключей и значений будет включать магический байт и идентификатор схемы Avro в ведущих байтах. Оставшееся содержимое байтовых массивов будет представлять собой сериализованную форму Avro.
4